[coreboot] CBMEM Console corruption with fsp_baytrail in coreboot 4.2

[Ben Gardner]

Hi,

I've narrowed down where the CBMEM console is getting corrupted and
found a work around that gets it working again.
It is getting corrupted in the FSP Early Init function. So in the
Intel blob, not coreboot.

I added logs to cbmemc_init() and cbmrmc_reinit() that show the
console pointer, size, cursor and the first 64 bytes of the console
(including size and console).

Right before the call to FspInitApi() in fsp_early_init():
fsp_early_init: cbm_cons_p: fef00000 size=3064 cur=2606
fef00000: f8 0b 00 00 7b 0a 00 00 63 62 6d 65 6d 63 5f 69  ........cbmemc_i
fef00010: 6e 69 74 3a 20 63 62 6d 5f 63 6f 6e 73 5f 70 3a  nit: cbm_cons_p:
fef00020: 20 66 65 66 30 30 30 30 30 20 73 69 7a 65 3d 33   fef00000 size=3
fef00030: 30 36 34 20 63 75 72 3d 30 0a 66 65 66 30 30 30  064 cur=0.fef000

And this is at the top of romstage_main_continue():
romstage_main_continue: cbm_cons_p: 00000b96 size=2052398204 cur=1024945500
00000b96: 7c 1c 55 7a bd 6d 17 3d 17 a9 76 69 ee 07 d1 b8  |.Uz.m.=..vi....
00000ba6: fa 6b 75 85 ee 7a dd 8f e9 48 59 93 b4 f8 0a ce  .ku..z...HY.....
00000bb6: 1c dc fe a4 09 d6 ba 1d 88 8f 23 e4 40 cc 88 cd  ..........#. at ...
00000bc6: 90 91 53 e4 71 6d 90 1d bd e9 fa 13 a8 16 fd b5  ..S.qm..........

So, the FSP is trashing the CAR variables.

I looked at the changes to src/arch/x86/car.ld and see that the
CONSOLE line was moved before _car_data_start.
That move appears to have been in commit dd6fa93d by Aaron Durbin.
http://review.coreboot.org/#/c/11740/3/src/arch/x86/car.ld

When I moved that CONSOLE line back to after _car_data_end, the
console works again.
That also fixes the timestamp table infinite loop issue.

So, I have a work-around.
However, I suspect that the root issue of the FSP trashing CAR
variables persists.

My initial email about the timestamp issue is here:
http://www.coreboot.org/pipermail/coreboot/2015-November/080719.html

I'm not sure what to do about this.
The above change seems reasonable and needed for verstage support, so
sending my 'fix' upstream probably isn't viable.

Suggestions?

Thanks,
Ben