Socket 462 BIOS workshop

[Tzk]

So i tested a few more cpus. My current conclusions about BCRC are:

• if the cpu has a minor revision of 2 or 11, then it is reported as multi locked
• if the cpu has a minor revision of 12 or 15, then it is reported as multi unlocked
• minor revision 11 is reported as Thorton w/ 512K, all other minors are reported as Barton
• Stepping is just a guess and mostly AQYFA or unknown

Now, i added Antinomy's cpus to my list and sorted them by minor revision and week.

• Revision 2 has two ranges with a gap in them: 0337 - 0349 (?) and 0405 - 0411 (locked)
• Revision 11 was made from 0342 to 0512 (locked)
• Revision 12 also has two ranges with gap: 0327 - 0332 (unlocked) and 0403 - 0407 (locked)
• Revision 15 seems to be the oldest: 0318 - 0319 (unlocked)

So i believe the timeline of the revisions is:

15 -> 12 -> 2 -> 12/2 -> 11

On german Hardwareluxx forums there is a user which states that AMD changed something inside the cpu die which makes them clock a lot better. That's why the mobiles from 0351 onwards clock so much better than older Bartons. I believe that it's the change to minor revision 11 which is to "blame" for this, although we need more cpus/data to prove this.

We also need more cpus to see of the gap in revision 12 and 2 is real...

Edited July 5, 2021 by Tzk

[I.nfraR.ed]

I've been going through some of my CPUs. I forgot to note the reported core by BCRC for some of the first entries in the table, so take them with a grain of salt.

The lookup table for those cores is not 100% correct anyway. Some of my Thoroughbreds are missing, hopefully I will find where they are

Model	OPN	Batch	Core	CPUID	Rev	Unlocked		Code Name	Site.Major.Minor	Multiplier type	Possible Marker
Athlon XP 1700+	AXDA1700DLT3C	AIUGA 0245SPIW	Thoroughbred-A	0680	A0	yes	2308	Thoroughbred	1.0.4	Unknown	Unknown
Athlon XP 1700+	AXDA1700DLT3C	AIRGA 0319WPMW	Thoroughbred-A	0680	A0	yes	2318	Thoroughbred	1.0.14	Locked	MIAGA
Athlon XP 1700+	AXDA1700DLT3C	RIRGA 0233VPMW	Thoroughbred-A	0680	A0	yes	2318	Thoroughbred	1.0.14	Locked	MIAGA
Athlon XP 1700+	AXDA1700DLT3C	JIUHB 0320MPMW	Thoroughbred-B	0681	B0	yes	2334	Thoroughbred	1.1.14	Unlocked	AIUHB/JIUHB
Athlon XP 1700+	AXDA1700DLT3C	JIUHB 0323RPMW	Thoroughbred-B	0681	B0	yes	2334	Thoroughbred	1.1.14	Unlocked	AIUHB/JIUHB
Athlon XP 1700+	AXDA1700DUT3C	JIUHB 0312XPFW	Thoroughbred-B	0681	B0	yes	2334	Thoroughbred	1.1.14	Unlocked	AIUHB/JIUHB
Athlon XP 1700+	AXDA1700DUT3C	JIUCB 0251TPXW	Thoroughbred-B	0681	B0	yes	2326	Thoroughbred	1.1.6	Unknown	Unknown
Athlon XP 1800+	AXDA1800DLT3C	JIUHB 0310MPMW	Thoroughbred-B	0681	B0	yes	2334	Thoroughbred	1.1.14	Unlocked	AIUHB/JIUHB
Athlon XP 1800+	AXDA1800DLT3C	JIUHB 0333VPMW	Thoroughbred-B	0681	B0	yes	2334	Thoroughbred	1.1.14	Unlocked	AIUHB/JIUHB
Athlon XP 2000+	AXDC2000DUT3C	AQZFA 0343UPMW	Thorton	06A0	A2	no	2306	{empty}	1.0.2	Locked	AQYFA
Athlon XP 2000+	AXDC2000DUT3C	AQXEA 0324UPMW	Thorton	06A0	A2	yes	2316	Thorton	1.0.12	Unlocked	Unknown
Athlon XP 2000+	AXDA2000DUT3C	KIXJB 0415EPMW	Thoroughbred-B	0681	B0	no	2333	Thoroughbred	1.1.13	Undetermined	JIXIB/AIXJB
Athlon XP 2000+	AXDA2000DKV3C	JIUHB 0338MPM	Thoroughbred-A	0680	A0	yes	2308	Thoroughbred	1.0.4	Unknown	Unknown
Athlon XP 2100+	AXDA2100DUT3C	AIUHB 0302WPDW	Thoroughbred-B	0681	B0	yes	2334	Thoroughbred	1.1.14	Unlocked	AIUHB/JIUHB
Athlon XP 2100+	AXDA2100DUT3C	JIUHB 0308VPMW	Thoroughbred-B	0681	B0	yes	2334	Thoroughbred	1.1.14	Unlocked	AIUHB/JIUHB
Athlon XP 2200+	AXDA2200DUV3C	AIUCB 0240RPFW	Thoroughbred-B	0681	B0	yes	2326	Thoroughbred	1.1.6	Unknown	Unknown
Athlon XP 2400+	AXDC2400DKV3C	AQXFA 0348MPMW	Thorton	06A0	A2	no	2306	{empty}	1.0.2	Locked	AQYFA
Athlon XP 2400+	AXDA2400DKV3C	AIXHB 0328SPGW	Thoroughbred-B	0681	B0	yes	2334	Thoroughbred	1.1.14	Unlocked	AIUHB/JIUHB
Athlon XP 2400+	AXDA2400DKV3C	AIUGB 0244MPM	Thoroughbred-B	0681	B0	yes	2322		1.1.2	Unknown	Unknown
Athlon XP 2500+	AXDA2500DKV4D	AQYFA 0350SPGW	Barton	06A0	A2	no	2315	Thorton w/512K	1.0.11	Locked	AQYFA

