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