Nice timing. I've been researching how to increase Phenom II support in AM2+ boards. So far I've dumped the old BIOS and extracted the various components. It's an Award/Phoenix which can be picked apart with CBROM, or alternatively just look for the -lh5- marker in a hex editor to find the individual archives that can be unpacked with good old LHA.

It looks like CPU identification code is contained in AGESACPU.ROM, for which various versions are listed here https://www.bios-mods.com/resources/index.php … %2FAMD+Agesa%2F

Need an SPI flasher so I don't brick something.

Once upon a time I did successfully mod an AMI BIOS with MMTOOL to insert Pentium M Dothan microcodes prior to a swap.

Will they run with core boot? https://www.coreboot.org/users.html

AFAIK coreboot is very limited in compatibility.

I've gotten around to updating the RealTek and Q-Flash roms on the X38-DQ6

I'm still hesitant to update the ROMS above MINIT for the controllers but mabye I'll get there eventually this motherboard has a BIOS backup feature but looks like I'll need to do some hex editing trial and error.

I'm suprised there isn't some automated website doing this somewhere but I can see why people might be hesitant considering the possibility of bricking....mabye restrict it to motherboards with a BIOS backup and then certified working BIOS for those that don't?

I'd buy sockets whenever possible, even though the amount of work to desolder and solder the socket is about the same as the flash replacement.

With older systems at least, the key is to make a working backup of the ROM, i.e. back it up, flash a compatible ROM, test it, then file the original under P for Panic and experiment on the new one (or vice-versa, perhaps, if you think the new ROM will last longer).

I don't know how easy it is to get ROMs for newer systems, and truly ancient systems could be hard as well.

Sockets are a really good idea.

Today I got one of these CH341A-based USB programmers with the cable that can clip onto the chip.

Note that the MSI board in the pic is not the one I want to mod, I just got it out for testing, and it took a while before I found the real BIOS chip. They are hard to ID with their microscopic writing. At first I read this chip that only had 256 bytes in it, I don't know if it contains the MAC address for the NIC or what...

The BIOS on the MSI board was a Winbond 25X80AV. My BIOSTAR board also has one, with the added bonus that it's in a socket, so I don't even have to reach in there with the clip-on.

I swapped in a new AGESACPU.ROM with CBROM32 1.55, added back the old one as a dummy, and shuffled things around with my hex editor so that MEMINIT would line up with it's original location. Flashed it and it did not work though. It DID show the correct CPUID string... but it wouldn't actually boot (or enter the BIOS setup) with any CPU. So I have now flashed the old BIOS again.

Has nobody ever got to the bottom of why MEMINIT can't be moved? I find it interesting that it has an MZ header (one of the other modules is a PE file...) and there is a MEMINITENTRYPOINT string with a 32-bit linear address after it that points to the MZ header. CBROM 198 updates this pointer but it's apparently not enough for the BIOS to work afterward. I have two official BIOSs that are almost the same with different MEMINIT locations, I'll have to compare them and see if there any clues in there.

I haven't been able to figure out the microcode table or NCPUCODE.BIN. CBROM won't extract it and when I look at the ROM image there is a NCPUCODE label but the data following it doesn't look like it could be microcode updates. I also can't find anything online that lists which ID number is for which CPU.

I've been attacking this from multiple angles and have some info to add.

1) The microcode is located _before_ the spot where it says NCPUCODE.BIN. It's in 2KB chunks. I tried adding in the whole thing (using hex editor) from a later ROM but then CBROM 198 would show garbage values for everything beyond the first eight. So instead I just replaced one of the microcode chunks for 90nm Athlon 64 chips with the one for Phenom II (CPUID $1043). The CPUID number shown doesn't match the value obtained from the CPUID instruction but it is derived from it. Basically, it's only bytes 0 and 2. So whereas CPUID (with eax=1) would return $00100F43 for Phenom II, the number gets shortened to $1043.

