Hi Simon
I agree that both cbfs or fmap for that matter are not practical options as on some SOC the boot memory is not memory mapped and requires some hardware init.
We have other instances where cbfstool updates the bootblock code post compilation: cbfs verification. See src/lib/metadata_hash.c which has a magic set of characters the tooling can find:
__attribute__((used, section(".metadata_hash_anchor"))) static struct metadata_hash_anchor metadata_hash_anchor = { /* This is the only place in all of coreboot where we actually need to use this. */ .magic = DO_NOT_USE_METADATA_HASH_ANCHOR_MAGIC_DO_NOT_USE, .cbfs_hash = { .algo = CONFIG_CBFS_HASH_ALGO } };
I guess CCB would have a similar way of working: a magic char sequence for each setting, because one struct containing all the options will not work well when the struct or the semantics of the entries need updating?
sidenote: There is an option framework already in place get_uint_option, which hooks up to serial console verbosity. Maybe CCB could be used as an implementation for that option framework so no code needs to change?
Similar to updating metadata_hash_anchor there are some difficulties if the bootblock is checksummed somewhere, in which case it needs to be updated. It also makes root of trust technologies like Intel TXT,bootguard,CBnT very hard to use as the digest of the bootblock is in a signed manifest which you'd have to regenerate then. So it's probably best to make this feature optional?
About Firmware Handoff: currently linker script globals (linker scripts are the same for each stage) are used to pass data between stages. It has the same advantage as the CCB solution you propose: the code has a pointer to the data without needing to fetch or decode it. The disadvantage is that you need to maintain this in every linker script. Maybe this deserves another discussion as others stumbled on the desire to pass data between stages too: https://review.coreboot.org/c/coreboot/+/76393
Arthur
On Tue, Sep 12, 2023 at 12:04 AM Simon Glass sjg@chromium.org wrote:
Hi,
RFC: 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
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.
Regards, Simon _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org