The previous stability issues were resolved, thanks to
the previous revision which added a fix courtesy Simon Glass.

This reverts commit eba73c778a85d1c6ad2f0de57c82a8775cdd1c17.

It's really buggy on hardware. Disable for now.

I've contacted Simon Glass on IRC, asking about hardware.

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

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

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>

Re-add xHCI only on haswell and broadwell machines, where
they are needed. Otherwise, keep the same GRUB code.

The xHCI patches were removed because they caused issues
on Sandybridge-based Dell Latitude laptops. See:
https://codeberg.org/libreboot/lbmk/issues/216

The issue was not reported elsewhere, including on the
Haswell/Broadwell hardware where they are needed, but the
build system could only build one version of GRUB.

The older machines do not need xHCI patches, because they
either do not have xHCI patches, or work (in GRUB) because
they're in EHCI mode when running the payload.

So, the problem is that we need the xHCI patches for GRUB
on Haswell/Broadwell hardware, but the patches break
Sandybridge hardware, and we only had the one build of GRUB.
To mitigate this problem, the build system now supports
building multiple revisions of GRUB, with different patches,
and each given coreboot target can say which GRUB tree to use
by setting this in target.cfg:

grubtree="xhci"

In the above example, the "xhci" tree would be used. Some
generic GRUB config has been moved to config/data/grub/
and config/grub/ now looks like config/coreboot/ - also,
the grub.cfg file (named "payload" in each tree) is copied
to the GRUB source tree as ".config", then added to GRUB's
memdisk in the same way, as grub.cfg.

Several other design changes had to be made because of this:

* grub.cfg in memdisk no longer automatically jumps to one
  in CBFS, but now shows a menuentry for it if available

* Certain commands in script/trees are disabled for GRUB,
  such as *config make commands.

* gnulib is now defined in config/submodule/grub/, instead
  of config/git/grub - and this mitigates an existing bug
  where downloading gnulib first would make grub no longer
  possible to download in lbmk.

The coreboot option CONFIG_FINALIZE_USB_ROUTE_XHCI has been
re-enabled on: Dell OptiPlex 9020 MT, Dell OptiPlex 9020 SFF,
Lenovo ThinkPad T440p and Lenovo ThinkPad W541 - now USB should
work again in GRUB.

The GRUB payload has been re-enabled on HP EliteBook 820 G2.

This change will enable per-board GRUB optimisation in the
future. For example, we hardcode what partitions and LVMs
GRUB scans because * is slow on ICH7-based machines, due
to GRUB's design. On other machines, * is reasonably fast,
for automatically enumerating the list of devices for boot.

Use of * (and other wildcards) could enable our GRUB payload
to automatically boot more distros, with minimal fuss. This
can be done at a later date, in subsequent revisions.

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

these laptops do not officially have nvme slots on them,
but there is an ngff wifi slot which is PCI-E x1, and you
can use a special adapter on it to run nvme ssds.

total throughput is retarded by the x1 PCI-E configuration,
but it's still faster than a sata ssd (nvmes are x4 PCI-E).

support it in grub_scan_disk on the off chance that some
users may make use of this. it should work just fine.

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

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