[L] Change in coreboot[main]: [RFC] drivers/option: Add forms in cbtables

[Patrick Rudolph (Code Review)]

Attention is currently required from: Angel Pons, Benjamin Doron, Lean Sheng Tan, Maximilian Brune, Nico Huber, Sean Rhodes.

Patrick Rudolph has uploaded a new patch set (#18) 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 forms in cbtables
......................................................................

[RFC] drivers/option: Add forms in cbtables

Introduce a mechanism so that coreboot can provide a list of options to
post-coreboot code. The options are grouped together into forms and
have a meaning name and optional help text. 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 support for more sophisticated
options like fan curve points. Feedback about this is highly
appreciated.

Change-Id: I304de7d26d79245a2e31a6d01f6c5643b31cb772
Signed-off-by: Angel Pons 
---
A Documentation/drivers/cfr_internal.md
M Documentation/drivers/index.md
A src/drivers/option/Kconfig
A src/drivers/option/Makefile.inc
A src/drivers/option/cfr.c
A src/drivers/option/cfr.h
M src/include/boot/coreboot_tables.h
M src/lib/coreboot_table.c
M src/lib/program.ld
9 files changed, 603 insertions(+), 0 deletions(-)

git pull ssh://review.coreboot.org:29418/coreboot refs/changes/21/74121/18