I have made 2 screenshots with the HOLE 4 modules from the FGf(my board beta BIOS) and the donor one ,the AMD 78x chipset based one ,from Hex Editor.
Remember HOLE4 is the module that gets extracted and inserted properly.
There is a path there ,is this path an internal one or it s the path from the machine the BIOS engineer worked from ?!
If it s an internal BIOS path does it mean it needs to be corrected somewhere ,in the modules themselves or somewhere else so the BIOS loads them ?!
This is the beta FGf 890GPA-UD3H 2.1 ,HOLE4
This is the F4 from the AMD 780 board ,HOLE4
Did you check the "Read only" option in the "Properties" of the ncpucode.bin file you tried to insert (see "Step 2" of the guide I gave you the link)?
Yes .
I have never seen a path to a special file as text string of a BIOS module.
Since the BIOS cannot see and read the drive letters of your system, I suspect, that it is the path from the machine the BIOS engineer worked from.
As promised I have downloaded all 3 files and done a look into them with a hex editor.
These are the results:
- File 1 (name: 78LTUB34.F4, size: 2048KB) and file 3 (name: AGESA20.B1, size: 64KB) have exactly the same data, but a different size. Here is the message I got:
- File2 (name: AGESA30.B2 modificat, size: 297KB) has the same first hex codes (24 41 4D 44) and some AGESA entries as well, but is very different from the other 2 files).
Obviously the BIOS operator has used different AGESA target files (B1 resp. B2).
Here is the path shown within file 1 and file 3:
And here is the path shown within file 2:
Nevertheless I cannot give you any advice, because I know nothing about the NCPUCODE.BIN files.
Thanks for the feedback.I understand ,it seems the CPU modules are really a mess in this BIOS-es ,maybe to make people buy newer boards 
I have the impression that this incomplete extraction might be a CBROM limitation.All day i have extracted from many other AM3+ Gigabyte BIOS-es the HOLE files ,and always the last 2 ,HOLE5 and HOLE6 were incomplete ,comparing the extracted size with the one shown by CBROM info ,much smaller always.
It also seems that CBROM has also a limitation regarding BIOS images bigger than 2 megs.
I took some BIOS that i ve used with the crap 970A-UD3 (that i bought and sold some time ago) and opened them in HexEditor ,strangely enough half of the image was filled from the start of the BIOS file till the middle with "FFFF FFFF" and so on.
Removing those made the file 2megs from the original 4megs.It seems that in this board Gigabyte put bigger RAM chips that in my board for nothing.
Before removing that dummy data i could NOT see in this BIOS-es the 2 AGESA modules(this can be seen in one of the pictures from the first page as well the one for the 99FXA BIOS opened with CBROM) ,after the removal CBROM was seeing them.
There were 6 HOLE modules as in the other older smaller BIOS files
Anyway i wonder how can we identify in the HEX Editor the begining of a module and the end of it. ?!
Maybe using this approach i can replace them inside the BIOS file.
Or there can be that in the middle of the module to have another one ,thus the incomplete extractions of the HOLE5(the one i ma interested in along HOLE4) and HOLE6.
HOLE6 is something not related to AGESA/CPU code in any way ,so it can stay in there no problem.
Usually a module begins and ends with other codes than 00 00 00 or FF FF FF. Both codes (00 and FF) do not contain any data.
Hello again.
My FX 6300 CPU has finally arrived and even though it fits the socket (as expected) the system does not initialize ,black screen ,fans working, with no beeps as in not initializing the CPU (which i have expected as well )
So users of Gigabyte 890GPA-UD3H v2.1 of the board be aware that the FX CPU does fit.Also the 890GX chipset is able to work with this CPU-s ,Gigabyte made possible that even 2006 Nvidia Nforce chips to run FX chips ,but for markting sake they must have black sockets.
The small BIOS chip of 8megs is enough to get the job done.
Now i realy have to start and try my luck ,nothing to loose ,the board has dual BIOS ,i can force it to kick in and copy from the back-up ,if needed, the original BIOS.Also the board is under warranty at the reseller so no biggy.
I have investigated a little on the web what is what with this modules.
Opened the 890GPA-UD3H v2.1 FGf beta BIOS and started looking at it in HexEditor4.
Stumbled upon a thread on a BIOS moders forum.There i could see that there are 2 kinds of modules ,compressed and non compressed.
The non compressed are used to initailize the system practically and into this cathegory we also have the 2 modules i am interested in HOLE4 and HOLE5.
The compressed ones are starting with lh5 and some bites prior.They finish with a dot.
I then took a look at the BIOS itself and identified every module in there one by one.
The compressed ones seem to be in the lower half of the BIOS file ,as it s opened in the HeXEditor ,the ones that i need are in the other half from the begining to the middle.
Like i said HOLE4 can be extracted (from any BIOS i ve tried) via CBROM.I have also extracted it manually with succes as i was able to rename it and add it with CBROM into the BIOS with no problems.
HOLE5 on the other hand is not fully extracted with CBROM ,but it can be extracted manually via HexEditor.The non-compressed modules can be extracted via Hex Editor they say…
I have managed to identify the modules HOLE5 properly and cut it more exactly from within DONOR BIOS and transforming it into a file .It is at the dimensions that CBROM sees it in the DONOR BIOS (but it s incapable to extract it fully).
Making the HOLE5 module using the HexEditor is nice ,but CBROM refuses to add it with a message : “Hole Structure information of BIOS file doesn’t match”.Adding it manually i am not sure it will be properly taken unless something is modified in the BIOS strings.
Google-ing the message led me to this forum again ,to this thread ,see post 2 in there → Guide: Enhanced BIOS Modding of Award BIOSes
It seems that in this scenario HOLE2 was to be replaced.
So having in mind this thread it means that i would need to edit that HOLE fields as well so the decompressor to avoid my modification.
The question is what are the byte holes in this area ,the bytes for them and which are the ones that need correction for HOLE5 ,as it seems there is a need for space.
The new updated HOLE 5 (cut from the DONOR BIOS) is bigger ,around 290K opposed to the original outdated one (from the FGf beta BIOS) that has around 270K by CBROM info.
So having the right space there should alow me to insert via CBROM or manually succesfully the module t osee what happens.
So is anyone able to identify the HOLE 4 and HOLE 5 in there and their coresponding page bits that should be changed to alow a 300K module.See picture attached for details.
This are the modules i have manually extracted from the DONOR BIOS ,AGESA 1500 modules ,that should alow FX Vishera CPU-s to be used :
This is the picture with the HOLE registers that need to be tweaked ,there should be 5 of them (Holes) in my FGf BIOS :
Sorry for re-posting the BIOS related files ,but to be clear even for new readers regarding the files used as the thread has grown in size and it s hard to follow.
Waiting for suggestions
This guide is really great Guide: Enhanced BIOS Modding of Award BIOSes
SummoneR guide opened my mind.
I have finally successfully changed the HOLE4 and HOLE5 modules in the 890GPA-UD3H FGf beta BIOS ,from AGESA0075 to AGESA1500 .
BIOS files are in the upper post linked
What i did was :
1.Extracted the HOLE4 module with CBROM ,for a clean result ,from the DONOR BIOS
2.Extracted the HOLE5 module manually with HexEditor 4 ,based on the dimensions stated by CBROM and obvious boundries .
Both this modules start with a dollar sign and named AMD on the right of the hex editor.
3.Compared the HOLE sections in both BIOS files opened (DONOR and the FGf beta) in Hex Editor ,trying to identify as in SummoneR thread what could be the meaning of those binary…
The software has a nice search function.
4.Corrected the max dimension of HOLE5 in the 890GPA-UD3H FGf beta BIOS (the one that will be used and installed maybe)
I had to change the value from 45 to 50 as in the donor BIOS ,nothing else changed.Saved the BIOS file.
As it looks in original FGf :
As it is in the DONOR BIOS ,
First group must be HOLE4 ,the 94 ,second group must be HOLE5 95 and the value was changed for it from 45 to 50 as in the donor so it fits.As it worked after modification it must be correct.
5.Started insertion with CBROM
-first HOLE4 module with the name AGESA20.B1(as in CBROM info for the FGf)
-second HOLE5 with the name AGESA30.B2 (as in CBROM right column)
6 Reopened the BIOS with CBROM command /D and all other modules seem to be in place.
A note would be that the NCPUCODE harvested could NOT be inserted and it s no biggy as the (NON-moded) FGf BIOS runs just fine for 2 days already with my Phenom 2 X975 BE ,in spite of the FGf empty section for this module.
I will have now to install the new BIOS Monday ,i will report the results after i install again the FX 6300.
If it works it s a wonder
If it will not work i ll move on and buy a new AM3+ mobo ,no problem.
I have flashed the modded BIOS ,but it s NOT working.
This is the file -> removed as it s useless
As in the previous CBROM picture we can see that the BIOS looks good in there ,but that s it.
Tried to flash with Q-Flash and it popped up a message "Invalid BIOS Image"
Then went into Windows and flashed thru @BIOS.It did it ,but at restart BIOS did not initialize the video (LCD monitor led was flashing as in stand-by) and when i ve pressed the button to turn it off a beep was heard.
At the next PC start from power button the Recovery BIOS procedure kicked in with Invalid Checksum or something and the mobo flashed from the backup the FF version.
Previously to flash i ve had FGf original (which was working ok) on the main and FF on the backup.
Practically my modded BIOS was not even initialized i think.
Any hints ?!
EDIT:
It seems that CBROM is not to be trusted.
First of all I opened again the resulted BIOS and HOLE 4 module seems to be a little shorter or something in the BIOS ,as pasting in HEX Editor over ,i mean the HOLE4 module content (extracted previously from DONOR) ,messes up the lines.
So some bytes got lost while CBROM replaced the HOLE5 ,HOLE4 being the first inserted with CBROM (as stated in the previous post) ,HOLE5 being second. Also the offsets of HOLE3 are wrong it starts differently ,CBROM is extracting the HOLE 3 differently from the FGf original and from the modded one .
So no wonder it didn t take it.
I have to re-seat the modules in the BIOS so they are where it should.
Fernando do you happen to know what this line refers too ?! 
There seems to be some overlaping taking place.
I have added manually the modules copy/paste over in HexEditor ,started from scratch.
I was able to set back the start of HOLE5 ,after i pasted the HOLE4 ,but after i ve copy/pasted HOLE5 over into the BIOS the module end moved lower than it should and overlaps with this line of code in the picture.
This overlaping could be solved by proper correction for the offset somewhere.
Is there a trick to full CBROM into making this stuff instead.
If by inserting them with the CBROM in this order HOLE4 and then HOLE5 i get issues with HOLE3 start ,but not with the line in this picture how can i insert this modules so they stay where they should ,so adjustment happen towards the start/up of the file as the FF dummy has enough space taken to loose from between the non compressed modules.
Should i reinsert all HOLES in a specific order ,starting from HOLE5 or ?!
There are other Forum members, who know more about that, what you are going to try.
After an insertion or replacement of a BIOS module it may be a good idea to check the integrity of the inserted module. This is why I always extract the new module and compare it with the source file by using a hex editor. Your special problem is, that the NCPUCODE module cannot be extracted as easy as a PCI ROM module.
I have made another BIOS.This one failed too even though looks good.Q-Flash says it s an invalid Image.
I have tested it by extracting HOLE-s after and comparing them with the ones extracted before re/adding HOLE4(DONOR) ,HOLE5 (DONOR-manually collected same size as CBROM reported) and HOLE3(FGf) into FGf.
HOLE 3 was extracted released reinserted the last in the hope of checksums corrections.
I had also took the Hex and compared them by copy/paste them to see if they overlap,they didn t
Keep in mind that even though HOLE5 can be inserted with CBROM with no problems ,it can t be extracted with CBROM.So it must be checked manually in HexEditor.
CBROM had all modules listed and with correct size.
All seemed good in theory but … after flashing it with atBIOS i still was in a black screen with monitor in stand by.This time it took longer though for the Recovery to kick in.
So something is still wrong.
Keep in mind i am using the Phenom 2 and that NCPUCODE is as it is in this beta(FGf) by default.So even if we make the assumption it s from NCPUCODE it worked without it as well.
I did not touched the NCPUCODE ,it was left as it is in this beta BIOS-es.
By the way the code in the previous picture seems to be from ECCODE.bin code.
Until someone that knows coding comes in i am unable to do more.
I would have tried directly some other BIOS if this not cheap board wouldn t have had such a small NVRAM chip.
I am opened to ideas.Maybe some checksums don t go right in there.
Maybe SoniX or CPL0 can help you to solve your problem.
I have checked the BIOS checksum of all your test files, because Gigabyte BIOSes are checksum sensitive (checksum-8 of the entire BIOS file has to be 00). Even your latest modded BIOS was ok regarding this point.
I will do one more try.
I will take the BIOS FGc as mod base.Maybe FGf has something in it that brakes the mod.It s 1K smaller in code.
I will also harvest the AGESA from a 990FXA board via HEX Editor.
Maybe indeed the AGESA code i ve took from the AMD 780 board is not compatible with the 890 chipset or something ,even though they are quite similar.
I will report what happens.
Edit:
I have made a BIOS based on the FGc.
It didn t work either .
Same Invalid BIOS image in Q-Flash and flashed with atBIOS did the same black screen at restart ,monitor led flashing as in stand by and then the routine of Auto Recovery kicked in putting back FF BIOS.
Preparation was the following:
1.Released the RAID850 component.
2.Released the HOLE4 and HOLE5 as well.
3.Edited the HOLEf field in the resulted file so it allows the full HOLE5 file to be inserted via CBROM ,as i have discovered and presented in previous posts.Value was changed for 95 module to 50 from 45.I did the same for HOLE4 (module 94 in there) which i ve changed from 10 to 11 from the fear of not having it incomplete as discovered earlier.
4.Added via CBROM HOLE5 (Agesa 1500)
HOLE5 here -> http://www.sendspace.com/file/rcz1sz
5.Added via CBROM HOLE4 (Agesa 1500)
HOLE4 file here -> http://www.sendspace.com/file/lfypip
It s interesting to notice that FGc opposed to FGf has no HOLE3 (ECCODE.bin) module.
Both of the original BIOS-es are linked in the first post.
The BIOS file resulted is here ,has no RAID module ,was left out -> http://www.sendspace.com/file/oeydfe
The checksums look ok ,but the Q-Flash Invalid Image message is what puzzles me.
At any normal BIOS file Q-Flash ,before flashing ,it shows a Checksum number.
Where is it getting it is the question.
Then i wonder if my BIOS-es don t work because the Checksum procedure kicks in first and before it even loads the BIOS file it goes for the Recovery ,which states Checksum error as well.
Hello again.
I think i am finally close to something here.
As the CBROM does strange stuff decided to use ONLY the copy/paste approach.
So what i did was to take FGc BIOS this time and see if by copying the new modules content over the old content it works.
So took the file opened it and the pasted HOLE4 and then HOLE5 content over.
As they are bigger by adding each one ,other lines were moving down ,so i have moved each ones start back to the offsets they had before pasteing.Practically by this i have removed some of the FFFFFFFFF dummy stuff.
This CAN NOT be done on the FGf on the other hand as after pasteing the HOLE5 content ,the big one ,the end of this module would overlap HOLE3 content ,which is ,with luck, a module non existent in the FGc.
So this is what i have now ,after correcting the HOLE 94 and 95 maximum sizes as it was did in that sticky.The modules are in there ,but CBROM reports the old dimensions of the previous ones.
I have the hunch that this ones in this picture are the lines that determine also the position and space of this HOLE-s 
This module or whatever it is ,somehow splits the BIOS file in 2 ,whats upper than it in Hex Editor is the HOLE-s content it seems ,under it in HexEditor there seems to be compressed modules.
It s some kind of boundry ID-ing the HOLE-s.
Maybe this module is the one that checksums HOLE-s.
So what do i correct in there.I ll take a look in the donor BIOS and see some hints or something ,but it would be nice to know each of those numbers purpose.
And almost forgot.
If this lines have nothing to do with the wrong file dimensions how do i correct them so the HOLE4 and HOLE5 show the correct sizes.Around 63Kb for HOLE4 and around 297Kb for the HOLE5.
Edit:
And here is a picture where we have on the right the FGc BIOS made with CBROM and on the left the initial values from the copy/pasted one (the strings are identical to the one in the original FGc of course)
Another question would be if i should change the HOLE names according to the DONOR BIOS.Copy/paste this strings from donor.
AGESA 1500 HOLE4 and HOLE 5 modules have different names in the other AGESA 1500 Gigabyte BIOS-es.
Could this names be hard coded in the modules copy-ed !?
Maybe that s why they are not initialized ?!
@ Jumbix:
What you are doing is really applaudable. 
I like people like you, who never give up. This is the way you learn the most.
All I wish is, that you will succeed at least. I have already my fingers crossed.
Thank you Fernando ,i am quite a stubborn indeed 
Unfortunately it did not help
Made another FGc BIOS taking care of those strings and putting them as in the donor.
It didn t work either.
That time prior to the recovery kicking in looks exactly like using an unrecognized CPU so whatever i am doing brakes the initialization of even the Phenom2.
Unfortunately all this modules most probable are linked and referenced in some other part of the BIOS ,so without real knowledge it s just the luck involved.
Anyway i am perfectly convinced that a skilled man can make out of the FGc easily an updated BIOS.
To bad no one made a tool to assamble all this modules starting form scratch ,making our own BIOS-es from modules.
To much proprietary stuff.We pay for the hardware we should be allowed to make our own.
We have just to wait for the manufacturers to throw us a beta BIOS from time to time.
What was so hard for the guys at Gigabyte to simply update in that beta the AGESA stuff.
And another question for you.
I see that the FGc and maybe even the FGf (i did not tested the sound on this one) has a strange sound module.
The Realtek control panel looks strange here and there opposed to the official FF BIOS.Also the hardware ID seem to have changed as from FF to FGc it reinstalled the Realtek audio driver.
Can the sound module be replaced with no head scratch?!
Where is it usually as i am not able to identify it.
I have extracted several modules of your BIOS and opened them with a hex editor, but I didn’t find the sound module either.
I have extracted several modules of your BIOS and opened them with a hex editor, but I didn’t find the sound module either.
The guys in the Gigabyte BIOS team are amazing wizards.
The sound module is in the same place where the CPUCODE is ,somewhere in there
Sound is outputted though in spite of the limited inputs/outputs ,but compared to the FF BIOS is quite limited.
We can t even edit/replace that
Maybe the Dolby stuff made them hide it.
Best approach to update this mobo would be 2 chips of 16 megs so we can upgrade to 3.1 BIOS-es.
If i can t sell it fast i will take care of it the hardcore way.
And it s so bad because hardware wise this board was simply blazing fast issue free.
Fast SATA controllers ,fast boot ,good on-board sound ,even though i use the X-Fi Music ,etc.
I hope that someone will make this mod just to show it can be done.
It fits users of 890GPA-UD3H 2.1 ,it s a FX 6300
Fernando ,this is the checksum used by Gigabyte ,the one that Q-Flash checks for at BIOS update.This checksum poped up at install.
It s 16 bit.
This is my modified file and same was on the FGc when i ve installed it to test it.
As the file has been modified the probability for the checksum to be AA00 as the original FGc is impossible.
And another question.
When you change modules does ITEM.bin needs modifications.What modules modifie when you change modules ?!
Any other modules should be changed ?!
EDIT:
Could be the fact that i ve worked with the hex editor in bytes instead of Dwords a problem ?!
Maybe harvested the modules incomplete or something ?!