VOGONS


First post, by Paul_V

User metadata
Rank Member
Rank
Member

Hi,

I'm writing this as a last resort in attempt to get some help downclocking AMD Geode LX800 CPU.
I've been tickering with it for quite a while and seem to hit a brick wall.
As the time goes by, my gathered knowledge of it starts to fade and would hate to just quit now without at least sharing some findings.

Test subject:
For testing, I've been using a motherboard from Fujitsu Siemens Futro thin client: TR2350
It comes with Insyde XpressROM BIOS, which is basically useless for retro rig use.
I managed to find compatible BIOSes from AMI and AWARD (even Insyde too, but it's a PITA to mod), which even allow to change CPU\GeodeLink multipliers (1 to 32)

My goal:
Devise a way to downclock this CPU as low as possible, using it's multiplier settings, as it would make it very versatile speed wise.

A couple of findings so far:
1) A big collection of dev board firmware from AMI, one of which fit TR2350 perfectly. Which is expected, because the design is almost similar to AMD development board.
https://www.ami.com/resources_with_downloads/amd/
2) You can change the multiplier on the fly by editing MSR registers to some extent. They are listed in LX800 Databook
3) Native 1600x1200 under DOS (I have no way of determining whether it is 320x200 or 740x400 or any other resolution that is scaled to 1600x1200 though)
4) It can run either 33 or 66Mhz PCI bus, has internal PLL divider (you can get same frequencies with ether lower multiplier without divider, or do PLL/2 and higher mult. number)
5) RAM bus speed is dependent on Geodelink multiplier.
6) Databook (datasheet) links
https://www.amd.com/content/dam/amd/en/docume … LX_databook.pdf

My problem:
Lowest CPU stable speed I got is 166Mhz (33x5). Lowest unstable is 133Mhz (33x4)
By trial end error, I'm pretty sure now that LX800 CPU clock:
a) Cannot be lower than PCI bus clock (which is 33 or 66Mhz, depending on hardare straps etc).
b) Cannot be lower than DDR base clock. (which is the source of my problem)

DDR introduced so-called Delay-Locked-Loop circuit (or DLL in short) to make it stable at intended clock speed.
But there is a catch - DLL stops working at lower speeds thus, preventing DDR init at speeds lower than 125Mhz (according to JEDEC specs)
So, without disabling DLL, the lowest DDR speed is 33x4 (stable) or 33x3 (unstable, basically unusable)

Probable solution (And that is where it gets painfull)
DLL can be disabled without causing stability issues, provided the clock speed of DDR is relatively low.
All the info about disabling DLL is mentioned in the datasheets.
Except there's one small detail: DLL state is programmed by BIOS during hadrware initialization.

Which means I have to basically disassemble the bootblock, find memory init routine and disable DLL (easy peasy, huh?)
And that is way above my current programming and BIOS skill levels.
Maybe there's a compiled menu option in the code, which is not exposed. (because I've checked all BIOSes for hidden options to no avail)
There were some promising leads to extract all possible compiled AMIBIOS8 options using AMISCE, but unfortunately, my BIOS version is not compatible.

So here I am. Basically crying out loud for any experienced BIOS modders\programmers help or advice )
Maybe someone can point to an alternative solution to disable DLL? Low level BIOS programming is not something you can do on every LX800 board you find.

Both AWARD and AMI compatible BIOSes are in the attachment.

Last edited by Paul_V on 2024-09-18, 08:53. Edited 3 times in total.

Reply 1 of 12, by kmeaw

User metadata
Rank Member
Rank
Member

Looking at 03/19/08 XpressROM BIOS.
raminit is f000:7dbe - set the clock drive strength and shift value, mask the clocks; located at 0x77dbe in the ROM chip and that subroutine starts with "mov fs,bx; mov al,70h".
f000:7f25 resets the DLL ("or eax, (1<<0) | (1<<27)") - if I got the documentation right, you can try changing it to "or eax, (1 << 0) | (1 << 24) | (1 << 27)" to set EMR_DLL to 1 - that would be changing 66 0d 01 00 00 08 to 66 0d 01 00 00 09.

