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

The -c option is added for distclean, and -x for crossgcc-clean,
in handle/make/config

about 100 sloc removed from lbmk

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

x86 u-boot is a bit flaky and this board never builds.

re-add it ot a later date.

u-boot is only really used in arm machines,
for our purposes at least.

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

See file:
resources/scripts/build/defconfig/for
It is based on:
resources/scripts/build/payload/u-boot

The u-boot payload script has been deleted, as has the
seabios payload script; the build/boot/roms logic has
been heavily simplified too, by removing the logic for
building of elf files based on defconfig.

SeaBIOS, U-Boot and coreboot all use defconfig-type
infrastructure for their build systems, and they are
fundamentally the *same* in how to compile each codebase,
at least in an lbmk context, regardless of actual (and
very huge) differences in these codebases.

Several hundred sources-lines of code have been eliminated
by this change, drastically simplifying everything; U-Boot
payload compiling also now errors out when a single build
fails, instead of continuing. Also: build/boot/roms no longer
re-compiles a coreboot target that was already compiled,
which is the same behaviour observed for payloads.

(this means you must now manually delete a target, when you
wish to re-build it; the build/boot/roms logic now more or
less just runs cbfstool; blobutil is handled from
build/defconfig/for)

ALSO: Since crossgcc is now handled by build/defconfig/for, not
build/boot/roms, standalone compiling of u-boot is now possible.
This has been tested. You compile it like so:
./build defconfig for u-boot
or specific trees, e.g.
./build defconfig for u-boot default

One other consequence of this patch is that re-building the same
ROM image is now much faster, because the same builds are re-used
unless deleted. This could be useful when testing grub.cfg changes,
for example, if that's all you change. With things like ccache used
(not yet used robustly in lbmk), this could speed things up more,
depending on the codebase.

This patch demonstrates the raw power of lbmk; it is a very
simple and highly efficient build system, and now much more so!

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

they are fundamentally the same, in an lbmk context.

they are downloaded in the same way, and compiled in
the same way!

(Kconfig infrastructure, board-specific code, the way
submodules are used in git, etc)

~200 sloc reduction in resources/scripts

the audit begins

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

Debian's signed shim allocates too many EFI variables to fit in the EFI
variable memory buffer. Normally it would then try to continue booting
in non-secure-boot mode, but its error handling throws a synchronous
abort that reboots the board, making it impossible to boot into Debian
unless one manually loads GRUB instead of shim. Increase EFI variable
buffer size to avoid triggering the bug.

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>

not well-tested, and existing testing has revealed video
issues on some of them (or just no boot)

for now, retain only qemu and gru-* on arm

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

bl1 bootloader blobs needed, and lbmk doesn't currently
auto-download these for insertion, so their presence in
the build system is problematic because people might build
these and think they work - they don't, due to the lack of
those bl1 blobs

notes about this are included in lbwww, on the compatibility
list. these can be re-added and tested later, when lbmk handles
those bl1 bootloader blobs

u-boot is known broken on these, last revision
known working is 2021.01

can bisect and find the fix. i'm putting this on
the issue tracker (new one on codeberg)

U-Boot can be configured via environment variables which can be saved to
various storage devices. This usually defaults to MMC or SPI depending
on where it boots from, but assumes the device's layout is controlled by
U-Boot.

We should store the environment in SPI flash, but we also need to
configure coreboot FMAPs to reserve the area U-Boot would use as its
environment storage. For now, disable environment storage by setting
ENV_IS_NOWHERE=y to avoid overwriting random regions of SPI or MMC if
someone tries to save the variables.

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>