[coreboot] Asus M2V-MX SE: Resume from S3 broken: `CBFS: ERROR: No file header found at 0x0 - try next aligned address: 0x40.`

[Kyösti Mälkki]

On 01/01/2014 06:46 PM, Paul Menzel wrote:
> Dear coreboot folks,
>
>
> the issue is still not solved, so here is an update.
>
> First of all, my thanks go to Kyösti for helping me debug this issue in
> #coreboot on <irc.freenode.net>.
>
> According to Kyösti there is fairly strong evidence of RAM / stack
> corruption during S3 resume.
>
> Memtest 5.00b5 successfully passed twice run from GRUB 2 on hard disk
> with coreboot and SeaBIOS payload. I’ll still have to test resume from
> S3 with other memory modules.
>
> Kyösti pushed a AMD K8/Fam 10h CAR rewrite to Gerrit [1]. Additionally
> he provided the attached diff [2] to capture a stacktrace. Please find
> my logs with `PRINT_IN_CAR` set to 0 and 1 attached.

What the traces suggested is RAM access being unstable on S3 resume. 
With stack moved to RAM, we saw issues like returning to incorrect EIP 
from function calls and local variables getting wiped. A single build 
could fail at numerous different ways.

Leaving RAM un-cacheable (not setting variable MTRR of [0x0 - RAMTOP[ to 
write-back) when resuming from S3 seems to solve the problem of halting 
in middle of romstage. On S3 resume it now loads ramstage and fails at 
the time of MTRR (re-)programming. This is where it would set RAM to 
write-back cacheable.

> Testing from other owners of the Asus M2V-MX SE would be very helpful as
> resume from suspend to RAM was supposedly working in the past for them.

And with different memory configuration and different CPU, those may 
work like they did before. And the particular configuration of memory 
you have may never have been tested for S3 resume until now.

We can compare memory controller parameters on power-on and S3 resume 
and hopefully we locate the significant difference in register 
programming there. JEDEC sequencing bringing DIMMs out of self-refresh 
needs to be investigated too.

Kyösti