A7N8X-E Deluxe as an alternative for socket 462

[I.nfraR.ed]

I've "rebooted" the mod project and started from scratch.

So far I've done a "base" bios file from the latest D27 official bios for NF7-S

• Updated SATA RAID Silicon Image to latest 4.4.02
• Removed /fnt1 "font1.awd", which doesn't seem to have any negative effect
• Replaced NIC ROM with Plop Boot manager and adjusted labels/menus to match that
• Changed "Unknown CPU Type" string to "AMD Athlon XP-M"
• Reorganized BIOS layout, renamed labels, changed setup and failsafe defaults
• Enabled x23 and x24 multiplier selection and verified to work - I had to change trailing bit in _EN_CODE.BIN with HEX editor (01 -> 00), 00 means "Selectable", 01 - "Non-Selectable".  Modbin was not able to change it.

So I now have a nice "clean" base bios to experiment with BPL and ROMSIP tables, timings, etc. This came at a price, though. One of the bios iterations was somewhat corrupted and WinFlash complained about verification issue of Main bios block, however I was smart enough to program the flash chip with a programmer, then insert that chip into the bios socket and try to boot it.

As a result, my NF7 was not POST-ing, not beeping, just the fans spinning. Changing bios chips didn't help at all. Tried to clear CMOS numerous times (jumper, battery, no power, completely disassemble and assemble the system again, change components - CPU, VGA, RAM) - still dead. When suddenly a bell ringed and decided to try an old Thunderbird CPU without integrated temperature sensor. And it booted, just like my AN7 - same behavior. From that point I flashed the bios+bootblock with uniflash, bent the thermistor in the socket and eventually it worked with T-Bred and Barton again.

A lesson learned:

• Don't flash a bad bios, although it appeared ok in modbin. Always check with as many tools as possible.
• Always save a new file after making changes in modbin. Don't just overwrite the one you've opened, sometimes it messes it up. For example, trying to cbrom such a bios it was constantly inflating up to 4GB, when I stopped it  Guess it went in an infinite loop. Happened twice! Started form NF7_D27a, currently at NF7_D27j. This way you always have a previous step that worked and you can roll back. Bios chip extractor tool is your best friend. I have a few from DFI Ultra-D s.939 boards.

Next, I will try to find how to show certain hidden things from bios. They appear as active in modbin, but probably get removed runtime, or there might be a similar way to unhide them, just like the multipliers. Not that there's much to be enabled, but there's one power management menu I want to try.

PS: Actually that bios POST-ed, but loading and saving defaults is what "killed" the board.

Edit: Another advanced bios modding source that is interesting: https://sites.google.com/site/pinczakko/bios-articles 

 

Additional info if someone is interested in modding under linux

$ sudo apt install dosbox
$ dosbox
$ mount c ~/NF7
$ c:

Then use the tools, e.g.

modbin nf7.bin

If it is a windows executable, like cbrom, use

wine cbrom.exe nf7.bin

 

Edited November 6, 2019 by I.nfraR.ed

[Thorn]

So does your NF7 react to more NB-V? Mine doesn't. Max is at 245MHz 32M@1.7VNB and this is it.I did the dirty Mod for the Ram and Vmod for the NB. DFI and Asus seem to love more voltage. EBED Bios

and an once in a while shot, without valid

 

 

 

Edited November 6, 2019 by Thorn

[Tzk]

1 hour ago, I.nfraR.ed said:

And it booted, just like my AN7 - same behavior. From that point I flashed the bios+bootblock with uniflash, bent the thermistor in the socket and eventually it worked with T-Bred and Barton again.

(...........)

Next, I will try to find how to show certain hidden things from bios. They appear as active in modbin, but probably get removed runtime, or there might be a similar way to unhide them, just like the multipliers. Not that there's much to be enabled, but there's one power management menu I want to try.

PS: Actually that bios POST-ed, but loading and saving defaults is what "killed" the board.

 

