this is based directly on the audit6 final revision.

same idea as klompboot. remove u-boot and arm support,
remove pico-serprog, remove support for making release
archives, and basically see how small the build
system can possible get.

quackboot *beats* the very first klompboot, at 790 lines,
because klompboot 1 was just over 800 lines. klompboot 2
was 701 lines. vendor file logic is about 200 sloc so
the next klompboot will be about 600 lines.

this is the very first quackboot.

Signed-off-by: Leah Rowe <leah@libreboot.org>

set a default one in mkhelper.cfg

Signed-off-by: Leah Rowe <leah@libreboot.org>

Never, ever build images where GRUB is the primary payload.

These options have been removed from target.cfg handling:

* seabios_withgrub
* grub_withseabios

The "payload_grub" variable now does the same thing as
the old "seabios_withgrub" variable, if set.

The "grubonly" configuration is retained, and enabled by
default when SeaGRUB is enabled (non-grubonly also available).

Due to lbmk issue #216, it is no longer Libreboot policy to
make GRUB the primary payload on any board. GRUB's sheer size
and complexity, plus the large number of memory corruption issues
similar to it that *have* been fixed over the years, tells me
that GRUB is a liability when it is the primary payload.

SeaBIOS is a much safer payload to run as primary, on x86, due
to its smaller size and much more conservative development; it
is simply far less likely to break.

If GRUB breaks in the future, the user's machine is not
bricked. This is because SeaBIOS is the default payload.

Since I no longer wish to ever provide GRUB as a primary
payload, supporting it in lbmk adds needless bloat that
will later probably break anyway due to lack of testing,
so let's just assume SeaGRUB in all cases where the user
wants to use a GRUB payload.

You can mitigate potential security issues with SeaBIOS
by disabling option ROM execution, which can be done at
runtime by inserting integers into CBFS. The SeaBIOS
documentation says how to do this.

Libreboot's GRUB hardening guide still says how to add
a bootorder file in CBFS, making SeaBIOS only load GRUB
from CBFS, and nothing else. This, combined with the
disablement of option ROM execution (if using Intel
graphics), pretty much provides the same security benefits
as GRUB-as-primary, for example when setting a GRUB password
and GPG checks, with encrypted /boot as in the hardening guide.

Signed-off-by: Leah Rowe <leah@libreboot.org>

replace it with logic that simply uses "." to load
files directly. for this, "vcfg" is added as a variable
in coreboot target.cfg files, referring to a directory
in config/vendor/ containing a file named pkg.cfg, and
this file then contains the same variables as the
erstwhile config/vendor/sources

config/git files are now directories, also containing
pkg.cfg files each with the same variables as before,
such as repository link and commit hash

this change results in a noticeable reduction in code
complexity within the build system.

unified reading of config files: new function setcfg()
added to lib.sh

setcfg checks if a config exists. if a 2nd argument is
passed, it is used as a return value for eval, otherwise
a string calling err is passed. setcfg output is passed
through eval, to set strings based on config; eval must
be used, so that the variables are set within the same
scope, otherwise they'd be set within setcfg which could
lead to some whacky results.

there's still a bit more more to do, but this single change
results in a substantial reduction in code complexity.

Signed-off-by: Leah Rowe <leah@libreboot.org>

this is bloat, because it's something the user can already
do at runtime configuration anyway.

set it to a reasonable default of 8 seconds instead of 5,
and don't honour the timeout variable in target.cfg.

this will be documented in the next release.

Signed-off-by: Leah Rowe <leah@libreboot.org>

the background is only a few kb. the whole rationale
before was to limit the space used in memdisk, but this
decision was made when the background was much bigger;
it has since been optimised greatly, and the grub modules
were heavily reduce, so it should be safe.

grub's memdisk breaks when you add too much data to it.
as part of simplifying the rest of lbmk, this change removes
some more bloat from the rest of lbmk. handling this in the
memdisk is much simpler than handling it with cbfstool.

Signed-off-by: Leah Rowe <leah@libreboot.org>

fixes DP++ and adds a DP that wasn't even there before,
on all currently supported variants of these machines

Signed-off-by: Leah Rowe <leah@libreboot.org>

the patch fixes IGD on certain xeon processors

Signed-off-by: Leah Rowe <leah@libreboot.org>

remove nvme support from the "default" grub tree

now there are three trees:

* default: no xhci or nvme patches
* nvme: contains nvme support
* xhci: contains xhci and nvme support

this is in case a bug like lbmk issue #216 ever occurs
again, as referenced before during lbmk audit 5

there is no indication that the nvme patch causes any
issues, but after previous experience i want to be sure

Signed-off-by: Leah Rowe <leah@libreboot.org>

certain code checks for build.list, to skip it, for
example in items()

we already use config/data/grub to store grub config data
that applied to all trees

create these directories too:

config/data/coreboot
config/data/u-boot
config/data/seabios

move the respective build.list files in here, and also
to config/data/grub

now multi-tree projects contain, per directory, just the
target.cfg file and the patches directory. this is much
cleaner, because some of the logic can be simplified more

Signed-off-by: Leah Rowe <leah@libreboot.org>