What I've seen so far:

• Reticle site is always 1 - it's either a mistake in the tweaker or these bits started to be meaningful from K8 and up
• Major mask revision is always the same as the stepping (read from CPUID) and the only core that has 1 instead of 0 is Thoroughbred B (as in "the 2nd revision of T-Bred core")
• Minor revision is the interesting one
• BCRC displays Barton if minor revision is 12 and Thorton w/512K when it is 11.

Note that the CPU in red is FAKE Thoroughbred-B, in reality it's T-Bred A instead with L3, L5 and L12 bridges manipulated and has fake markings.

Up to the "Unlocked" column are values either written on the cpu or detected from other tools. Unlocked column is based on testing.

Rest of the columns are from BCRC and the tweaker.

I will also check what Palomino reports, but that MSR is invalid on Thunderbird core, so maybe it's the same on Palominos.

 

PS: Maybe we should use some shared google sheet, since you can't really format the tables here.

Edited July 5, 2021 by I.nfraR.ed

[Antinomy]

On 7/6/2021 at 4:06 AM, I.nfraR.ed said:

Reticle site is always 1 - it's either a mistake in the tweaker

Nope, I've cross-checked all my CPUs with tweaker and CPUMSR, they both show always 1.

On 7/6/2021 at 4:06 AM, I.nfraR.ed said:

the only core that has 1 instead of 0 is Thoroughbred B (as in "the 2nd revision of T-Bred core")

Now that is interesting. So the major revision is the same thing as core revision (stepping in terms of CPUID) and minor revision is the suffix for it. So it's like Thoroughbred-B.14 or rev. B0.14...
Another interesting thing is that minor revision is not an absolute build number.
So we can see 0.14 and 1.2 meaning that minor revision works only together with major. It's only important for Thoroughbreds and maybe Palomino because Bartons are all same major revision.

Edited July 8, 2021 by Antinomy

[I.nfraR.ed]

True.

I was expecting minor revision to be higher for newer CPUs, but it seems there's no such correlation.

There's also no correlation between the minor revision, the PCB revision and the gold letter in the corner.

Common versions for Barton are 2, 11, 12, 15 and as @Tzkpreviously wrote, 12 and 15 are reported as unlocked, while 2 and 11 are reported as locked. This doesn't 100% correspond to reality, since it depends on the production week, too. One of my 2s are unlocked and one 12 is locked. Overall the detection success rate seems to be high.

I will re-check those 2 CPUs to make sure it's not an error on my side.

Thoroughbred B has revisions 2, 6, 13, 14. 2 and 6 are reported as "Unknown", 13 is reported as "Undetermined" and 14 as "Unlocked".

In reality, 13 seems to be the only one that is locked.

2 and 6 seem to be from 2002, others are 2003 and 2004. There's one 14 from 2002.