Reply 2 of 12, by Paul_V

User metadata
Rank Member
Rank
Member
kmeaw wrote on 2024-09-02, 15:59:

Looking at 03/19/08 XpressROM BIOS.
raminit is f000:7dbe - set the clock drive strength and shift value, mask the clocks; located at 0x77dbe in the ROM chip and that subroutine starts with "mov fs,bx; mov al,70h".
f000:7f25 resets the DLL ("or eax, (1<<0) | (1<<27)") - if I got the documentation right, you can try changing it to "or eax, (1 << 0) | (1 << 24) | (1 << 27)" to set EMR_DLL to 1 - that would be changing 66 0d 01 00 00 08 to 66 0d 01 00 00 09.

Thank you!
I've modified the value. The BIOS works, but downclocking doesn't.
When I read MSR 20000018h, I get "10077113 01004840". And if I read that correctly, it indicates, that bit 24 is zero. Meaning DLL is still enabled

Also, I found "66 0d 01 00 00 08" string in AMI BIOS, maybe they have similar raminit routines

Last edited by Paul_V on 2024-09-03, 15:47. Edited 2 times in total.

Reply 3 of 12, by MikeSG

User metadata
Rank Member
Rank
Member

You can program BIOS registers using DOS programs, too, if it's stable enough to get that far.

Code in any program in plain c. To compile, I use the Watcom Build Environment (DOS box interface in windows). "wcl -os -lr -bcl=DOS compileme.c"

Reply 4 of 12, by Paul_V

User metadata
Rank Member
Rank
Member
MikeSG wrote on 2024-09-03, 13:35:

You can program BIOS registers using DOS programs, too, if it's stable enough to get that far.

Code in any program in plain c. To compile, I use the Watcom Build Environment (DOS box interface in windows). "wcl -os -lr -bcl=DOS compileme.c"

I've already tried programming "load-mode" MSRs, described in the datasheet. System just freezes.
If I'm correct, no memory calls can be made during DLL programming. And I'm not sure it can be done in DOS.

Reply 5 of 12, by rasz_pl

User metadata
Rank l33t
Rank
l33t

Yeah, to say touching memory controller while running from ram is tricky is an understatement.
There might be multiple points in BIOS where its being initialized. For example f000:7dbe could be safe defaults, but later bios loads something else from a table.

https://github.com/raszpl/FIC-486-GAC-2-Cache-Module for AT&T Globalyst
https://github.com/raszpl/386RC-16 memory board
https://github.com/raszpl/440BX Reference Design adapted to Kicad
https://github.com/raszpl/Zenith_ZBIOS MFM-300 Monitor

Reply 6 of 12, by kmeaw

User metadata
Rank Member
Rank
Member

Could you try setting EMR_DLL at the same time when MSR_BA is set to "01"?
To do that you need to update the MC_CF07_DATA register one load-store cycle before you did the previous change: at f000:7f0d change "66 0d 01 00 00 10 0f 30 66 25 fe ff ff ef" to "66 0d 01 00 00 11 0f 30 66 25 fe ff ff ee".

Reply 8 of 12, by Paul_V

User metadata
Rank Member
Rank
Member
kmeaw wrote on 2024-09-03, 23:47:

Could you try setting EMR_DLL at the same time when MSR_BA is set to "01"?
To do that you need to update the MC_CF07_DATA register one load-store cycle before you did the previous change: at f000:7f0d change "66 0d 01 00 00 10 0f 30 66 25 fe ff ff ef" to "66 0d 01 00 00 11 0f 30 66 25 fe ff ff ee".

Thanks! Applied the changes. It does not boot now.
The problem is - I cannot change default DDR clock in XpressROM beforehand, so the issue also may be that the clock is too high for it to init without DLL.

However, both AMI and AWARD BIOSes have exact same HEX values in their ROMs.
I'll try to set their default CPU and RAM clock as low as possible first, then try to edit DLL.
It will take some time to run all the tests, I'll post the results ASAP.

