Hi Simon,
Why not CMOS RAM / VVRAM?
- If we allocate some space in CMOS for console / logging settings, then it would allow a similar feature. But it involves changing settings on the device. Each board would need to provide some CMOS options for this feature as part of the layout file. It would not be possible to enable console output without running some code on the device to update the CMOS RAM.
(Pardon the formatting; I copied this out of my semi-regular digest)
Many boards already have this space allocated in their cmos.layout. Take for example my sandybridge board, asus/p8z77-m:
# coreboot config options: console 395 4 e 4 debug_level [...] # debug_level 4 0 Emergency 4 1 Alert 4 2 Critical 4 3 Error 4 4 Warning 4 5 Notice 4 6 Info 4 7 Debug 4 8 Spew
Setting this to 0 suppresses almost all outputs unless it's a "I'm going to die()" scream.
For development/hacking we do want to start with debug outputs on the console. If after ample testing a build has proved itself to be stable, cmos.default (that is a separate file) in CBFS can be patched to change the default log level. This would be done through cbfstool (albeit indirectly - extract, patch, re-insert) or a hex editor. I'd propose a tool that operates on this binary cmos.layout instead.
In short, in my opinion, we don't need a new construct.
Regards Keith
Hi Keith,
On Tue, 12 Sept 2023 at 18:09, Keith Hui buurin@gmail.com wrote:
Hi Simon,
Why not CMOS RAM / VVRAM?
- If we allocate some space in CMOS for console / logging settings,
then it would allow a similar feature. But it involves changing settings on the device. Each board would need to provide some CMOS options for this feature as part of the layout file. It would not be possible to enable console output without running some code on the device to update the CMOS RAM.
(Pardon the formatting; I copied this out of my semi-regular digest)
This came in not as a reply to my email, so perhaps others will not see it.
Many boards already have this space allocated in their cmos.layout. Take for example my sandybridge board, asus/p8z77-m:
# coreboot config options: console 395 4 e 4 debug_level [...] # debug_level 4 0 Emergency 4 1 Alert 4 2 Critical 4 3 Error 4 4 Warning 4 5 Notice 4 6 Info 4 7 Debug 4 8 Spew
Setting this to 0 suppresses almost all outputs unless it's a "I'm going to die()" scream.
For development/hacking we do want to start with debug outputs on the console. If after ample testing a build has proved itself to be stable, cmos.default (that is a separate file) in CBFS can be patched to change the default log level. This would be done through cbfstool (albeit indirectly - extract, patch, re-insert) or a hex editor. I'd propose a tool that operates on this binary cmos.layout instead.
But how does that work generically? Doesn't it require boards to have a particular CMOS layout? Also, how does this work with boards which don't have CMOS RAM? Finally, is it really correct that booting coreboot should update the CMOS RAM? What tool is available to adjust CMOS RAM without having to boot into Linux, etc.? (which may not work)
In short, in my opinion, we don't need a new construct.
I don't know how to join the threads, but I am not convinced, based on the above.
Another concern is that we don't even enable the serial console at present in many cases...we need some control of that, separate from what the debug level is. For example, CBMEM can record all the console, perhaps at maximum level, but the serial output might want to be disabled.
Regards, SImon
-
Keith Hui -
Simon Glass