[coreboot] Saving truncated preram CBMEM messages

[Nico Huber]

On 08.01.2017 14:38, Paul Menzel via coreboot wrote:
> Dear coreboot folks,
> 
> 
> looking at the coreboot CBMEM console messages board status repository,
> you’ll find a lot of truncated preram CBMEM console messages.
> 
> Currently the buffer size is 0xc00 – 3 kB, right –, which is too small
> for quite some boards. The mainboard *Kabylake LPDDR3 RVP3* overrides
> it to 0xd00.
> 
> So I am thinking about increasing it [1], but it’s of course not that
> simple, especially as I don’t understand all the implications.
> 
>> Increasing this buffer reduces amount of available CAR stack, and
>> apparently DDR3 raminit already struggles with the amount of
>> cachelines available on fam10/15

This means a lower stack size (higher console buffer size) would result
in a stack overflow. In other words, a brick.

> 
> My first question is, what other downsides are there of increasing the
> buffer size? I assume it’s unrelated to resulting usable RAM size, as
> RAM sizes nowadays are much, much bigger? So would one megabyte be
> reasonable/possible as a goal on boards supporting that?

No, no other downsides beside bricking.

> 
> So if their is consensus that it should be increased, what would a way
> be forward? I assume, overriding it per mainboard is not so useful, as
> these messages are mostly from the chipset, so it should be chipset
> dependent?

I would override it per chipset. But, for boards that implement the rom-
stage main(), it has to be tested for each board (a single declaration
in the main() could decide if the stack overflows or not).

A better option would be to reduce the verbosity: Identify log messages
that are less useful (and could be hidden behind options like CONFIG_
DEBUG_RAM_SETUP). Or something like disabling BIOS_SPEW messages if
CBMEM is the only console.

Nico

> 
> Should that option be moved there?
> 
> 
> Thanks,
> 
> Paul
> 
> 
> [1] https://review.coreboot.org/18049/
>    "arch/x86: Increase preram CBMEM console buffer size"
> 
> 
>