2) I came up with a different strategy for replacing AGESACPU (or any other module) that is located before MEMINIT, without messing up the location of other modules. I just disable the old AGESA by changing it to a different module type (OEM2 in this case), and then add the new one with CBROM155. If you were wondering what the difference is between OEM1, OEM2, GV3, PCI ROM, and so on, this information is actually hiding in the date field of the LZH header of each module. (That's why all the dates are bogus when you extract the files.) So just by changing that and the header checksum byte, now the old AGESA becomes OEM2 (which is effectively ignored) and I can add a new one as GV3 again. I also changed the filename but it doesn't seem to matter.

1list of module types that were found in my BIOS (defined in LZH header date field):
202 40 = splash screen
303 40 = ACPI
40E 40 = ygroup
50F 40 = MIB
613 40 = OEM1
714 40 = OEM2
85D 40 = BIOSF0
967 40 = GV3
1069 40 = MINIT
1177 40 = OEM4
127A 40 = HTINIT
137C 40 = 2 PE32 in MB (?)
147F 40 = xgroup
1586 40 = PCI ROM A
1687 40 = PCI ROM B
17B5 40 = SETUP0
18B7 40 = SMI32
1900 50 = BIOS

modified BIOS summary:

1cbrom32 V1.98 [08/27/08] (C)Phoenix Technologies 2001-2008
2
3              ******** mcodeag3.bin BIOS component ********
4
5 No. Item-Name         Original-Size   Compressed-Size Original-File-Name
6================================================================================
7  0. System BIOS       20000h(128.00K)  13351h(76.83K)  A780A513.BIN
8  1. XGROUP CODE       0D7F0h(53.98K)   09635h(37.55K)  awardext.rom
9  2. ACPI table        065B1h(25.42K)   0256Fh(9.36K)   ACPITBL.BIN
10  3. EPA LOGO          0168Ch(5.64K)    002AAh(0.67K)   AwardBmp.bmp
11  4. YGROUP ROM        0BEE0h(47.72K)   05DFDh(23.50K)  awardeyt.rom
12  5. GROUP ROM[ 0]     064A0h(25.16K)   02C8Bh(11.14K)  _EN_CODE.BIN
13  6. SETUP0             022E0h(8.72K)   00D8Fh(3.39K)   _ITEM.BIN
14  7. BIOSF0              02330h(8.80K)  014F5h(5.24K)   _DMI.BIN
15  8. FLSH CODE         02090h(8.14K)    00C14h(3.02K)   SPIFLASH.BIN
16  9. PCI ROM[A]        10000h(64.00K)   08BA8h(34.91K)  .\ROM\SATA\SATA.BIN
17 10. SMI32       002E0h(0.72K)          00246h(0.57K)   SMI32COD.BIN
18 11. SMIAP       087B0h(33.92K)         00432h(1.05K)   SMIAPCOD.BIN
19 12. OEM2 CODE         088D4h(34.21K)   026F5h(9.74K)   BGESACPU.ROM
20 13. MINIT             0CD0Fh(51.26K)   0CD3Ch(51.31K)  MEMINIT.BIN
21 14. HTINIT             04BC1h(18.94K)  04BF2h(18.99K)  HT.DLL
22 15. 2 PE32 in MB       004A5h(1.16K)   004D4h(1.21K)   HT32GATE.BIN
23 16. MIB ROM           009ACh(2.42K)    004A0h(1.16K)   .\ROM\MIB\A780X.txt
24 17. PCI ROM[B]        0A800h(42.00K)   060C6h(24.19K)  .\ROM\LAN\RELTEK\RTEGPXE
25.LOM
26 18. OEM4 CODE         01350h(4.83K)    00DC0h(3.44K)   SU_Flash.rom
27 19. LOGO BitMap       7560Ch(469.51K)  02845h(10.07K)  .\rom\BMP\bb2008.BMP
28 20. GV3                08BEBh(34.98K)  02E8Ah(11.63K)  AGESA332.ROM
29(SP) NCPUCODE          04000h(16.00K)   04000h(16.00K)  NCPUCODE.BIN
30(SP) HOLE0             4C28h(19.04K)      4C28h(19.04K)     CIMRD790.B2
31(SP) HOLE1             2C42h(11.06K)      2C42h(11.06K)     .\ROM\SATA\UI.BIN
32
33  Total hole area space      = 10000h(64.00K)
34  Total compress code space  = C7000h(796.00K)
35  Total compressed code size = 58BEBh(354.98K)
36  Remain compress code space = 6E435h(441.05K)
37
38                          ** Micro Code Information **
39    Bridge ID                          |     Bridge ID
40 North    South     Patch  ID  CPUID   |  North    South     Patch  ID  CPUID
41---------------------------------------+----------------------------------------
4200000000 00000000   01000002 00000000  | 00000000 00000000   010000B6 00001043
4300000000 00000000   00000068 0000040A  | 00000000 00000000   0000006D 0000041B
4400000000 00000000   00000083 00000680  | 00000000 00000000   01000020 00001000
4500000000 00000000   01000065 00001022  | 00000000 00000000   01000066 00001020

My BIOS from 2008/5/13 contained AGESA 3.1.1.0 and identified all 45nm CPUs as "processor model unknown." The board (A770-A2+) doesn't have dual power planes so I don't believe any 125W or above 45nm chips can work properly. But Phenom II 945, Phenom II 840, and Athlon X2 B26 (or 260) worked, all 3.2GHz or less. The last one doesn't even need microcode updates, so it's almost the perfect choice. I used to run that CPU with a bit of OC but then I changed video cards and the new card doesn't seem to handle overclocked PCIe so I was forced back to stock speed. Ever since then I've been itching to use a Phenom X2 3.3GHz black edition that I have, and get the CPU speed back up. But it seems that the 3.3GHz speed causes the old BIOS to go bonkers.

I tried a few times to swap in AGESA 3.7.0, but the system wouldn't boot. Now I have tried 3.3.3.2, and with this one the system DOES boot, correctly IDs the CPU and applies the microcode update (which I also patched into the BIOS) but there is still some shenanigans going on because it boots at 800MHz. In the BIOS setup where it shows the multiplier, it should say "16.5x" but instead it says "hard disk boot priority" 🤣. As long as the HT link speed is set above 1GHz then I can still boot up and use the system though. If HT is set to 1GHz, apparently the BIOS really sets it to 200MHz and then the system freezes if I try to mess around in DOS or press too many keys at the Windows boot menu...

Once Windows comes up then Phenom MSR tweaker takes over and I can run 3.3GHz and beyond. Although some diagnostic programs continue to report weird stuff.

I already reverse engineered half of the old AGESA code and found a routine that chooses a multiplier and divider from a clock speed, and another routine that appears to be setting up the p-states. So I might still be able to find a fix for booting up with wrong P-states, although the bug could be in another module. The first two bytes of my AGESACPU.ROM are 55 AA and then there is a short jump to the beginning of the code where it tests eax for either "IRTS" or "TDSS". If it's the first one then it IDs the CPU and writes the processor name string, both to the chip registers and to a memory location (pointer supplied by the caller in edi). "TDSS" does a lot of other confusing stuff... 😀

Final update on this persuit.

1) AGESA 3.5.3.1 also works, but doesn't solve anything in this case.

