Hello, I am having a problem with raminit.c reading SPD data. When I use the smbus_read_byte function it is only returning a value of 0xFF.
smbus_read_byte(ctrl->channel0[i], 2)
No matter what SPD Byte I try I am just getting 0xFF. What could this be? Please help.
On another note I am finally getting console output on the i82830 chipset:-) Getting closer....
Thanks - Joe
Joseph Smith wrote:
your i2c bus functions of the southbridge code don't work.
Quoting Stefan Reinauer stepan@coresystems.de:
Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx src code. Corey, mabe you could shed some light on this?? Here is my serial console output, where it says "SPD is ff, ff, ff, ff" I just tried a bunch of different SPD bytes to see the return values.
LinuxBIOS-2.0.0.0Fallback Sat Aug 11 01:30:14 EDT 2007 starting... Setting Initial Registers.... Initial registers have been set. SPD is ff, ff, ff, ff No DIMM found in slot 00, Setting DRA to 0xFF DRA 70 has been set to ff SPD is ff, ff, ff, ff No DIMM found in slot 01, Setting DRA to 0xFF DRA 71 has been set to ff RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x00000000 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 20 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 00 00 00 00 00 00 00 30 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff ff ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 70 d7 d4 00 00 00 00 90: 02 38 00 01 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 fc 14 00 00 f0: 11 11 01 00 00 00 0d 05 37 d6 30 d3 1f cf 1e Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. SMBus controller enabled
Thanks - Joe
* Joseph Smith joe@smittys.pointclark.net [070811 18:52]:
Hm. maybe the spd roms are on a different position then. I think Corey's code is known to work. They're usually at 0x50...0x53 but that may be different on any other board.
Quoting Stefan Reinauer stepan@coresystems.de:
How would I go about finding out what it is on my board??
Thanks - Joe
Stefan Reinauer wrote:
Yeah, the code works for me, and was a hack up of the other 82801s, so it should work for just about any. Can you do me a favor and check that the smbus device is located at device 0x1f (ie 31) function 3? That was one big assumption I made, I checked most of the datasheets but not all of them, and datasheets do lie. I did throw in a check just as a failsafe, but that may not have worked either. Also check your factory bios's smbus IO base, it should be programmed at d31f3 rx20-21, and will have an extra 1 at the end. If that's not 0x0f00, then try plugging it in as SMBUS_IO_BASE in i82801xx.h.
The current code also makes no attempt to do give any sort of warning if an smbus timeout/error occurs. It was something that I wanted to do, but other things came up. You could probably drop in some debugging info there, as the functions already do return negative values in case of an error. The other thought is, run smbus_enable before enabling serial/console, and also try to force a full smbus dump using the debug.c that I left in with the i82810 (oops, meant to move that). It may be that your smbus needs a little time to initialize, if you're smbus dump starts pulling good values after the first few transactions, this is the case. It it is, let me know and I can take care of it, and for the time being just do an smbus dump before attempting to do ram init.
Last thought is, make sure your dimm actually has spd. I've never seen a dimm that didn't, but that doesn't mean they don't exist, especially with older sdram, and doesn't that board use so-dimms? lm_sensors dimms-detect.pl should be able to tell you if there is spd info to be found, and also the location of the spd. If I get some time, create a little program to dump the spd info from userspace, but dimms-detect.pl already does pretty much the same thing, except it translates it into dimm info (which is quite annoying if that's not what you want).
Good luck! Corey
Quoting Corey Osgood corey.osgood@gmail.com:
Yep datasheet says SMBus Controller - Bus 0:Device 31:Function 3
How would I call debug.c and from what file?
I noticed in auto.c there is a dump_spd_registers(&memctrl[0]); commented out. Could I try this to dump the SPD data??
Thanks - Joe
Quoting Joseph Smith joe@smittys.pointclark.net:
So, I tried the dump_spd_registers(&memctrl[0]); dump_smbus_registers(); from debug.c and here is the results: ----------------- LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting...
dimm: 00.0: 50 00: bad device
dimm: 01.0: 51 00: bad device
smbus: 69 ----------------
HELP???
Thanks - Joe
Joseph Smith wrote:
In the attached debug.c is probe_spd_rom(). If your device has spd, it should be able to find it. You can use the whole file and #include it into the southbridge or mainboard or even northbridge code, or just copy and paste it into somewhere else. Call it whereever you called dump_spd_registers from. Note that it's not magic (yet), it won't actually use found spd locations, you'll have to do that manually. Also, what make/model is your dimm and board (I know you've told me, but my memory is terrible)? The datasheets may have more info, if they're available.
-Corey
Quoting Corey Osgood corey.osgood@gmail.com:
So I tried the probe_spd_rom() and it comes back with "bad device". Which I expected because this line in the function
status = smbus_read_byte(i, 0);
is my whole problem:( The smbus_read_byte function is what is not working in raminit.c so why would it work when called from auto.c?? No matter what byte I try to read it just comes back with a 0xFF ??
Here is a recap of the hardware: RCA RM4100 Embedded Set-top-box Low Voltage Intel® Celeron® processor (Micro-FC-BGA) 733MHz 128MB PC133 SDRAM on board (Embedded) (In Socket2) Intel i82830 (i830M4) Northbridge (Developing) Intel i82801DB Southbridge (Using i82801xx) SMSC lpc47m192 SuperIO (Using smscsuperio)
This is making me crazy, I'm so confused?
Thanks - Joe
Joseph Smith wrote:
That's because I messed up and forgot to remove the break, so after checking the first location, it left the function. It should have (quite literally) filled your screen with bad device messages, with one message saying it found an spd rom. In hindsight, it was pretty damn stupid of me to leave that message there. Try the attached version, it should be fixed and is even simpler now.
Essentially what seems to be going on here is the smbus is looking for data, but it can't find the spd rom. The "bad device" error is trying to say bad spd device, or at least that's the hope. Better parsing of the error code (-1 vs -2, etc) could tell us more, but that's the next step (mainly cuz I'm almost asleep right now). This is exploring stepan's theory that the device isn't located at the standard 0x50, etc, by checking the first byte (byte 0) at every address (denoted by i), through the first 256, and throwing up a message if it finds anything. Note that just because there's a device found it's not necessarily the spd rom, but there's a decent chance of it. The other possible problem is that, since your ram is embedded, there isn't any spd rom at all...
-Corey
Quoting Corey Osgood corey.osgood@gmail.com:
Ok, so I tried this and it just returns a "SPD located at 0x69" is this correct? It is much different than the standard 0x50, etc. Is this because it is embedded?? Thanks for all help.
Thanks - Joe
Joseph Smith wrote:
I'd do an dump first, just to make sure that it really is an spd rom and not some other device on the smbus. Or else do a dump and try to use it in the same run, can't really hurt.
-Corey
Quoting Corey Osgood corey.osgood@gmail.com:
OK, I think I know what is going on here. Here is a dump of my smbus with the legacy bios.
0 1 2 3 4 5 6 7 8 9 a b c d e f 00: XX XX XX XX XX XX XX XX XX XX XX XX XX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX UU XX XX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX 70: XX XX XX XX XX XX XX XX
SPD would show up at 0x50 or 0x51 right? It doesn't appear there is SPD on the on-board memory.I only show items at 0x2d (sensor) and 0x69 (clock chip).
So where do you think I should go from here? I could set up a *.c file in the mainboard directory to call a function to manually set the correct settings for socket2 (I know what the settings are supposed to be) after raminit.c dynamicly configures the register but before the sdram_enable function is called. It should be fairly simple to do and call from auto.c. What do you think?
Thanks - Joe
* Joseph Smith joe@smittys.pointclark.net [070812 19:49]:
Are these devices (sensor, clock chip) identified? Any chance there is an i2c mux somewhere?
Quoting Stefan Reinauer stepan@coresystems.de:
Not sure, what is the typical address for a i2c mux? I can probe for it. The only other device i think there is, is the on-board tv-out chip, and I think that is at 0x88. How come lm-sensors default is to only probe between address range 0x03-0x77?
Thanks - Joe
Generally, I2C mux has some external pins to set its address. In my Tyan S3992, the address is 0x71, so the function activate_spd_rom is called before accessing SPD.
Best Regards
??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406
-----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Joseph Smith Sent: Monday, August 13, 2007 2:09 AM To: Stefan Reinauer Cc: Corey Osgood; linuxbios@linuxbios.org Subject: Re: [LinuxBIOS] Read SPD issue
Quoting Stefan Reinauer stepan@coresystems.de:
Not sure, what is the typical address for a i2c mux? I can probe for it. The only other device i think there is, is the on-board tv-out chip, and I think that is at 0x88. How come lm-sensors default is to only probe between address range 0x03-0x77?
Thanks - Joe
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Simple questions. I hope you don't mind. The LinuxBios Product page does not seem to show a motherboard for a desktop machine.
A few months ago I read that LinuxBios could run on the GA-M57SLI-S4 motherboard.
There are some problems (http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial) though. To change the BIOS requires soldering a new socket onto the board and, even at that, there is a possibility that the board could be ruined in the process. I don't have the skills required to modify the board, so it is a modification that I need done by someone else. Would you recommend this machine for desktop use ?
Is there a desktop AMD 64 Linux machine with LinuxBios available from a good commercial vendor ?
Thanks in advance, Bob
Please create a new thread for new questions.
Robert Vogel wrote:
http://www.linuxbios.org/Supported_Motherboards <- look at desktops/workstations, the first section.
Thanks in advance, Bob
-
Corey Osgood -
Feng, Libo -
Joseph Smith -
Robert Vogel -
Stefan Reinauer