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
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?
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?
Should that option be moved there?
Thanks,
Paul
[1] https://review.coreboot.org/18049/ "arch/x86: Increase preram CBMEM console buffer size"
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"
Dear Nico,
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 [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.
One more question. How was the size 0xc00 chosen in the first place?
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.
Understood. I adapted the change set accordingly for the Intel 945 [1]. 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?
Thanks,
Paul
[1] https://review.coreboot.org/18049/ "arch/x86: Increase preram CBMEM console buffer size"
On 12.02.2017 00:34, Paul Menzel wrote:
Dear Nico,
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 [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.
One more question. How was the size 0xc00 chosen in the first place?
[2] mentions log output of above 2KiB. Looks like it was just rounded up to 3KiB. But I doubt that all boards were tested if any gives more out- put by default.
Nico
-
Nico Huber -
Paul Menzel