[coreboot] More details about ram issues

[Nico Huber]

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