I have one Applebred B0 (Thoroughbred-B) which is 14 and is locked, produced in week 0347.

All Thoroughbred-B Semprons I have are 13 and are locked. Also later production weeks, which "guarantees" a super locked CPU.

 

11 is B in HEX, 12 is C, 13 is D, 14 is E, 15 is F. I guess the highest possible is 15 (F).

According to the documentation, it's bits 3-0 (4 bits), so 1111 = F is the highest.

 

Edit:

For Applebred/Thoroughbred the following seems to be valid (with one exception again, which I have to recheck)

xxxHB (e.g. JIUHB) is 14

xxxCB (e.g. JIUCB) is 6

xxxJB (e.g. KIXJB) is 13

xxxXB (e.g. MCXB) is 13

xxxGB (e.g. AIUGB) is 2

I'm sure BCRC is guessing the "Crystal Marker" based on the minor revision and codename.

The theory is that this minor revision is something like a range of letters. Same applies to the major revision, which is indicated from the last letter, e.g. JIUHB, where B = 1 for "Thoroughbred-B". In case of a Barton, we have A = 0 there, e.g. IQYHA.

I'm kind of sure about last letter now. The minor revision is probably "encoding" for more than one letter.

 

This timeline with steppings might help us reconstruct the lookup table:

https://www.cpu-world.com/info/AMD/amd_stepping_K7.html

https://www.cpu-world.com/info/AMD/K7_stepping_codes.html

Edited July 9, 2021 by I.nfraR.ed

[digitalbath]

I managed to add BIOS options to a AMI BIOS. My ASRock NF2 BIOS mod now has more DRAM settings.

I would like to share a few words about AMI BIOS modding and my main problems I had.

1.0   AMI BIOS

AMI BIOS modules are divided into module IDs:

The modules we want to mod is 1B (System module) and 21 (language module).

 

2.0   Language module

The first bytes of the language module should be the same as in most AMI BIOSes. Offset 08h and 09h indicate the start of the first address to the lables. This is also the start where the counter begins. Addresses are written down in little endian (offset 06F6 --> F606).

Special note to the (red) offset 14h and 15h. This bytes are crucial. Wrong  values will cause a crash in AMIBCP. I have no clue what they mean.

The last address follows with the first lable F606. No further addresses can be added here. To solve this problem I added 200h free space between the last address and the fist lable. Then I had to correct ALL (!) addresses by +0002 (little endian, +200h offsets). Then I was able to add a lot of new lables! I filled the whole 200h with addresses.

Important! I also had to change offset 14h and 15h by +0002!

Now, lets have a look at our new lables in AMIBCP:

Looks fine now. Lable tokens are important fo find the BIOS strings and menu in the System module.

 

3.0   Edit System module.

The 1b module consists of several parts. The part that I need is called here: SETSVR_CSEG (sometimes other names). You can easily find it with this sequence:

There is a tool (ami_1b_utilz)  to split the 1B module to its parts. Many thanks here to Antinomy!

Now you have to search for the lable tokens. This can help to decrypt the BIOS menu and the BIOS items.

Here is some help to find it easier. BIOS items (begins with 01 ….) should look like:

 

(pics from Polygon)

BIOS menu code should look something like this:

My second problem was to find empy space for my code. There is usable space before the code starts and some space in between. AMI BCP finds this new added code, but the BIOS (after a flash) showed an empty screen with no items. My conclusion is that AMBCP and probably some boards will find this new added code, but my board is not able to use the code from the empty spaces (maybe not addressable area?). To solve this problem, I deleted unimportant and unused BIOS options and moved some code to create empty space for my new option. Well, this worked. My BIOS mod works finally! One sidenote: Moving menus in AMIBCP can cause problems. It seems like AMIBCP moves also the menu in the BIOS code.

The BIOS mod now sets correct CMOS values.

The next part should be to create a PCI option rom, that changes all BIOS settings in the System part. As far as I know, AMI BIOS is not able to add a ISA option rom.  So, exchanging existing LAN boot rom to our modded option rom is the way to go.

LAN and LAN Boot has to be enable in BIOS!

 

edit:

There are still some points to improve in this BIOS (hidden RAID menu, more settings...). If I find the motivation to do so, I will improve the BIOS mod.

 

ami_1b_utilz.zip K7NF2_DB2_R2.zip K7NF2_DB3_R2.zip K7NF2_DBA_R2.zip