How was the "dead" nf7 and an7 behaving? I currently got my best nf7 bricked. It boots, but just freezes after ~5mins, even if i'm just in bios. If i wait a bit i can repeat this.

Regarding the selection, have a look at the PDF i linked, page 214. Swapping bios items is the easiest method i know of to get the setting back. Downside is that you need to sacrifice another item to make it work. I also got a similar issue right now. Asus limits the selectable vcore depending on CPU type on A7N8X... XPm doesn't have the 1.85V choice, only 1.825. Regular XPs can't use below 1.65V. And i feel somewhat offended by this behaviour.

[I.nfraR.ed]

39 minutes ago, Thorn said:

So does your NF7 react to more NB-V? Mine doesn't. Max is at 245MHz 32M@1.7VNB and this is it.I did the dirty Mod for the Ram and Vmod for the NB. DFI and Asus seem to love more voltage. EBED Bios

and an once in a while shot, without valid

 

 

 

Abit boards usually work up to 2 - 2.1V for chipset and I suspect the problem is that Northbridge and Southbridge share the same power plane.

On DFI you have separate voltage regulators, perhaps Asus as well? But some boards just hate voltage. VDIMM is derived from 3.3V, so it's better to power it from 5V or 12V rail, otherwise it is unstable.

This NF7 does ~267MHz 2.04V and I'm trying to get higher.

 

24 minutes ago, Tzk said:

How was the "dead" nf7 and an7 behaving? I currently got my best nf7 bricked. It boots, but just freezes after ~5mins, even if i'm just in bios. If i wait a bit i can repeat this.

Regarding the selection, have a look at the PDF i linked, page 214. Swapping bios items is the easiest method i know of to get the setting back. Downside is that you need to sacrifice another item to make it work. I also got a similar issue right now. Asus limits the selectable vcore depending on CPU type on A7N8X... XPm doesn't have the 1.85V choice, only 1.825. Regular XPs can't use below 1.65V. And i feel somewhat offended by this behaviour.

Basically only work with older CPUs without internal thermistor. AN7 relies on digital reading only, so it was showing 0 degrees for older CPUs that boot and I guess it reads a very high temperature for those with internal sensor and stops it from initializing. And I'm getting a siren (for overheating).

NF7 was behaving the same, but was showing normal temperature on the Thunderbird, because it has a physical thermistor in the socket.

Abit boards have most of the things unlocked - CPU voltage from 1.1 to 2.3V, AN7 has VDIMM up to 3.3V, multipliers from x5.0 up to x22 and I've unlocked x23 and x24 now, so full range.

Default Vcore depends on the CPU, but you can manually select whatever you want. Haven't encountered OCP or OVP up to 2.3V and you can go even higher with vmod

[Tzk]

5 minutes ago, I.nfraR.ed said:

Default Vcore depends on the CPU, but you can manually select whatever you want.

Technically yes, but the asus hides vcore selections depending on the default vcore of the cpu and/or cpu type. Basically my XPm has 1.45-1.825V in bios, while a regular Tbred has 1.65 to 1.85V. All other settings get hidden by the bios. Asus is way more restrictive than Abit on Vcore... no >1.85V options. But at least you got Vdimm fed off 5V, so you can mod Vdimm to >3.6V. 

I might try giving the vcore setting new options in _EN_CODE.bin, maybe that does the trick. I already did this for my "new" items and it worked great.

[Thorn]

Thanks for your explanation . I guess this is why DFI decided to put a heatspreader on the SB. It is getting pretty warm compared to the naked Abit.

 

Edited November 6, 2019 by Thorn

[ozzie]

the most fantastic thread ive ever seen written anywhere since being involved with overclocking, id say, im 1 of the 99% that doest understand it all but what a most enlightening thread , hence the few participants in it replying,  i cant wait until the next day for the next or the next post to read 

this is all about  REAL over clocking and super smart, clever people that know what theyre doing to achieve the maximum from anything

[TerraRaptor]

