these variables are initialised empty, then populated
by reading a configuration file.
it may be that in some cases, we want these variables
to be empty. besides that, the "setcfg" command before
it will throw an error if the module file is missing,
and it is assumed that the variables would be set there.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the current check is flawed, because if u-boot doesn't
exist, but a given build would be the file verified by
the first check, the check would still fail even after
then building u-boot.
building it first will make this check pass, under such
a condition.
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead, make it a helper function, defined in target.cfg
this means that we can also do the same with other projects
in the future, and it is expected that we will have to.
these helper functions are used in cases where we want
additional actions to be performed.
actually, the helper could be anything. for example, you
could write:
mkhelper="./build foo bar"
and it would do that (at the point of execution, PWD
is the root directory of the build system)
Signed-off-by: Leah Rowe <leah@libreboot.org>
the script used to support building multiple single-tree
projects, but this behaviour was buggy and unused, so it
was removed.
rename the build_projects variable accordingly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it was always by design that an error should occur, if a
target.cfg file does not exist on multi-tree projects,
but we previously did not support target.cfg files on
single-tree projects.
single-tree target.cfg support was later added, and it was
done by making target.cfg optional there, but i accidentally
made it optional on multi-tree projects.
in practise, all multi-tree projects included target.cfg,
but this was not being enforced in code.
this patch should fix the issue.
Signed-off-by: Leah Rowe <leah@libreboot.org>
set it to "auto", because otherwise it'll be unset,
which means that kconfig type is assumed.
the build system is designed in such a way that multi-tree
is assumed, if the target build system uses kconfig files.
target.cfg is optional on single-tree but not multi-tree,
so it's ok to set something here.
basically, kconfig-type projects will never be single-tree.
Signed-off-by: Leah Rowe <leah@libreboot.org>
don't hardcode the check based on whether the current
project is grub. instead, define "btype" in target.cfg
if unset, we assume kconfig and permit kconfig commands
e.g. make menuconfig, make silentoldconfig, etc
this is to avoid the deadliest of sins:
project-specific hacks
Signed-off-by: Leah Rowe <leah@libreboot.org>
the current logic for handling multiple single-tree projects
is quite error-prone, and uses recursion.
since we don't actually use it this way, remove that feature.
the most correct way to do it is with a for loop.
Signed-off-by: Leah Rowe <leah@libreboot.org>
doing nothing means that if a flag is passed, and then
another flag overriding it, the resulting action will
not be correct; only one flag should be provided anyway,
but some users may feel a bit more adventurous.
mitigate it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
otherwise, release=n is ignored and an image is built in
the elf/ directory, even if it's still skipped for bin/
avoid doing unnecessary work per-release by checking the
variables before building coreboot via script/trees
Signed-off-by: Leah Rowe <leah@libreboot.org>
we don't need this message here, because the final confirmation
at the end of main() says which targets were built. saying what
individual rom images were built is just needless bloat,
especially with the new simplified lbmk design; we no longer
provide lots of rom images with different keymaps, because we
now expect the user to insert a gkb file themselves with cbfstool.
Signed-off-by: Leah Rowe <leah@libreboot.org>
because we use crossgcc here, blindly running trees -f
means needlessly re-running buildgcc, which then checks
for gcc binaries, even though we already know that the
u-boot binary exists. skip this check if u-boot exists.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we're building it per coreboot configuration file, rather
than per-target; the latter is more appropriate, and saves
on compilation time.
do it per-target.cfg, not per coreboot configuration.
this works because the trees script compiles all images
per target, for each given coreboot configuration within
that target, e.g. libgfxinit _corebootfb and _txtmode.
Signed-off-by: Leah Rowe <leah@libreboot.org>
sometimes buildgcc just fails for like no reason. we had this
the other day and another fix was made to the trees script, to
mitigate; the user ran it again and buildgcc worked just fine.
run it twice, and then call err only if the second one fails.
Signed-off-by: Leah Rowe <leah@libreboot.org>
just run the make crossgcc command anyway.
coreboot's own build system checks itself, and much
more reliably, but the check is more thorough and a bit
slower.
in rare cases, lbmk may come into build issues with xgcc,
and if you run the build again, it will always fail every
time because the checks is based on whether the xgcc
directory exists, rather than checking each
individual crossgcc binary.
checking every binary is also possible, but as i said,
the coreboot build system already does that, so let's defer
to coreboot's own handling of it.
remove the directory check. this will slow down the build
process a little bit, but should improve reliability under
fault conditions.
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>
due to lbmk issue #216, it is now unwise to use grub as the
primary payload on any machine; the sheer complexity of grub
and the number of memory corruption bugs that have been fixed
due to auditing over the years, means more such bugs exist.
we now provide seabios as the primary payload on all x86 ports,
but provide a "grubfirst" configuration where a bootorder file
in seabios can be added via cbfs, which tells seabios to load
grub from cbfs first, while still allowing use of the boot select
menu by pressing esc in seabios.
well, the "grubonly" option also disables the seabios esc menu,
so that *only* grub runs. there is no point in using this unless
you want to harden your setup, for example if you want to set up
encrypted /boot and boot that from grub, and have a grub password
disallowing unauthorised bootup of your machine.
see grub hardening guide;
https://libreboot.org/docs/linux/grub_hardening.html
at least as of today, 22 June 2024, that page already says
how to manually disable the seabios menu in the same way, if that
is the setup you want. alternatively, a user may be wily
enough to edit target.cfg for their board and compile a rom
that only has the grub payload in it, if that is what the user
wishes to do.
regardless, the default configurations provided by lbmk must never
be unsafe, norc should the build system support such unsafe
settings;
yes, grub as primary payload is technically still supported in
lbmk. actually, at the time of this revision, i have half a mind
to remove that functionality altogether, so that only seabios is
allowed as primary payload, when compiling a rom image that also
has grub, chainloading grub from the seabios menu instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's bloat. telling the user to rtfm is something that
we already do on irc; they will still ask how to do
everything, and ignore the message from badcmd(), or
they will automatically know to rtfm.
i'm on a massive purge, removing bloat from lbmk as
part of Libreboot Build System Audit 6.
all bloat must go.
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>
do not use shorthand here. the test was failing to
produce the desired result under some circumstances,
for example when i did "./update release" i got this:
make: Entering directory '/home/lbdev/lbmk/release/20240612-62-ga6b1a6bd/libreboot-20240612-62-ga6b1a6bd_src/src/stm32-vserprog'
make: *** No rule to make target 'fetch'. Stop.
make: Leaving directory '/home/lbdev/lbmk/release/20240612-62-ga6b1a6bd/libreboot-20240612-62-ga6b1a6bd_src/src/stm32-vserprog'
ERROR script/trees: !mk src/stm32-vserprog fetch
ERROR ./update: excmd: script/trees -f
ERROR script/roms: Unhandled non-zero exit: ./update
ERROR ./build: excmd: script/roms serprog
ERROR ./update: build_release release/20240612-62-ga6b1a6bd: stm32
ERROR ./update: can't build rom images
in the above circumstance, run_make_command was executed,
which is not the desired behaviour; rather, fetch_project_trees
or fetch_project_repo should be called, and then the script
should immediately exit. it should also exit, without downloading
anything, if a changelog file exists as in release archives.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 3610667e3d.
The output of some functions in the roms script are used as
an argument in cp and mv commands, also cbfstool. I overlooked
this fact in a previous code optimisation.
Revert it. The change only reduced sloccount by a few lines
anyway.
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>
i disabled a check in the script, while testing a prior
modification. re-introoduce the check, which is put there
to yield an error condition if no targets were compiled.
Signed-off-by: Leah Rowe <leah@libreboot.org>
payloads are compiled before coreboot, but it doesn't matter
to the build speed whether this is done first.
reduce the lines of code by checking payload builds *while*
adding them to the coreboot images. this means that coreboot
is now compiled first, before the payloads.
Signed-off-by: Leah Rowe <leah@libreboot.org>
nowadays, we don't insert GRUB keymaps automatically, for
sake of efficiency; without one, the default is US QWERTY.
a user will only want one keymap in particular, so this
is more efficient. in practise, they're either building
from source anyway, or using the inject scripts which
compile cbfstool anyway, so the user will already have
cbfstool.
also output this message from the inject script.
Signed-off-by: Leah Rowe <leah@libreboot.org>
there are two for loops that use x as a variable anme,
and an idiosyncrasy of certain sh implementations is
that these become global;
the result in this case was that when you finish building
every target in "./build roms", it would print "libgfxinit"
repeatedly, comma separated, instead of a comma-separated
list of the targets that were built.
work around it by renaming the variable in one of the loops.
Signed-off-by: Leah Rowe <leah@libreboot.org>
cbcfg is already a global variable, so there's no reason
to set it again at the start of this function.
remove the check for whether the given coreboot config
exists, to the calling function instead of build_roms().
Signed-off-by: Leah Rowe <leah@libreboot.org>
we don't need to call mktemp everytime.
just use a staticly named file in tmpdir
and keep overwriting it.
these files are only small, and they get deleted
when the build system exits later on.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we don't need to check whether this variable is set,
because checking an empty path will also cause the
same return in the next line.
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>
if not inserted, the default keymap is usqwerty.
don't waste ssd write cycles copying so many images,
or cpu time compressing so many. the user can simply
add a keymap.gkb file to cbfs and it will work fine.
this will be documented in the next release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
rely on return status per each of the three main rom
functions, to then update the "targets" variable.
use this as the basis to determine which targets were
built, during final confirmation when the script exits.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the current validation check is extremely over-engineered,
because the user override is no longer available and we're
always very careful in how we modify target.cfg per board.
remove the redundant code. trust that target.cfg is correct.
Signed-off-by: Leah Rowe <leah@libreboot.org>
p = payload
s = grub_scan_disk
d = displaymode
setting the payload is no longer safe, due to issue 216
and similar issues that might pop up in the future; it's
best left only to target.cfg, per board, so that we know
what config is safe/tested. don't let the user override it.
scandisk isn't safe to override because the given machine
may not have the type of device that the user specifies
displaymode is actually ok to set, because it simply whitelists
what configs pre-existing to actually use, but it's bloat
basically, the rule is this:
don't make it easy for the user to brick their hardware.
make it harder instead.
a user wily enough to go modifying their payload will probably
have read docs/maintain/ anyway and knows how to edit target.cfg
if they want another board configuration.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe