Modding Phoenix BIOS to add CPU support

[symphy]

Hey,

Some Updates: I tried it by myself and failed... okay, but i got some informations.

I found the CPU Microcodes for the CPUs in the BIOS of the X6QT8 Quad Socket Mainboard (i used MMTool for that..)

I copied and opened them with a HEX editior, together with the CPU file of the X6DA3-G2 which i wanted to edit...

After pasting and putting it in the right place i flashed the new bios... but no boot. It was my first try, so i dont care... i'll order a new bioschip 2morrow, no problem.

The good thing: After screwing up the BIOS, the board shows now with the little Nocona the same behaviour like with the Tulsas. So microcode missing -> LED off, CPU stays cold, no picture.

I think i screwed up the BIOS during pasting the microcodes for Tulsa. Please help!

[symphy]

Over at new rebels haven i got asked for some screenshots... i post them here, too. any ideas?

I redid the mod in order to take screenshots and recognized some things that COULD HAVE BEEN my mistakes (e.g. errors counting and inserting lines etc.)

The way shown in the screenshots is how i would do it now, please take care of that.



EDIT: THE WAY DESCRIBED BELOW AND SHOWN ON THE PICTURES IS WRONG! PLEASE DONT REFER TO IT! I'LL POST AN UPDATE ASAP!



Okay, let's go:

1. I opened the original PHOENIX BIOS with the Phoenix Bios Editior and backuped the CPU Patch file.



2. Now i opened the AMI BIOS of the Quad Socket board with MMTools and searched for the right CPU string. As you can see, i used the Intel Spec Finder to identify the right one. Saved the string to HDD.



3. Now i opened the extracted CPU string file (left side in the picture) and the CPU data file of the original BIOS (right side in the picture) with a HEX editor. It seems like all microcodes start with 0100 ...



4. Some more research. Between each microcode of the CPU patch file are exactly the same amounts of zeros, then another microcode starts.



5. Copy and paste action. I copied the code for the new CPU and pasted it right above the first code in the original file.



6. Now i scrolled down again and copied the amount of zeros between the microcodes...



7. ... and pasted it between the microcode for the new CPU and the microcode of the (former) first CPU in that file.



Note: My mistake could be happened here. I maximized the window and messed up the "form". The microcodes ended or started in the middle of a line, i had to fill up free space with additional F's and zeros. Maybe i did a mistake here. If you just keep the window in the size it opens, all fits nicely...

8. ... as you can see here, too.



9. Now i had a look at all those F's at the beginning. Must be something like "placeholders?"



Note: In fact, i tried to flash the BIOS at this time, but the read-in failed. So i decided to remove some of the F's until the modded file is as long as the original one.

10. Here again: You can see here that the modded file is of course longer (modded one one the right side, original one on the left)



11. I ereased the needed amount of F's to make it fit.





12. Now it was just putting the files together again...

Choosing the modded CPU data file



And building the BIOS



That's EXACTLY the way i would do it now if i had to do it again.

[ibby]

Sometimes,
using phonix BIOS Editor can have odd effects.

I cant see any mistakes in what you have done.
The ideal way of probably doing it, and the way I have seen it work many times
is to import other mobos microcode in. - Ive always had issues and phonix BIOS Editor.
Hence the orginal route

[symphy]

Sometimes,
using phonix BIOS Editor can have odd effects.

I cant see any mistakes in what you have done.
The ideal way of probably doing it, and the way I have seen it work many times
is to import other mobos microcode in. - Ive always had issues and phonix BIOS Editor.
Hence the orginal route

Sorry, i don't get you. Import other mobos microcode in? So just take another CPU data file and replace the original one (how to replace it without Phoenix BIOS Editior?)

In addition, i dont know of a single board which is using Phoenix BIOS and is capable of running Tulsa.

//Edit: Another idea. I still have the faulty mod Bios from my first try on the floppy disk. I'll compare it later with the one i modded for taking the screenshots, maybe the mistakes are shown.

//Edit2: Tyan uses also Phoenix BIOS on their dual core ready mainboards, but the layout in HEX is slightly different.... no idea how to see which CPU's microcodes are included.

I just opened the newest BIOS version for my X6DA3-G2 in HEX and it's designed another way, too. I worked with a BETA version before... hm.

ibby, can you have a look at this? comparing beta 2.0b and final 2.0c

[ibby]

link me to the BIOS

[symphy]

Hm? they're in post 3.... 2.0c is the newest and 2.0b the one stored on rapidshare.

[symphy]

I identified every single code in the PHOENIX and AMI BIOS.

The way to do it i've shown above is WRONG.... i think the "F"s are needed. I found 2 microcodes in the Phoenix BIOS which have exactly the same length as the Tulsa microcodes and will try just to replace one of them... (e.g. there's one for 667 MHz FSB xeons which isn't needed at all...)

[Ket]

Have you tried simply extracting the P6 microcode and slotting it into your BIOS with MMTOOL?

[symphy]

Hey,

Some Updates: I have got new BIOS chips... i tried the following things up to now:

- just pasting the microcode of tulsa at the end of the UPDATE0.ROM no success
- replacing the dualcore microcode of the UPDATE0.ROM with the microcode of the tulsa no success

and, as Ket said: Just taking the P6 file of the X6QT8 renamed to UPDATE0.ROM - no success... But i used Phoenix BIOS Editor for that, MMTool won't work with those Phoenix BIOS....

BUT... my little single core nocona worked correctly with all these versions.

Another idea was to delete the content of the UPDATE0.ROM... so i deleted everything except the F's at the beginning and the tulsa microcode. no boot at all, even with my single core. so the microcode is important for booting up, not only for displaying the right cpu name etc.

Any other ideas why the tulsa CPUs isn't starting at all? It's electrically the same as the officially supported paxville dualcore, but 65nm instead of 90 nm. Could that be the problem?

//Edit:

Another thing that doesnt work:

- There are three microcodes for Paxville (CPU ID 0F48 - dual-core technically similar to Tulsa) inside the quad socket board bios. I took all three of them + the tulsa microcode + the microcode for my little testing cpu (in this order).... little CPU working, tulsa still no boot.

[symphy]

Any new ideas?

[symphy]

Do I really need to sell this stuff again? ...

[karbonkid]

I'm having similar problems with my MSI K9ND BIOS mods...

Inserting the microcode, making sure to follow conventions used for the rest of it, to UPDATE0.ROM results in POST getting stuck at code 85. This suggests that either UPDATE0 has an internal checksum, or that its size cannot be changed easily.
Trying with replacing other microcode POSTed when I restarted after the flash, but now just results in POST looping codes 11~85, can't record exactly which ones yet as they flash past too fast. My debug card has a history function though, so I'll try to record the process as fully as I can and try to figure out what's going on.

Interestingly, the above findings are with the 8mb, quad-core supporting BIOS, replacing quad-core microcode with the shorter microcode for the Athlon FXs that I want to get working.

With the 4mb BIOS, it is a completely different scenario - UPDATE0 in this BIOS is mostly blank (FF), suggesting microcode is stored elsewhere. However, the file it seems to be the same length as 2 microcode strings; inserting the Athlon FX microcode here results in the board POSTing and half-recongising the CPU (saying "CPU0 =Althon 64 FX-" during POST) but not recognising the exact model and therefore not setting correct Vcore or multiplier. It may be due to the FXs having unclocked multis, but I hope that isn't the case...

More hacking/testing tomorrow, hopefully.