Attention is currently required from: Angel Pons, Benjamin Doron, Lean Sheng Tan, Maximilian Brune, Nico Huber, Patrick Rudolph, Sean Rhodes.
Patrick Rudolph has uploaded a new patch set (#14) to the change originally created by Angel Pons. ( https://review.coreboot.org/c/coreboot/+/74121?usp=email )
The following approvals got outdated and were removed: Verified+1 by build bot (Jenkins)
Change subject: [RFC] drivers/option: Add option list in cbtables ......................................................................
[RFC] drivers/option: Add option list in cbtables
TODO: add proper documentation, add tests.
Introduce a mechanism so that coreboot can provide a list of options to post-coreboot code. This can be used to let payloads know which options should be displayed in a setup menu, for instance. Although this system was written to be used with edk2, it has been designed with flexibility in mind so that other payloads can also make use of this mechanism. The system currently lacks a way to describe where to find option values.
This information is stored in a set of data structures specifically created for this purpose. This format is known as CFR, which means "coreboot forms representation" or "cursed forms representation". Although the "forms representation" is borrowed from UEFI, CFR can be used in non-UEFI scenarios as well.
The data structures are implemented as an extension of cbtables records to support nesting. It should not break backwards compatibility because the CFR root record (LB_TAG_CFR_ROOT) size includes all of its children records. The concept of record nesting is borrowed from the records for CMOS options. It is not possible to reuse the CMOS records because they are too closely coupled with CMOS options; using these structures would needlessly restrict more capable backends to what can be done with CMOS options, which is undesired.
Because CFR supports variable-length components, directly transforming options into CFR structures is not a trivial process. Furthermore, CFR structures need to be written in one go. Because of this, abstractions exist to generate CFR structures from a set of "setup menu" structures that are coreboot-specific and could be integrated with the devicetree at some point. Note that `struct sm_object` is a tagged union. This is used to have lists of options in an array, as building linked lists of options at runtime is extremely impractical because options would have to be added at the end of the linked list to maintain option order. To avoid mistakes defining `struct sm_object` values, helper macros exist for supported option types. The macros also provide some type checking as they initialise specific union members.
It should be possible to extend CFR to support additional functionality such as being able to describe dependencies between options, or support for more sophisticated options like fan curve points. However, this may require having a version field in the CFR root record to avoid problems with CFR consumers that do not support these extensions. Feedback about this is highly appreciated.
Change-Id: I304de7d26d79245a2e31a6d01f6c5643b31cb772 Signed-off-by: Angel Pons th3fanbus@gmail.com --- A src/drivers/option/Kconfig A src/drivers/option/Makefile.inc A src/drivers/option/cfr.c A src/drivers/option/cfr.h 4 files changed, 433 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/21/74121/14