On Sun, 2013-10-27 at 00:14 +0200, Rudolf Marek wrote:
Anything I can do to debug? Do you have an idea?
Yes it looks like memory is setup in wrong way. I did the port for ASUS A8V-E SE board. Possible reasons:
- something is wrong with placement of dimms
I remember sometimes memory did not work well if in second channel, sometimes even the board had it labeled vice versa... Try to put dimm in different slot. It could fix single dimm issues
You're right with the single dimm issues, I have to use slot B1 or B2 for a single module, vendor BIOS and coreboot. But I also found a more or less working configuration I had somehow missed before: putting both 1GB ECC modules in B1 and B2 makes coreboot detect full 2GB and boot, but with reduced speed: "Memory speed reduced due to signal loading conditions", and not DualChannel of course; see log. Anything else hangs at "Jumping to image" or detects only 1GB.
- something is wrong with dualchannel setup
This is usually sign that the following table is wrong:
You can try to modify it like this as it is on A8V-E SE because the deluxe version seems wrong to me (you have only 4 dimm slots)
static const uint16_t spd_addr[] = { // Node 0 DIMM0, DIMM2, 0, 0, 0, 0, 0, 0, // Node 1 DIMM1, DIMM3, 0, 0, 0, 0, 0, 0, };
I used i2cdetect like you suggested (which was interesting!) and I found out that this should be the correct table. The labels on the board seem to be vice versa indeed:
Board label: A1 | A2 | B1 | B2 <-- physical layout ----------------- i2c address: 51 | 53 | 50 | 52
With both modules in A1/B1 or A2/B2 the system would boot now, but only 1GB was detected, or 512MB with 512MB modules, also with non-ECC! With both modules in B1/B2 it was the same as before (2GB detected, reduced speed, but works). Both log files are with this corrected table.
I also tried to swap DIMM0, DIMM2 with DIMM1, DIMM3 and the results from i2cdetect were funny:
0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2f 30: -- -- -- -- -- 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77
Also, only the module in B1 was detected, not in B2, if I remember correctly..
- something is wrong with memory init
lets wait if above helps, I suspect it should.
I'm not sure right now if it did.. the table is probably correct but now even non-ECC is not fully detected. Assuming it IS correct, is there anything I can try except making myself familiar with RAM init and searching for a bug, which could take a while, like, forever?
Apart from that I got a little success story: the VIA K8T890 chipset on this mainboard had a bug in it's first revision, making it incompatible with dual-core CPUs. I was curious if coreboot also had this limitation, so I bought a cheap dual-core Opteron 180 and tested it. Vendor BIOS: one core detected in linux. coreboot: two cores!!
Yes because I was not aware of this problem while implementing this chipset support 6? years ago. Do you have any details?
I'm glad you were not! I don't know any more than what I found using google though [1]. The A8V-E SE had a newer chipset revision which was fixed. Probably they shipped some A8V-E Deluxe boards with the new revision and mine already has it as well.
Thank you for your help Rudolf!
Michael