Edited August 31, 2021 by digitalbath

[ludek]

I want to help you guys. I have something like 4 nf7's, AN7, asus NF2 board and one burned DFI Infinity (don't know what is burned).  I also have lots of Socket A cpu's (40-50pcs). Do you want me to check some things on these boards/CPUs? I know that you also have a lot of gear to play with, but just wanted to let you know that there are some more people interested in this "vintage" motherboards/platforms. Thanks for your work.

[Antinomy]

2 hours ago, ludek said:

Do you want me to check some things on these boards/CPUs?

Try setting 5-6x multi and pus FSB to the max. Try 1M stability and push over 250. Check different CPUs, BIOS, memory, anything that helps get over 250. That's one of the main goals. You are welcome to the Discord channel (link in the first post) for details.

Edited September 2, 2021 by Antinomy

[Tzk]

As the Asus A7N8X in particular is very picky when it comes to ram, i'll share what i found when trying to pass 32M at high fsb. The sticks in question are:

• any TCCD stick, here: Corsair XL v1.2 2x512mb
• Crucial Ballistix PC3200 2x512mb (Micron 5B-G),
• Twinmos Twister "new BH-5" 2x512mb (UTT BH-5)

First i did several hardmods to the board. These are:

• recap with polymer capacitors
• 12V rail mod for cpu
• lower the resistance of the feedback divider of VDimm VRM
• VTT mod (not used here)
• Vdd mod for the chipset

I tested the board with Infineon 6A (BH-6) and Hynix BT-D43 256mb sticks first, as these just work on the A7N8X and i'm able to pass 32M up to 263Mhz with them at 1.85V Vdd without much hassle. Without Vdd mod the board won't pass 32M above ~230MHz, so we keep this for all of our tests.

I'm also using a bios made by @digitalbath, which got all the new options that we found and developed in the past 2 years inside it. The bios is called ED55 B2A, so it uses the ED55 romsips and got the B2A changes for additional romsips and memory controller inside it. The stock bios of A7N8X only got primary memory timings, Vdimm and fsb/ram clocks integrated. The modbios does give us additional options. We get: ram drive strength, ram slew rate, alpha timings, further romsip tweaks, Trc, Trfc, Tref and 2.9V Vdimm. This is essential to push the above mentioned sticks to new limits.

-------------------------

Let's start with the Corsair XL v1.2 2x512mb sticks.

With all new settings on default, Cpu Interface on, CL2.5-3-3-8 and 2.7V Vdimm i can't pass 32M above 235MHz. If we change the alpha timings from the stock 2-3-5-3-2-2-4 to a lot looser 5-4-6-3-3-5-6, that gives us some extra clock and we may pass 32M at 240. Now we work our way through the drive strength (stock 4) and slew rate (stock 10) settings and set them to 5 / 10. At last we work our way through the custom romsips settings. On my board Hynix #1 gives me another few Mhz extra, as this settings seems the most stable.  So here you go, 32M at 245MHz on A7N8X with 2x512mb TCCD sticks.

Note that different sets of TCCD may behave a whole lot different. I got two kits of Corsair XL v1.2 (0538 and 0542) and a kit of Geil Ultra-X. The Asus likes the Geil a lot more and i'm able to pass 32M at 250MHz without such trouble as with the Corsair. Also two Corsair sticks are quite weak and won't pass 32M above 235MHz, no matter which settings i apply. So if you're planning to run TCCD on A7N8X, choose your sticks carefully and test everything yourself.

-------------------------

Now, the second set. I got two sets of Crucial Ballistix (Batch CL1115T.XY and CL11161.26). The 61 set seems to scale about 5-10MHz better, so i used it for this test. With stock settings i wasn't able to pass 32M at 210MHz 3-4-4-8 with any Vdimm between 2.5 and 2.85V. The system was able to boot at 200MHz 2.5-2-2 but quite unstable. And again we work our way through the settings. At first, we set the alpha timings to 3-4-5-4-3-4-5, tref to 2560, Trc 14 and Trfc 16. We also tighten the primary timings to 2.5-2-2-6 and drive strength 2, slew rate 6. With these settings and the custom #3 romsip preset we manage to pass 32M at 240Mhz. VTT Offset stays stock, as these sticks become unstable when changing it. Above 240, the sticks still crash, so we loosen Tras from 6 to 8 and voila, 250MHz 2.5-2-2 with 2x512mb Ballistix on A7N8X ?