Does anyone check what are those registers that preface each ROMSIP table in romsip files? They seem to be a bit different between different versions and may have some potential in it (i.e. define the hardwall in fsb - as individual romsips seem to affect performance/stability at given multi but if we run into the same wall with any multi then it should be something else and I expect it can be one of the reasons for that).

[Tzk]

I already made a table to compare these side by side but didn't draw any conclusions. I thought that these might store subtimings/alphatimings, drive strength or slewrate. However i didn't build different romsip combinations to test this. If you want to test this, you could swap only the upper half and check registers with wpcredit to see if for example the drive strength changed.

Here's what Trats 1008mod3, Merlin ED and D26 MantaXT looks like. I marked the difference in yellow. Note that using the lower table gives me a lot of extra FSB on the Merlin bios vs. Trats (260 vs. 245Mhz). So the magic must happen in the upper half of the romsip table at offset 100h to 180h. I didn't use a multi for testing which is affected by the 1510 vs. 1518 setting (multi 10 to 12.5 i guess).

Now i should probably use a single lower half table and combine it with the different upper half tables... And then dump chipset registers with WPCRedit i guess...  

 

Edited November 7, 2019 by Tzk

[I.nfraR.ed]

Yes, that's what I'm currently experimenting with. You can see values changing in b0d0f3 and b0d0f4. Perhaps something else too.

I'm only testing at one multiplier (x6) and changing things one by one to hopefully see some relations to affected values and their effect.

That upper half of the table is changing things you can't change on the fly with wpcredit.

If you search for 65 D0 16 (start of a romsip table), you can see that there are some additional tables in the  decompression block, but not sure what they are - perhaps these are the failsafe tables.

There are other long tables just under the main romsip tables with bytes that are repeated 4 times each, e.g.

09 09 09 09 25 25 25 25 0D 0D 0D 0D 36 36 36 36

I'm now using a faster method of editing for faster testing. Open the bios rom with modbin and leave it open. It extracts original.bin - this is the main bios decompressed.

Change the table of interest with hex editor in original.bin and then save the bios from modbin. It compresses it back and corrects the checksum.

 

@Tzk Regarding the ISA/PCI option rom, you can check D26 Black mantarays bios for NF7, there's a very small custom ISA option rom (Black.bin).

Perhaps you can take that as a base if you disassemble it.

Edited November 7, 2019 by I.nfraR.ed

[Tzk]

I just built some custom romsips with the upper half of D26 Mantarays XT, Taipan EBED and Trats 1008mod3 while keeping the lower half of Taipan EBED. B0D0F0, F2, F3 and F4 differ while B0D0F1 and F5 stay the same. However on B0D0F4 the only difference i get is A4h and A5h, everything else is identical. So no different Slewrate or DriveStrength.

Aren't these repeating values below the romsip just some padding bytes or placeholders? Regarding the other tables: DFI got 10 tables while all other boards got 6. Maybe the tables inside the decompression block are used as defaults during boot or when cmos defaults are loaded? 

I know about the modbin method, but on winxp i can't overwrite the original.bin while modbin is open. You keep modbin open and modify original.bin while modbin is still running in the background?

I'll have a look at the Blackmantarays bios, thanks for pointing that out!

EDIT: Looks like the black.bin patches some pci registers as it writes to 0xcf8. TicTac might use this for the Cpu Disconnect Patch which is mentionen in the readme. If i got it right he writes to Cmos register 0C, 48 and 6C. Still might be a good idea to just modify this for my custom code.

Edited November 7, 2019 by Tzk

[TerraRaptor]

33 minutes ago, Tzk said:

DFI got 10 tables while all other boards got 6

Just a quick note - Biostar boards had 14 entries if I'm not mistaken:)

[I.nfraR.ed]

Yes, but using a newer modbin 2.04.03 - that might be the difference.

I have disassembled the main bios file, but that's a lot to comprehend for my little brain. I've done ARM kernel disassembly and reverse-engineered some of the driver calibration data before, but that nforce2 bios has too many and I don't know where to start. 

Edited November 7, 2019 by I.nfraR.ed

[Tzk]

