Hello On Sat, Nov 12, 2016 at 7:28 PM, Nico Huber <[email protected]> wrote:
> Looks like it's booting the fallback path, maybe because something went > wrong on the normal path? I haven't got USB debug working with the MRC > blob reliably for over a year now, btw. But you should definitely see > messages before coreboot jumps into the blob. If you get there and it > seems to hang, disable USB debug in romstage (the blob doesn't have de- > bug output anyway). > It was late, I must have done something really stupid. Because this morning I've got usb debug working. Output attached. The ram is correctly detected, and at the right non-XMP frequency. I only had to update the default MMCONF in the w520 Kconfig, otherwise the boot would hang. > A wild guess: TS stands for thermal sensor (for each DIMM). Shouldn't > matter. Ok, I will leave that at 0 > But according to your comments A2 and A4 should be exchanged > (matters if your DIMMs have different SPDs or you didn't populate all > slots). Oops you're right. I did a fancy listing of read_spd like 0,2,1,3, but it hides the correct order Instead of making that obvious by ordering 0,1,2,3. Fixed. Now I get a boot with the mrc.bin blob, but it messes up something with the video init, as I get a black screen. So I can't get the memtest results and check whether everything works. I tried various things: native video init or not, pcie_init=0 or =1, same result: black screen. Output attached. Would you have any idea why? If I add a default order to seabios, I think can still try to use that to check the ram settings with inteltool by ssh, and compare the results to the native ram settings. I just wish I could quickly check the stability too. Charlotte
blob-raminit.cap
Description: application/vnd.tcpdump.pcap
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
