________________________________
I have 4 sticks 256MB dual rank of IBM branded RAM and and CUBX-L motherboard.
BUT,
1 - Micron, 2 - Infineon, 1 - Hunix.
And they all have quite different SPD.
SPDtool reports an incompatible SMbus driver.
Frankly, I don’t want to solder, because the stick do not have a standard SOIC-8 case, but a miniSOIC.
In general, I need a program for DOS or Windows that works with 440BX for write SPD to RAM.
Definitely, I want 1GB of RAM on 440BX with a bus speed of 133MHz. 😀
Attachments
Last edited by shevalier on 2023-06-25, 10:54. Edited 2 times in total.
There is no need to desolder the SPD ICs in order to reprogram them, as they are directly accessible via the edge connector. You can use a spare DIMM slot or any dead motherboard and wire it to the programmer.
There is no need to desolder the SPD ICs in order to reprogram them, as they are directly accessible via the edge connector. You can use a spare DIMM slot or any dead motherboard and wire it to the programmer.
AIDA64 reads SPD normally, which means that all circuits are wired and functioning.
Really no one wrote a utility in those years?
DMI BIOS Version : ASUS CUBX-L ACPI BIOS Revision 1008 Beta 004
>ASUS CUBX-L
Asus is special, it locks SPD bus out. you have to specifically enable it. Most tools like Everest/AIDA/Astra/Sandra/CPUZ have this code. They share i2c bus between clock generator/monitoring chip and ram SPD using a mux. If you switch this mux and forget to switch it back computer will have trouble rebooting because bios blindly assumes its always set to clock gen.
I know this because I emailed cpuz author code to do this back in 2007 when noticing cpuz wasnt reading A7V133 😀 Wasnt my code, I think I got it from Everest author (tamas.miklos@lavalys) after helping him debug 😀 Everything started with my lm-sensors bug report because Linux couldnt access spd 😀 https://marc.info/?l=lm-sensors&m=117538100315786&w=2
Everest Ultimate 5.50 had a bug where it would unlock SPD, but not lock it again - this might be your in, try to find and install this very version and the bug might still be there 😀
ASTRA32 was another program in 2007 that unlocked SPD bus on ASUS boards and didnt bother to lock it back up. I also let the author know about the rebooting problem and a fix. https://marc.info/?l=lm-sensors&m=117544836806201&w=2
looks like SPDINFO.EXE was part of sisoftsandra and is able to unlock SPD bus on Asus boards. https://forum-index-hu.translate.goog/Article … &_x_tr_pto=wapp
>Sisoft Sandra's professional DOS program SpdInfo.exe , which, if you don't want to run test programs, you should definitely get (70kB) (part of Sandra)
I dont know where to get it now 🙁
TLDR:
1'CUBX' 2 3enable SPD 4 temp = inb_port($e437); 5 outb_port($e437,(temp & 0xe7) | 0x08); 6 7disable SPD 8 outb_port($e437,temp);
you should be able to do this in dos with debug.exe on with pciset under windows xp
debugging with Everest author:
From: RusH
Date: Mon, 2 Apr 2007 01:55:18 +0200
Subject: Re: read the spd on A7V133
To: "Tamas MIKLOS (Lavalys)" <tamas.miklos@l […] Show full quote
From: RusH
Date: Mon, 2 Apr 2007 01:55:18 +0200
Subject: Re: read the spd on A7V133
To: "Tamas MIKLOS (Lavalys)" <tamas.miklos@lavalys.com>
Hi. First I want to thank you VERY much. You saved me a ton of
hacking, poking and proding.
> I've just checked the BIOS image of A7V133, and found out that it only
> alters bit0 of E44C, so please try to use this trick, and let me know how it
> works. If it doesn't cause issues about reboot, then I'll modify EVEREST
> according to this, and send you a new beta so you can try if it eliminates
> the reboot issue.
original
rasz@capek:~$ sudo isadump -f 0xe440 16
0 1 2 3 4 5 6 7 8 9 a b c d e f
e440: 10 00 00 00 71 00 00 00 fd 02 c0 00 ff f6 ff 0f
rasz@capek:~$ sudo i2cdetect -y 0 |grep 50
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
bit 0 0xe44c
rasz@capek:~$ sudo isaset -f 0xe44c 0xfe
rasz@capek:~$ sudo isadump -f 0xe440 16
0 1 2 3 4 5 6 7 8 9 a b c d e f
e440: 10 00 00 00 71 00 00 00 fd 02 c0 00 fe f6 ff 0f
rasz@capek:~$ sudo i2cdetect -y 0 |grep 50
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
method 1 from your code (bit 4 0xe44c)
rasz@capek:~$ sudo isaset -f 0xe44c 0xef
rasz@capek:~$ sudo isadump -f 0xe440 16
0 1 2 3 4 5 6 7 8 9 a b c d e f
e440: 10 00 00 00 71 00 00 00 fd 02 c0 00 fe f6 ff 0f
rasz@capek:~$ sudo i2cdetect -y 0 |grep 50
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
method 2 from your code (bit 0 0xe44d)
rasz@capek:~$ sudo isaset -y -f 0xe44d 0xf7
rasz@capek:~$ sudo i2cdetect -y 0 |grep 50
50: 50 51 52 XX XX XX XX XX XX XX XX XX XX XX XX XX
succes. So its bit 0 of 0xe44d. Now ill try to reboot.
... bzz bzzz ...
ok, reboot successful. So its not this. Something else is very aggressive.
Looking at "overclocking" tab it might be timings reading. BTW Why do
you display only one line of timings? KT133/133A can have 4 dimm
slots, every single one with its own timings (regs 0x64-0x67). It
would be more helpfull to display 4 separated readouts.
Or it can be clock generator probe, its ICS 94215AF, propably also on
smbus(?). I dont know if I remember right, but I think everest was
displaying ICS 94215 (without AF), I cant find AF datasheet, all I
have is plain 94215 and YF-T.
Anyway Im ready for you to throw some debug version at me to test
which part will make computer hang on reboot.
1From: "Tamas MIKLOS (Lavalys)" <tamas.miklos@lavalys.com> 2Date: Sun, 1 Apr 2007 23:27:00 +0200 3Subject: Re: read the spd on A7V133 4To: RusH 5 6Hi, 7 8I'm sending you the Asus SPD multiplexing code in my next email. Let me 9know what happens if you try to manually alter the relevant bit(s), ie. if 10it causes issues with the reboot, just like with EVEREST. 11 12Var 13 AsusSPDMethod,AsusSPDValueB1,AsusSPDValueB2 : Byte; 14 AsusSPDValueD : DWord; 15 16Procedure EnableAsusSPDSub(method:Integer); 17 18Begin 19 AsusSPDMethod :=method; 20 AsusSPDValueB1:=0; 21 AsusSPDValueB2:=0; 22 AsusSPDValueD :=0; 23 24 Case AsusSPDMethod Of 25 1 : Begin 26 AsusSPDValueD:=Port_ReadDWord($E44C); 27 Port_WriteDWord($E44C,(AsusSPDValueD And $E7FFFFFF) Or $08000000); 28 End; 29 30 2 : Begin 31 AsusSPDValueB1:=Port_ReadByte($E44D); 32 Port_WriteByte($E44D,(AsusSPDValueB1 And $F6) Or 1); 33 End; 34 35 3 : Begin 36 AsusSPDValueB1:=Port_ReadByte($E437); 37 Port_WriteByte($E437,(AsusSPDValueB1 And $E7) Or 8); 38 End; 39 40 4 : Begin 41 AsusSPDValueD:=Port_ReadDWord($E44C); 42 Port_WriteDWord($E44C,(AsusSPDValueD And $FFFFF6FF) Or $100); 43 End; 44 45 5 : Begin 46 Port_WriteByte($2E,$87); 47 Port_WriteByte($2E,$87); 48 Port_WriteByte($2E,7); 49 Port_WriteByte($2F,8); 50 Port_WriteByte($2E,$F1); 51 AsusSPDValueB1:=Port_ReadByte($2F); 52 Port_WriteByte($2E,$F1); 53 Port_WriteByte($2F,(AsusSPDValueB1 And $E7) Or $10); 54 Port_WriteByte($2E,$AA); 55 End; 56 57 6 : Begin 58 AsusSPDValueB1:=Port_ReadByte($EC80); 59 Port_WriteByte($EC80,(AsusSPDValueB1 And $EF) Or $10); 60 AsusSPDValueB2:=Port_ReadByte($EC84);
1From: RusH 2Date: Tue, 3 Apr 2007 11:21:25 +0200 3Subject: Re: ASTRA32 uninstall 4To: Support <support@sysinfolab.com> 5 6On 4/3/07, Support <support@sysinfolab.com> wrote: 7> Hello, 8> 9> Sunday, April 1, 2007, 8:09:43 AM, you wrote: 10> 11> cgc> SMBus probing is too aggresive, it breaks Asus boards (A7V133 12> cgc> for example) = computer cant succesfully reboot, it hangs. 13> 14> Thank you for the bug report. 15> Please send astra32.log file from 'My Documents' folder. 16 17I dont have one, I allready uninstalled, but I can tell you what was 18wrong (and can test fixed binary if you like) 19 20> cgc> On the other hand you use some hack to enable SPD readout on 21> cgc> this board, I would love to know what it is to backport it to lm-sensors. 22> 23> You can see this method in the BIOS. 24 25Yes, I digged to it in the mean time (gpios are defined in the ACPI DSDT). 26 27Back to problem with astra. To enable SPD readout you flip bit 0 in 280xe44d to 1 - that switches asus smbus mux to spd channel, but you 29forget to switch it back to 0 and the board cant reboot properly ( I 30know this because when I scan smbus before running astra I see only 31hwmonitor, after running it I see only spd roms). No idea why the 32board doesnt like it, maybe bios has to talk with sensor/clock chip 33(both of them have watchdogs) and expects it on the smbus without 34making sure mux is set properly.
Thanks for the solution.
Micron flashed perfectly, Hunix - it turns out that already in those years the first 128 bytes were locked for writing.
But, no luck.
124MHz FSB - ok, 133 - or RAM error, or no detect 1 stick.
Moreover, at any voltage - 3.4 / 3.5 / 3.65 Volts.
Need to look for and select other RAM sticks.