Ah well. I refused to use the newer modbin 2.04.03 because i disliked the new design. You can't see selections on the item tree anymore... That's why i stuck to 2.01.02.

I also try to stay away from disassembling the system bios as it seems to be a mess of legacy (spaghetti) code plus some legacy limitations due to x86 architecture and several relocations of code during boot + decompression trickery. It's a mess... There's the source of an older award 4.51 bios somewhere on the internet, but we're on 6.0. So the general bios layout and structure will be similar but details will differ. Pinzakkos site is a great source for the bios structure though.

 

EDIT:

Here's what black.bin from blackmantarays does. It basically loads different registers and uses the different subroutines to push data through the PCI address- and dataport. All used subroutines look similar, but with variing ports. This looks like the examples shown on the PDF i linked, but uses subroutines to reduce code duplication.

 

Edited November 7, 2019 by Tzk

[I.nfraR.ed]

Yes, if we had the documentation about different MSR and index/data offsets for DRAM controller we could set things with a custom ISA rom.

I think (based on the disassembled bios), index/data for one of the extended DRAM controller is 70h/71h, but don't know the base address.

If we knew what each bit is, then setting registers is not that hard, basically using bitwise operations and toggling multiple bits in eax using masks, then write back.

I know the concept and use it in ZenStates app, but it's not assembly.

Edited November 7, 2019 by I.nfraR.ed

[Tzk]

Well, for Slewrate, Drive Strength, SuperBypass and a few other registers we do know this, right?

What i'm currently missing is the link between the bus-device-function adressing scheme and an adress like 08000C28Ch. Am i correct that this is a pci address in the pci address space? So converting this adress to binary leads to 32bits and those 32bits can be mapped to b-d-f adressing?

Example:

08000C28Ch is ‭10000000000000001100001010001100‬ in binary. Let's split this into parts as described here: https://wiki.osdev.org/PCI#Configuration_Space_Access_Mechanism_.231

result: ‭1 0000000 00000000 1100 0010 10001100

this translates to:

• enable bit is set
• bus is 000 -> 00h
• device is 1100 -> 0Ch
• function is 0010 -> 02h
• register is 10001100 -> 8Ch

As the address was 08000 C 2 8C h this result isn't unexpected, i guess.

 

Or are you trying to inject code at an earlier stage of the boot procedure? So like manipulating Dram settings while the bios load the initial values?

Edited November 7, 2019 by Tzk

[I.nfraR.ed]

Yes, that sounds about right. You configure the desired PCI device register by using the two 32-bit registers PCI_CONFIG_ADDRESS and PCI_CONFIG_DATA in the I/O space.