2) I ran across something in AMD's manual (BIOS and Kernel Developer's Guide #31116) that said the CPU speed shouldn't be more than double the NB clock. I don't know WHY it says this, as I myself have run it higher and there are reports online of overclockers also doing so. But my NB is only 1.6GHz, so I started to wonder if the BIOS was knocking the CPU down to 800MHz because it detected that 3.3GHz would be more than double the NB and considered this to be an invalid config. Then I started to wonder why the NB is only at 1.6GHz in the first place, there is no option to configure it in the BIOS setup and it is supposed to run at 2GHz for this CPU. Then I found out about the SinglePlaneNbFid bitfield... (BTW, search engines couldn't find any info on this, returning either no results or ads for plane tickets)

3) I booted to DOS and dumped a couple of registers...

1        mov ecx,$C001001F
2        rdmsr
3        bts edx,$0E                 ; 1=ENABLE extended config
4        wrmsr

1        mov edx,$CF8
2        mov eax,$8000C3D4
3        out dx,eax
4        add dl,4
5        in eax,dx

1        mov edx,$CF8
2        mov eax,$8100C3FC
3        out dx,eax
4        add dl,4
5        in eax,dx

which came back $C8810F24 and $80008E11. This CPU is flagged as dual power planes only! I thought that only applied to 125W CPUs, and this one is only 80W according to wiki (and CPUZ said 65W). Confusing... But that would explain why it is booting up at 800MHz. Although from what I read, dual-plane-only CPUs were supposed to "lock" themselves to 800MHz. Whereas here the issue is easily defeatable with software. Not only PhenomMSRTweaker, but I also was able to fix up the pstates with a simple DOS program which means I could probably add an option ROM to the BIOS that cleaned everything up before the OS even begins to load (and maybe fix the TSC frequency too).

4) I tried hacking the BIOS to set a faster NB clock (ie. 1.8GHz instead of 1.6GHz) but this didn't work, just bricked it again.