Am Sonntag, den 08.01.2017, 15:23 +0100 schrieb Nico Huber:
On 08.01.2017 14:38, Paul Menzel via coreboot wrote:
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.
One more question. How was the size 0xc00 chosen in the first place?
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.
Understood. I adapted the change set accordingly for the Intel 945 .
Testers are welcome.
But, for boards that implement the romstage 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?
>  https://review.coreboot.org/18049/
> "arch/x86: Increase preram CBMEM console buffer size"