<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 12, 2017 at 5:53 PM, Gert Menke <span dir="ltr"><<a href="mailto:gert@menke.ac" target="_blank">gert@menke.ac</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Thanks for your quick reply!<span class=""><br>
<br>
On 2017-03-12 13:08, Kyösti Mälkki wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We'll likely need coreboot debug logs. You can get one for normal boot<br>
using the tool under utils/cbmem, that might help us already. To<br>
collect log from failing S3 resume you need to learn about usbdebug<br>
and possibly get some FT232H or beaglebone hardware.<br>
</blockquote>
<br></span>
I'll attach the cbmem log, both for a clean boot and a boot that happens instead of the expected resume.<br>
<br></blockquote><div><br></div><div>As indicated by the clean boot log, it's a failure to write MRC cache. Could be that our SPI flash routines have regressed or were never tested for a setup with 4Mib + 8MiB SPI flash parts installed. Or there may be some unwritten rule about CBFS size and the location of MRC cache.<br><br></div><div>Kyösti<br></div></div></div></div>