Hi Arthur, On Mon, 11 Sept 2023 at 23:42, Arthur Heymans <[email protected]> wrote: > > 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?
Yes...although within the bootblock it can just use the C struct directly, since the symbol points to it. It is really just a bit of static data. When running from romstage, etc. we can either search for a magic number or (if CBFS is available early enough) use a CBFS attribute to locate the offset of the area within the bootblock. > > 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? Yes, I see that for log level. But it does use a string to search for the option, which presumably has more overhead? It seems to only be implemented in the CMOS RAM?? The code is quite confusing. > > 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? Yes, perhaps controlled by a Kconfig option? > > 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 Yes we could plug into that...but I wonder how this works when the data is in CAR? Doesn't that make it hard to make the data available to ramstage? Is there any documentation about this? Regards, Simon > > Arthur > > > > On Tue, Sep 12, 2023 at 12:04 AM Simon Glass <[email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
