On 12.11.2016 06:40, Charlotte Plusplus wrote:
Using my new usb debug cable, here is a full debug output from setting max_mem_clock_mhz=800 (image normal) : clocks selected 9-9-9-24, getting about 750 errors in memtest after 3 min
max_mem_clock_mhz=934 (image fallback) : clocks selected 10-10-10-28 which is so optimistic it can't boot and remain stucks in a loop of "PLL busy..."
Before, when I was manually setting the SPD latency, I could get fewer errors and even boot at 934.
So I followed Nico advice and created mainboard_fill_pei_data to do a non native ram init with the same max_mem_clock_mhz=800, with a fallback at 666.
It compiled fine with CONFIG_USE_BLOBS=y and CONFIG_USE_NATIVE_RAMINIT manually disabled, but I must have done something wrong, as it shows the 666 from the fallback, and gets stuck in the "PLL busy" loop
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).
On reboot to fallback, max_mem_clock_mhz=666 (image fallback) is correctly selected, with clocks 7-7-7-20 and as usual a bunch of errors in the memtest
It's late and I may have done some obvious mistake in mainboard_fill_pei_data, but I can't spot it. (and I don't understand the ts_addresses part)
A wild guess: TS stands for thermal sensor (for each DIMM). Shouldn't matter. 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).
Nico
Hello
On Sat, Nov 12, 2016 at 7:28 PM, Nico Huber nico.h@gmx.de 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
-
Charlotte Plusplus -
Nico Huber