Looks like our newly found registers, tweaks and bios has a huge influence and is very powerful... Also the Vdimm feedback rework seems to help by a huge margin. Nice.

 

-------------------------

Let's move to the last set, namely the Twinmos Twister new BH-5. If you search the web for socket 462 results of these sticks, you mostly get posts of people complaining about incompatibility and all sorts of issues. I own two kits of these and all sticks are able to pass 32M between 250 and 260Mhz at 3.4-3.5V on socket 939 (Ultra-D). However on A7N8X with stock bios they even struggle for stability at 200MHz 2.5-3-3, no matter of VDimm applied. At 183MHz 2-2-2-11-13-15 and 2.8V the system was stable. Interestingly going above 3.2V Vdimm even made things worse. This is quite strange behaviour for UTT BH sticks and i suspect that Twinmos might have not binned those sticks well or the pcb of the sticks (KO-6633) just sucks. The production date on the relabeled chips is 0526 btw.

I again started with my ED55 bios and worked my way through the settings. I also tested VTT changes, but deviating from the stock -15mV Offset didn't yield a lot better results. -30mV gave freezes and raising the VTT to 0mV Offset (so exactly 50% of VDimm) made no difference while a positive offset of +30mV made things worse. So i stuck with the stock value of -15mV. I also tested drive strength and found that the range between 4-6 was most stable. Slew rate was kept at the stock 10, as lower or higher settings made things worse. With these settings and alpha timings of 2-3-5-3-2-2-4 i was able to get the sticks stable at 210MHz. A little improvement, but still dissapointing for UTT BH-5 sticks. At this point i decided to call it a day and just put the twinmos back into the drawer. There's no point in wasting more time on these sticks.

So no 32M screen here, i just gave up...

 

 

[digitalbath]

As @Antinomy already in Post #4 discovered, there is a connection between the last two bytes in the romsip multi tables (CPU part) and the S2K PCI register. With the help of the nForce2XT tweaker I was able to discover the right bit mask:

The other 6 Bytes of the romsip multi tables seems not to apear in the PCI register. With this information we now have a better view at the romsips. More tests are required so that we can better understand what these timings do.

 

Edited December 18, 2021 by digitalbath

[Tzk]

You were right, the SYSDCIN is indeed a 4 bit register. This is taken from the AMD-762™ System Controller Software/BIOS Design Guide, page 64 (24462.pdf). Note that it says that 0b1111 = 16 clocks is a valid value for this register.

I also noticed that there's a lot more SIP registers which the AMD 762 chipset uses. The datasheet also mentiones that the SIP values are sent to the cpu, so these values should be present on all socket 462 chipsets, but maybe stored on a different way. So my suspiction is that the NF2 does also have these stored somewhere.

As i also suspect that Nvidia actually licensed the IP of the chipset from AMD, which would make the NF chipset a successor of the AMD 760/762, this might help us a lot with romsips. Remember the Xbox story where Microsoft wanted to use AMD cpu and chipset? The story where a last minute swap to cpus by Intel forced them to rename the chipset, so the chipset wasn't advertised and made as AMD but nvidia? Iirc they even had to build either a intel cpu which could deal with EV6 bus or a chipset to accept the intel bus protocol...

Anyways. Here's what i found in the above mentioned datasheet, namely in the B0:D0:F0:60h to 70h register. Note that the datasheet got these tables multiple times in it. I suspect this is because the 762 chipset can handle dual-cpu setups, so you need them for cpu #0 and cpu #1.

 

And there's even more in this pdf... Seems like AMD implemented drive strength and slew rate for the FSB (not dram!) and even more timings.page 43 and 52:

 

Edited December 18, 2021 by Tzk

[Antinomy]

Sharing is caring

ds_km400a_123.pdf ds_kt600_102.pdf

[Tzk]

I'd like to document my findings on item string inside the Award 6.00PG bios of my A7N8X-E Deluxe. The version i'll use for this is the latest official, so bios 1013. I guess i mostly figured how the bios items are stored...

In Award bios, the selectable items are stored as 25 byte binary strings inside the 128kb system.bin inside the bios file. These strings contain information about the name of the option as link/pointer to the _en_code.bin file (read more about the labels here), where the variable gets stored in CMOS etc. Award groups these strings into pages, just like inside the bios, when the user access it.

