ron minnich wrote:
On Tue, Sep 9, 2008 at 11:42 AM, Daniel Lindenaar daniel-coreboot@lindenaar.eu wrote:
ron minnich wrote:
On Tue, Sep 9, 2008 at 11:33 AM, Daniel Lindenaar daniel-coreboot@lindenaar.eu wrote:
Ah I see, it's pretty much how the i2cdetect app works. I just did that and I got 128 times: "smbus_error: 04, Device Error", which is the same as I got from the spd functions :/
Cr*p it seems I've overlooked that there were only 126 errors and actually 0x5a and 0x5b did reply... Does this help?
Woohoo, it does help. When you divide 0x5a by two, you get 0x2d, when you divide 0x5b by two, you get 0x2d again. 0x2d is a device that was shown by i2cdump... So I figured, maybe the vt8235_early_smbus code i copied from contains a bug and voila... the address is not shifted left by 1 bit before it's written to bit 7-1 of the IO register containing the slave address! Now smbus works. Coreboot as a whole not yet, but I think this has something to do with the payload.
the log ends with:
elfboot: Attempting to load payload. rom_stream: 0xfffe0000 - 0xfffeffff No header at 0 No header at 16 No header at 32 No header at 48 No header at 64 No header at 80 No header at 96 No header at 112 No header at 128 No header at 144 No header at 160 No header at 176 No header at 192 No header at 208 No header at 224 No header at 240 No header at 256 No header at 272 No header at 288 No header at 304 No header at 320 No header at 336 No header at 352 No header at 368 No header at 384 --- snip --- No header at 8096 header_offset is -1 Can not load ELF Image.
I was trying to use filo as a bootloader, but apparently something went wrong.
any hints?
regards Daniel