Hi,
Here is an updated version 2 of the RFC
RFCv2: Post-build control of serial console
It is annoying to have to create and maintain two completely different builds of coreboot just to enable or disable the console. It would be much more convenient to have a 'silent' flag in the image, which can be updated as needed, without needing to rebuild
coreboot. For example, if something goes wrong and coreboot hangs, it would be nice to be able to enable serial on the same image, then boot it again to see how far it gets.
I propose a 'Coreboot Control Block' (CCB) which can hold a small number of such settings.
It is designed to be available very early in bootblock, before CBFS is ready. It is able to control the output of the very first bootblock banner. early silicon-init, etc. It is built as part of the bootblock image, so can be accessed simply as a static C struct within the bootblock code. That means that the code overhead is very low and we could
perhaps enable it by default.
The bootblock can have a CBFS file attribute that indicates that it contains a CCB and the offset where it is stored. Other coreboot stages can read this as well, or it could be duplicated in a separate file.
We can provide options in cbfstool to get and set settings in the CCB. This makes it easy to use this feature, e.g. to enable silent:
cbfstool coreboot.rom ccb-set -n serial -V silent
API for the settings:
I propose something like this:
enum ccb_setting {
CCB_SILENT_CONSOLE,
// others here
},
int ccb_read(enum ccb_setting val)
This is very efficient in terms of code size, e.g. it does not require a string, like get_uint_option().
What other APIs exist for reading config?
Mechanism
Control at run-time?
Controlled by image?
Cross-platform
Earlly bootblock
Smmstore
Yes
Yes
No
?
CMOS
Yes
No
No
Yes
Devicetree
No
Yes
Yes
Yes
CBI
Yes
No[1]
Yes
No
SPI ROM
TBD
CBFS flag files
Yes[1]
Yes
Yes
No
VPD
Yes
Yes [2]
Yes
No
CCB
Yes
Yes
Yes
Yes[4]
[1] Resides in EC, if there is one
[2] But changing the VPD is dangerous and we would want to avoid that for debugging. E.g. it might adjust the serial number.
[3] Can someone please point me to an example of flag files being used in coreboot?
[4] To the extent possible. Compression or verification may make this impossible, but this is likely unavoidable
Of the existing mechanisms, none seems to quite meet the requirements.
Why not use a separate CBFS file?
- Boards typically read the entire bootblock and start execution from it. The console is started early so the settings are needed before CBFS is available. By putting the CCB inside the bootblock, it can control things from an early stage.
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.
Why not use Firmware Handoff to pass the CCB to following stages?
- We could do that, particularly if CCB attracts some additional features,
such as logging.
How to deal with Boatguard, verification, etc?
If it is not possible to change the bootblock without causing a failure, then this feature will not work as intended.
How to deal with bootblock running on a different CPU? (AMD)
This should still work OK, since the CBB should be accessible to the CPU.
How to deal with a compressed bootblock?
If the whole bootblock has to be compressed, then this feature will not work, since it is not possible to update the CCB without knowing about the compression.
Regards,
Simon