To gain access to the strings, we need to extract and decompress the system module. We can either do this by using CBROM or AWDBEDIT. We'll for now use the easy way and load the bios in AWDBEDIT. Here's how it looks when we select the System BIOS and then the Setup Menu tab. AWDBEDIT will show all item strings it has found in the list, grouped by pages. We now know that there are 9 groups inside this bios.

We'll now extract the system module and open it in our prefered hexeditor, in my case HxD. The hex offset where the strings are stored is 10000h. Here's how this looks. Note the "magic number" which is marked in yellow. There's eight of these magic numbers to be found, so i'll assume that these may indicate the start of a bios page.

From the start of the segment at 10000h to the magic number at 10190h seems to be unreadable gibberish, we'll talk about that later.

Before that, we'll have a look at the section below the magic number. It seems like some bios item strings got assembly code attached to them, while some don't. The indicator for this is a small lookup table below the magic number and the blue 08h. It indicates that there's eight bios strings in this bios page which got code attached and is followed by a pointer table. That pointer table consists of a pointer to the bios string and a pointer to the code table. Each pointer is 4 bytes long. I marked two of the eight pointers in green and pink. The green pointer "6b02" directs to the item string at 1026Bh (note the little endian notation) and to the code block "3E04" at 1043Eh. The pink block directs to 10284h and 1044Bh respectively. The other six pointers are marked as orange block and work just like the first two. These pointers are then again followed by a block of "gibberish", marked as big blue block. Below that, the actual bios item strings are stored. In this case there are 18 strings.

In the following shot, the 18th string is marked in green. It is followed by two text strings "Press Enter". Afterwards there's again some kind of (yet) unknown lookup table, which consists of 16 seven or eight byte long groups. This section will need further investigation. There are followed again by gibberish, but in this case the table with pointers to strings and code from above brings us here. So it's safe to assume that this section is actually assembly and will be executed when the user accesses the corresponding bios option.

At the bottom, this code block is followed by the next magic number (marked in yellow), indicating the end of this page and the start of another bios page.

----

That's it for the structure of the bios pages. We now know that these consist of bios strings and code (if nessecary). Now, we'll extract the bits that we called gibberish above and run them through a decompiler. We find that all of this is actually assembly code. Even the block in front of the first magic number is code... So we need to investigate this further to fully understand why Award did this.

------

To close things up for now, i'll attach a textfile where i split the binary data in sections and arranged it into "data" and "code":

offsets.txt

 

[Tzk]

To expand on this a bit further, i dug deeper through the system module of the 1013 bios. There are several of these pointer tables which reference both, an item string and a bit of assembly code. I noticed that these pointer tables aren't stored at the same place inside the module, but the position varies. Also at offset 12B64h and 12B96h there's two pointer tables stored next to each other.

That got me thinking... How does the bios know that the next block of bits is indeed an index, pointer table or whatever else? So i concluded that there must be another lookup table somwhere which stores the positions of these tables. So basically a master lookup table, so the bios knows where to look for the (sub) tables.

As x86 cpus and offset usually work in little endian, i decided to convert the offsets of the pointers mentioned earlier into little endian. Also note that we omit the system module offset of 10000h:

12B64h -> 642B

12B96h -> 962B

I then searched the system module for these numbers and got a single result (!) for both of them at offset 11B36h and 11B38h. That can't be a coincidence... I haven't analyzed that segment further, but i believe this could be the mentioned lookup table. For further conformation, i will first map out the missing bits of the system module and then try to search for all pointer table index offsets afterwards. Maybe there's more to be found...

[digitalbath]

I want to write down some lines about my experience with the mod BIOS for the ASUS A7V600-X board. But what makes the BIOS of this board special? Well, the postscreen says: "AWARD Medallion BIOS 6.0". By trying to look at BIOS modules and items with the tools: awbedit, cbrom and modbin, all three tools refuses to work with this BIOS. After some help from Antinomy and Tzk, we figured out, that we need a special cbrom version for this BIOS called "ACBROM" (A for ASUS?).

ACBROM recognizes this BIOS and this is how the modules look like:

What I see is, that all usuall modules in Award BIOSes are missing here (_EN_CODE, awardext, awardeyt ...). We also get new modules here like ENGLISHPOST, Other (1000:000), Group2+3+4.

After some research, I found the lables to the BIOS items in the Group2.rom module.