P.S. Also, if someone owns a motherboard (any brand or CPU), which has DDR SDRAM and a BIOS which allows to disable DLL on boot, a dump would be highly appreciated. I've seen some screenshots during my searches, so they do exist. I could then modify it's default setting and compare the dumps to see what exactly changed in binary code

Last edited by Paul_V on 2024-09-04, 07:50. Edited 1 time in total.

Reply 9 of 12, by Paul_V

User metadata
Rank Member
Rank
Member

Here's a DDR to DDR2 BIOS porting guide for LX.
It has a more thorough description of ddr init sequence.

Reply 10 of 12, by Paul_V

User metadata
Rank Member
Rank
Member
kmeaw wrote on 2024-09-03, 23:47:

Could you try setting EMR_DLL at the same time when MSR_BA is set to "01"?
To do that you need to update the MC_CF07_DATA register one load-store cycle before you did the previous change: at f000:7f0d change "66 0d 01 00 00 10 0f 30 66 25 fe ff ff ef" to "66 0d 01 00 00 11 0f 30 66 25 fe ff ff ee".

No luck as of yet.
All BIOSes refuse to boot after modification, no matter which CPU\RAM clock is set.

Reply 11 of 12, by StefanPutureanu

User metadata
Rank Newbie
Rank
Newbie

Hi. I finally got some time and I have extracted the System ROM from AWARD 3517R115.bin file that you provided. The DLL MSR is referenced by this ROM in a function at offset 0xA802. The MSR 18000020 (little endian hex value) can be found 43 times in the BIOS dump file, but I like to use the AWARD tool to extract one ROM at a time and reverse it with IDA. The System ROM reference's this DLL MSR only 5 times. There might be other ROMs where this MSR gets a value. But it takes time to disassemble all the ROMs.

This is the AWARD tool that I've used to extract the System ROM:

The attachment 2024-09-27-17-40-38-475_1.jpg is no longer available

And this is the code at 0xA802 offset:

The attachment 2024-09-27-17-41-47-171.jpg is no longer available

Here the MSR is referenced 4 times and are only read instructions. Returned values gets computed and then there is a call to offset 0x8AAE where there is another call outside of this ROM at F000:1633 where the MSR might be written by other ROM.

This ROM has 131.072 bytes, is a big ROM and it takes time to disassemble it in IDA. There might be a function that set this DLL in there.
If you have time you can do the disassemble by yourself. Use the AWARD tool to extract all the ROMs, open them in a hex editor and search for the 18000020 hex value. If you find one then it might be that that ROM has a function for this DLL.
Open that ROM in IDA or Ghidra and have a look at what is doing. Then you can patch that ROM in the hex editor and put it back in the BIOS dump with the AWARD tool.
Whenever I'll have time I will continue to search for a solution.

Reply 12 of 12, by Paul_V

User metadata
Rank Member
Rank
Member
StefanPutureanu wrote on 2024-09-27, 15:22:

Hi. I finally got some time and I have extracted the System ROM from AWARD 3517R115.bin file that you provided. The DLL MSR is referenced by this ROM in a function at offset 0xA802. The MSR 18000020 (little endian hex value) can be found 43 times in the BIOS dump file, but I like to use the AWARD tool to extract one ROM at a time and reverse it with IDA. The System ROM reference's this DLL MSR only 5 times. There might be other ROMs where this MSR gets a value. But it takes time to disassemble all the ROMs.

Thank you very much, StefanPutureanu, for all your help.

I'll certanly try to inspect this further.
Those endless jump points is what certanly complicate things.

By the way, the AWARD editor you are using is prone to corrupt BIOS images if you try to import the ROMs back, but the export function works fine.
I use it frequently to quickly check the contents and menu structure.
To put tem back and recalculate the CRC I use CBROM.

You also mentioned, that INSYDE eXpressROM had 2000.0018 referenced in the boot block itself. Would it be easier to navigate than AWARD?
I've attached the compatible BIOS for my test motherboard.

Disabling DLL to downclock CPU is just my theory yet. So I think it would be best to choose the easiest ROM to work with, in case it won't work.