As you have shared (and you can see from tictac's code), the ADDR register is at 0xCF8 and DATA is 0xCFC.

The address register format is:

0x80000000 | bus << 16 | device << 11 | function <<  8 | offset

So e.g. 0x8000006C is bus 0, device 0, function 0, offset 6C.

The problem is we only know some of the registers/bits, but others are unknown. What I mean is it would be helpful if we had some sort of a bios and kernel develompent guide for the nvidia chipset. Not all combinations of bits are valid. Usually, if you want to turn on or off certain feature, you need to set several related bits in some register.

 

PS: Actually it says lowest 2 bits should always be 0, so the address offset is then the rest 6 bits?

Edited November 7, 2019 by I.nfraR.ed

[I.nfraR.ed]

More on the ROMSIP.

Testing with XP-M 2500+ and x6 multi. Usual ED multiplier tables, it appears the 133MHz (CPU Interface ON) is loaded.

So far, so good. Loads Windows at ~270MHz and goes half way through Pi 1M, but almost impossible to finish it without error. That's what I was experiencing and what I expect.

Changing the top part of the particual table with the same part from stock 133MHz table makes the board a little faster, but also drops the maximum FSB to about 240MHz.

It seems this is the key for high FSB and that's why modded bioses work - they use the 200MHz table for all.

Based on these tests, I think we need to:

- Make one "performance" bios with tighter tables for CPUs that are benched at lower FSB and another bios for high FSB, basically 200MHz table copied to 166 and 133 tables (most of the modbioses)

- Try to slacken the first part further to allow higher FSB, even with small performance loss (still should be better for super-locked low-multi CPUs). Good for validations, too

- Maybe even combine both in one bios, e.g. use the high FSB tables for CPU interface on or off and the performance tables for the other one. Have to check if the difference between CPU Interface ON/OFF is just the tables or it affects the performance in other ways too.

PS: That's why L12 hard mod worked as well - making the CPU detect as 200MHz default FSB, so the bios loads 200MHz table, which then allows higher FSB.

Edited November 8, 2019 by I.nfraR.ed

[Tzk]

Well, we know all Timings in NF2 Tweaker if we a/b test them one after the other. Iirc most NF2 Tweaker Alphatimings are 4bits while for example Tras is 8bits. And if someone brave tests all available bios options on Abit and/or DFI we probably get most of them.

This might also be of great help (ISA option rom sourcecode):

http://www.xtremesystems.org/forums/showthread.php?109834-AMD-Athlon-64-DDR-ROM-Patcher

Yes, you basically want to reverse the Soft-L12 mod. Most modbios have the 200Mhz tables copied to 133 and 166Mhz, so every cpu can reach high fsb. This makes sense for unlocked cpus but will make the performance on superlocked cpus suffer. If you got enough time you could even tweak a bios for like every 10Mhz of FSB (one for ~200Mhz, 210Mhz,...) to get maximum bandwith/efficiency for low-fsb cpus. Especially superlocked Cpus with high multi and low stock fsb might profit from this.

Interesting observation that the top half of the table seems to allow for more/less fsb. I thought it's mainly the lower half which helps fsb. I built 3 romsip versions yesterday and might try max. FSB on them. I made D26 Mantarays XT upper half + EBED lower table; full EBED table and trats 1008mod3 upper + EBED lower half. Might be interesting to see how the max. fsb behaves on all of them, especially since my northbridge is definitely limiting my max. FSB. I need to increase Vdd to >1.8V to reach 255Mhz+, else i get errors in Memtest Test 7. I can't even get 2x512mb TCCD stable above 250MHz while 2x256mb Winbond is perfectly stable at 260MHz+.

Edited November 8, 2019 by Tzk

[Tzk]

I did a quick comparison between my modded romsips. Base is Taipan EBED romsips + 3.19 BPL, CPC on. I then swapped the first half of the romsips to Trats 1008mod3 and D26 Mantarays XT while keeping the 2nd half of EBED. Setup is A7N8X Dlx, random Tbred B, 1x512mb TCCD (Geil Ultra-X) 3-4-4-8 and Memtest v5.01. I tested Test #7, as this seems to be the indicator if the chipset is stable or not. Vdd was 1.85V, Vdimm 2.7V. Results:

EBED: 255Mhz pass, 260Mhz fail

Trats: 250 pass, 255 fail

MantaXT: 245 pass, 250 fail

So it looks like the upper half alone gives me a 10Mhz increase in stable fsb when going from MantaXT to EBED. I'll post the exact romsips i used later.

 

Edited November 8, 2019 by Tzk

[I.nfraR.ed]

I've seen that code and it is quite easy to understand and modify. We can modify it to support all known timings (and other things) for nforce2, however we can already control most of them with windows tools (memset, nf2 tweaker, wpcrset). Worth trying super bypass and data scavenged rate though. Is there a known Tref for nforce2?

On the romsip topic - try with one really tight upper half (some 133 table) and see if your FSB drops dramatically as well. Based on this research, I believe native 200MHz CPUs would work good even with stock roms (unless the multiplier table is completely broken). Back in the days those 200MHz locked CPUs were rather limited in frequency by the high multi x 200 FSB combination. And there are just a few 200MHz models. It was all about 133 and 166MHz cpus.

I have tried to change some of the bytes in a table, but it was not booting. e.g. (using @TerraRaptor's screenshot)

Changing byte 12h to 49 or 89 was no POST, 61 and 69 works (have seen both in tables). The problem is we don't know what are these.

PS: Ah, CPU Interface doesn't seem to work on NF7 bios, it always loads the "Disabled" table. That's why I never saw a difference between them - same performance, same max FSB. Have to try if it is broken after the bios menu rearrangement, though. Will have to test with a stock bios.

Edited November 8, 2019 by I.nfraR.ed

[Tzk]

If Tref setting is available on NF2, then it is unknown. As we can control Alphatimings, i'd try to get Slewrate, Drive strength, SuperBypass and DataScavenged Rate working. Sadly NF2 Tweaker source isn't available and thus we have to manually find the registers. Afaik DFI has them in bios, so this might be a way to find them.

Here's what i used for my comparison of romsips. I combined the blue first half with the orange 2nd half. Left is trats, middle is EBED and right is mantarays XT.

Next up i'll swap the A7N8X and try my NF7. Maybe i can get it into a working state. And i'd like to try Merlins Bios, as up to now i mostly ran Mantarays XT.

[I.nfraR.ed]

Merlin had been better for me before I made mine, which is very similar anyway.

Slew rate and drive strengths can be modified with wpcredit, so I was thinking of using ISA rom to only set SuperBypass and DataScavenged Rate as a starting point. The thing is those registers show different on the NF7 and I'm not 100% sure which bits need to be changed in the whole byte. Will have to test with the DFI board in order to get a better understanding. As for the NF2 Tweaker I can easily make a new similar app to control all timings, since we know the registers already. And there's a openlibsys to help with MSR and PCI read/write operations. I can use the ZenStates app as a base.

On a side note, I got 15 sticks of DDR (11 on this picture), but not a single one is Winbond. One of the 2x512 OCZ PC4000 Gold Rev2 (should be Hynix) actually play very nicely on NF2 with default 2.5-3-3-8 1T, but that's not what I'm searching for. Was able to boot 265MHz.

Also got the MSI KT880 Delta-FSR, which seems in very good condition, except the CPU VRM capactors, which are bulged and need replacing. Way better built than the Asrock board.

Edited November 8, 2019 by I.nfraR.ed

[Tzk]

I just tried combining the romsips to see if there is any effect, especially since i knew that Trats and Mantarays is clocking worse than Taipan on my asus... And i found that the limit indeed is lower on both. Haven't had a look at your tables up to now.

If you need further data for the registers i can dump via wpcredit on my a7n8x dlx and a7n8x-x. Just tell me which registers you need. If you could make the newer settings work in Zenstates app that'd be awesome. I've had a brief look for A64 Tweaker and NF2 Tweaker sources, but it seems like CodeRed never released those to the public.

I haven't had time to actually test a custom ISA rom, but that's my next goal: to get an ISA rom for DriveStrength, Slewrate, SuperBypass and DataScavengeRate working and on top of that read Cmos registers and set these settings depending on the cmos register content. That way i should get fully working bios options for those. The b-d-f registers itself should mostly consist of 4bit settings. So either the upper or lower half of the bytes are used for a single setting (except settings like Tras with >8 choices). Afaik the right half of settings on NF2 Tweaker are all 4bits. Tras, Trc, Trfc and the AGP/PCI latency should be 8bits. DriveStrength and Slewrate too. Not sure about SuperBypass and DataScavengedRate, but i'd guess 4bits.

Again some code i found for option roms: https://gist.github.com/DruckiMcDruck/10d22bef2ac6ed1673ff15210c8aefb8

And here's a list with registers i found on different forums so far: https://gist.github.com/DruckiMcDruck/01174f3cd2bc2c1df6a7aa366060f304

Edited November 9, 2019 by Tzk

[TASOS]

Excellent work you doing here (everybody involved).

It's really nice to see that after so many years , there is still passion about making this platform gen , even greater than before (better than it's glory days).

But i noticed that there is no Hellfire love in this effort ... why so ?