It seems like the "_EN_CODE" module for the labes is working here in a different way then in the usual Award BIOSes. The Group2 module beginns with a lot of CODE and about a half, the part of the labes begins:

We see some pointers to the BIOS pages : "Main", "Advanced", "Security", "Power", "Boot", "Server" and "Exit". I didn't check all pointers below the main menu, but these pointers seem not to contain all lables, just for some.

These lables got my attention:

Since the BIOS does not have any items for Dram Voltade or AGP Voltage, there should be some hidden items in the BIOS. I should take a look at the items.

The BIOS items are still located in the System module "MAINBIOS.BIN".

I marked the first item. You see the lable "303A"? It seems like the first lable in the Group2 module is for the first item in the system module. All items are grouped together as a single block of items. They weren't grouped in pages as Tzk found out in his post. Most items begins with a 00 or 01, so they should be all visible, but they aren't. Is there a lookup table with visible and non visible status? I could find anything. I also couldn't find any "$ml$" marker for BIOS pages as normal Award BIOSes do. No wonder the usual Award tools weren't able to read this BIOS. The whole "BIOS structure" is different.

I looked for the missing items for Dram- and AGP Voltage and found them in offset 1C4A7h and 1C48Eh.

For my first mod, i tried to replace two visible items with the items for Vdimm and Vagp. It didn't help, since they were still invisible. My second try was just to set a different Position marker in the strings (yellow marking in the screenshot above). I uses same position marker as the Vcore item (06 vs 1F)

That worked! The non visible items became visible! Now we are able to change the Dram Voltage in BIOS. The bad thing is, these Voltage changes doesn't work. So, these items are useless / non working.

My conclusion to this BIOS is, that there are invisible items and they weren't placed in the BIOS menu. By changing the position marker we are able to make this items visible. I will try to make more items visible and test them, but they aren't as important as Vdimm.

 

Edited March 20, 2022 by digitalbath

[Tzk]

Let's talk about the POST code jump table inside Award v6.0PG Bios.

I'll use the Asus A7N8X-E Deluxe 1013 bios as example bios. The POST code jump table is located inside the original.tmp or system.bin inside the bios. So the first step is to extract he system module with cbrom. Afterwards we can load it into the disassembler of our choice.

Before we dive into this, please be aware that the system bios is usually 128kb in size and split into two 64kb segments. Usually these are refered to as E and F segment, as this is where they get loaded to when the bios is read and processed by the cpu. As the system.bin is 128gb in size, we get hex offsets from 0h to 20000h. The lower half becomes the E segment, so 0h - 10000h is mapped to E000:0000h - E000:FFFFh and the upper half becomes F000:0000h to F000:FFFFh. Keep that in mind when you stumble across far jumps or the bios loading 0E000h or 0F000h into registers. Usually this means that a far jump to the other segment is about to occur.

Luckily Award seems to use the same entry point into the system bios on several bios versions. So in our case we have a look at offset F000:F80Dh (remember, that's stored at 1F80Dh in the system.bin file!) and notice that award stored a jump instruction at that offset. It's a jump to F000:EE0Eh, that might differ on your bios. The interesting part sits down a bit further, the bios moves offset 8D50h into the si register, pushes 0E00h and then returns. We follow that offset and have a look at E000:8D50h.

 

Now, let's have a look at the new offset:

We're presented another offset 8D7Ch (that one is actually the first entry in the post code jump table!) and a call to another routine. If all of that fails, then the sytem will jump to HALT. We'll follow the call to E000:8D5Ch for now:

This looks like a loop, which iterates through the post code jump table. Nothing to do here, but we found the jump table and we now know how it's accessed. The Post code jump table itself consists of several two byte entries which are pointers to code snippets which prepare the machine for POST, so these initialize controllers, dram, chipset and so on. Some entries are just dummies, so we can make use of this and manipulate either the entry in the table (to point elsewhere) or change the code at the corresponding offset. This allows for manipulation of chipset registers and such, even before the bios initialized it.

I believe this is the way to move forward and away from using a ISA or PCI option rom to manipulate chipset registers.

----------

If you want have a deeper look into the topic, read chapter 7.2 here: https://sites.google.com/site/pinczakko/pinczakko-s-guide-to-award-bios-reverse-engineering#Original_tmp

[TASOS]

This platform and it's bios modding , is still interesting in 2024.

I want to thank all members , participants here for their shared knowledge and i hope they will continue to support this thread if they can.

and again , THANK YOU all.