Working on an Atom D500/NM10 system, trying to get some info on memory init. Everything seems to go alright up to when it starts pulling SPD data from the SMBus, but for some reason, the stock BIOS performs an SMBus read at 0x60, checks and sees that the read completed successfully, clears the success bit, and then, without reading the data, tries 0x64, and does the same thing. It then moves on to 0x9c, 0xd3, and 0xd2. I've attached a log file, don't mind my notes. Any ideas what might be causing this, and how to work around it?
Thanks, Corey
On 04/01/2011 10:49 AM, Corey Osgood wrote:
Working on an Atom D500/NM10 system, trying to get some info on memory init. Everything seems to go alright up to when it starts pulling SPD data from the SMBus, but for some reason, the stock BIOS performs an SMBus read at 0x60, checks and sees that the read completed successfully, clears the success bit, and then, without reading the data, tries 0x64, and does the same thing. It then moves on to 0x9c, 0xd3, and 0xd2. I've attached a log file, don't mind my notes. Any ideas what might be causing this, and how to work around it?
Hmm could be probing to see if devices are present at those addresses? Is there anything there? Thermal sensors?
On Fri, Apr 1, 2011 at 6:43 PM, Joseph Smith joe@settoplinux.org wrote:
On 04/01/2011 10:49 AM, Corey Osgood wrote:
Working on an Atom D500/NM10 system, trying to get some info on memory init. Everything seems to go alright up to when it starts pulling SPD data from the SMBus, but for some reason, the stock BIOS performs an SMBus read at 0x60, checks and sees that the read completed successfully, clears the success bit, and then, without reading the data, tries 0x64, and does the same thing. It then moves on to 0x9c, 0xd3, and 0xd2. I've attached a log file, don't mind my notes. Any ideas what might be causing this, and how to work around it?
Hmm could be probing to see if devices are present at those addresses? Is there anything there? Thermal sensors?
So, it turns out this board really doesn't like it when I try test/dump all 128 SMBus addresses, the SMBus stops working around 69h. Not sure if it's because of the number of SMBus operations in a short time span, or that SMBus work for very long after init. I did manage to figure out that I'm rusty on SMBus, the addresses are all shifted to the left one, so the address it's really trying to probe are 30h, 32h, 4Eh, and 69h, all of which have devices of some kind on them, although I'm not sure if they're all sensors (kinda doubt it, but it's possible) or for other functions like TV-out or clock controls. Also, these are both read and write functions, and mostly write. It seems like the SMBus only stays working for a short period of time after it gets initialized, and I think the problem is that SerialICE makes the SMBus operations take so much longer that they start failing before the system has everything set up. So, I'm thinking there are a couple options, one being to modify the lua script to not log access to the SMBus addresses, but I don't think that will help much, because it just eliminates printing the text to the screen (afaik). The other being to try a BIOS from a really cheap NM10 board, that's not likely to have the configurable clock chips and TV out, since all I'm really interested in is RAM init, for the time being. Any opinions?
Thanks, Corey
On 04/06/2011 04:20 AM, Corey Osgood wrote:
On Fri, Apr 1, 2011 at 6:43 PM, Joseph Smithjoe@settoplinux.org wrote:
On 04/01/2011 10:49 AM, Corey Osgood wrote:
Working on an Atom D500/NM10 system, trying to get some info on memory init. Everything seems to go alright up to when it starts pulling SPD data from the SMBus, but for some reason, the stock BIOS performs an SMBus read at 0x60, checks and sees that the read completed successfully, clears the success bit, and then, without reading the data, tries 0x64, and does the same thing. It then moves on to 0x9c, 0xd3, and 0xd2. I've attached a log file, don't mind my notes. Any ideas what might be causing this, and how to work around it?
Hmm could be probing to see if devices are present at those addresses? Is there anything there? Thermal sensors?
So, it turns out this board really doesn't like it when I try test/dump all 128 SMBus addresses, the SMBus stops working around 69h. Not sure if it's because of the number of SMBus operations in a short time span, or that SMBus work for very long after init. I did manage to figure out that I'm rusty on SMBus, the addresses are all shifted to the left one, so the address it's really trying to probe are 30h, 32h, 4Eh, and 69h, all of which have devices of some kind on them, although I'm not sure if they're all sensors (kinda doubt it, but it's possible) or for other functions like TV-out or clock controls. Also, these are both read and write functions, and mostly write. It seems like the SMBus only stays working for a short period of time after it gets initialized, and I think the problem is that SerialICE makes the SMBus operations take so much longer that they start failing before the system has everything set up. So, I'm thinking there are a couple options, one being to modify the lua script to not log access to the SMBus addresses, but I don't think that will help much, because it just eliminates printing the text to the screen (afaik). The other being to try a BIOS from a really cheap NM10 board, that's not likely to have the configurable clock chips and TV out, since all I'm really interested in is RAM init, for the time being. Any opinions?
Well I think you need option one. You need to be able to read memory SPD's on the smbus.
-
Corey Osgood -
Joseph Smith