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"