On Tue, 18 Apr 2017 16:08:09 +0200
Marek Behun <kabel(a)blackhole.sk> wrote:
> > I would try the following to narrow it down: Run the memory training
> > with the original ME firmware; keep the MRC cache intact while
> > switching to the truncated ME firmware; boot. If it doesn't work
> > with the cached values, something around the memory clock might be
> > off. If you have de- bug access, you could also directly compare
> > the training results from a boot with the original ME firmware vs.
> > the modded firmware. If not you can still compare the results from
> > MRC-cache dumps. But you'd have to decode them first...
>
> So I tried to put mrc.cache generated with ME into CBFS, but after
> reboot, mrc cache was regenerated. I investigated, and found out:
> 1) in mrc.cache with ME, the data begins 4 bytes sooner than in
> mrc.cache without ME. This could be the reason why mrc.cache was
> regenerated: the one that was found there (generated by coreboot
> with ME) was invalid for coreboot without ME?
Looks like you corrupted the mrc.cache. Every entry is protected by
CRC32. If the first few bytes (mobile) are zero, there's
something very wrong, as this is a constant value.
The other timings are fine and may vary a little bit, due to noise while
training the memory modules.
> 2) there are different timings in the cache generated without ME.
> I have written an utility to print the data stored there. I am
> attaching those two together with a diff.
>
> I am going to try to somehow change the mrc.cache generated by
> coreboot with ME so that coreboot without ME accepts it as valid and
> does not regenerate.
>
> Marek