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 , 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
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.
Should that option be moved there?
"arch/x86: Increase preram CBMEM console buffer size"