sha-1 has known collision issues, which may not be readily
exploitable yet (in our context), but we should ideally use
a more secure method for checking file integrity.
therefore, use sha-2 (sha512sum) for checking files. this is
slower than sha-1, but checksum verification is only a minor
part of what lbmk does, so the overall effect on build times
is quite negligible.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Tested on a Nucleo-F042K6.
That has an onboard stlink:
`st-flash --format ihex write bin/serprog_stm32/serprog_nucleo-f042k6.hex`
The usb port used for flashing is separate, its is exposed on
the pin header instead. Check boards/nucleo-f042k6.h for usb pinout.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
where it is set to "both" (grub_scan_disk), inserting
scan.cfg is superfluous, because grub.cfg defaults to
both anyway, unless otherwise specified by scan.cfg,
and only if that file exists within cbfs.
thus, save a bit of build time (only a slight saving)
Signed-off-by: Leah Rowe <leah@libreboot.org>
target.cfg can now specify e.g.
grub_timeout=20
this would then be inserted as timeout.cfg in cbfs,
containing the instruction:
set timeout=20
HP laptops need a bit of extra time, due to the delay
caused by the EC bug workaround deployed in GRUB
desktops in general need extra time. this too is set to
10s, like the HP laptops.
only insert timeout.cfg if actually needed (declared in
target.cfg), otherwise grub.cfg will default to 5s
Signed-off-by: Leah Rowe <leah@libreboot.org>
My previous patch b0rked memtest and others because when making sure
their parent directory (the project root) exists, it would instead create
the project directory (memtest86lus). The later move would then put the
git repo inside that (memtest86plus/memtest86plus_123456).
We just need to make sure we don't create the target directory itself.
This way, there's no need to hardcode any project names.
Tested by ./updating rpi-pico-serprog, memtest86plus, grub and seabios.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
for example, the beep sound in debian's installer needs
this module.
the cute ding in the arch/artix menu also needs it
Signed-off-by: Leah Rowe <leah@libreboot.org>
it doesn't really make sense to have nvmutil.h
since this is only a very small program and not
intended for use as a library
Signed-off-by: Leah Rowe <leah@libreboot.org>
we are copying large numbers of ROM images, and the
host system may have /tmp under a tmpfs; that same
host system may or may not have a lot of memory.
respect the user's machine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we must conserve memory usage, in the event that the
user's /tmp is a tmpfs. copying of ROM images into
tmpfs is ill advised; we must copy them, due to how
the release process works (e.g. stripping of blobs,
but this must be done in a way so as to not interfere
with regular builds, thus they are copied instead)
Signed-off-by: Leah Rowe <leah@libreboot.org>
now under coreboot mainboards, target.cfg can specify
a background. if not specified, the 1280x800 one is
assumed, and used by default. it can be overridden.
the path should be relative to:
config/grub/background/
Signed-off-by: Leah Rowe <leah@libreboot.org>
explicitly set the count to 3, so that a maximum of 3
attemps are made per download, barring fatal errors such
as http 404.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the /tmp/ file system may be a tmpfs, with conservative
memory limits, depending on host system.
it's more likely that the user will have enough disk space
under tmp/ within lbmk (if they don't, they can't use
lbmk anyway). that is to say: more likely that they would
have the disk space, but not the memory.
Signed-off-by: Leah Rowe <leah@libreboot.org>
check based on whether defconfigs are available, which
are used extensively, rather than checking based on
whether target.cfg is available, which is not used
Signed-off-by: Leah Rowe <leah@libreboot.org>
also: only return zero status if rom images were succesfully
built, and print a list of each rom image directory based on
what was actually compiled, rather than just saying that the
rom images are stored under bin/
Signed-off-by: Leah Rowe <leah@libreboot.org>
the handling of target.cfg is *not* required, in
this script. other mechanisms are also used for
error checking. this script only uses defconfigs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this causes a saving of about 131KB uncompressed, when
i tested. we don't need mach kernel support. nobody will
ever use it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this causes a 6.7% decrease in the payload size
these file systems are microsoft(fat, ntfs) or mostly
oldschool amiga and beos file systems
also remove minix modules, and some old linux file
systems that nobody will use in 2023
Signed-off-by: Leah Rowe <leah@libreboot.org>
they weren't even handled at all, but they were referenced
under coreboot configuration
they don't need to be handled. lbmk simply includes these files.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it doesn't really make sense for them to be under
blobs/ - nominally, they are blobs, but they are
well-understood data files containing config data,
that is easily parsed by tools like ich9show or
ifdtool (and tools like bincfg or nvmutil)
blobs/ has been re-purposed: this directory no longer
exists in lbmk, but it is created (and on .gitignore)
when needed, by blobutil
thus, the blobs/ directory shall only contain vendor
files, and only those files that libreboot scrubs from
releases. therefore, build/release/src can (and has
been) simplified; it currently copies just the ifd and
gbe files from blobs/, selectively, and this logic is
quite error prone, requiring maintenance. now, the
build/release/src script simply copies config/ (which
only ever contains distributable files) and entirely
ignores the blobs/ directory
the blob download script already creates the required
directory, except for the sch5545 download; this is
now fixed
lbmk code size is slightly smaller, due to this patch
Signed-off-by: Leah Rowe <leah@libreboot.org>
the resulting changes are what i will push. this prevents
the coreboot build system from asking for user input.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This cuts down on build time, and it will allow libreboot
to remove large chunks of code.
these ifd/gbe configs are just binary-encoded config files,
in a format well-understood. they can easily be opened up
and displayed, using ich9show or ifdtool, and manipulated
by these tools; bincfg can generate them from scratch, and
nvmutil can change mac addresses, for example.
so, do this and remove from lbmk the following:
* ich9utils (which contains ich9gen) - not needed anymore
* code in lbmk for handling ich9gen and insertions; the
coreboot build system is now used, for this same purpose,
so remove such code from lbmk
this results in a massive code size reduction (thousands of
lines) in lbmk; smaller when only looking at the build
system, but much larger when you consider that ich9utils
is also removed (about 3k sloc)
Signed-off-by: Leah Rowe <leah@libreboot.org>
a follow-up patch will make use of these, rather than ich9gen,
and ich9gen will be deleted.
these files were in fact generated *by* ich9gen.
coreboot has ifdtool and bincfg, the latter of which can
generate both ifd and gbe files for ich9m. that, and nvmutil
which is part of libreboot, can change gbe mac addresses.
i was going to replace ich9gen with a script that would run
bincfg, ifdtool and nvmutil, to greatly reduce code size,
because ich9gen is about 3k sloc.
however, in practise we would always generate the same ifd
config, and basically only change the mac address if that's
what the user wants; nvmutil can already do that just fine.
so, just include the binaries directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the mkdir command in update/project/repo, added for
pico-pi integration, broke a bunch of other downloads.
the fix is a bit of a hack but it should hold for now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This was only tested on the iGPU model, though a dGPU model does exist.
The vendor firmware used a 16KiB gbe.bin, which was modified with a
random MAC address as well as shrinking it to 8KiB. As with the E6400,
GRUB doesn't like the way the EC implements the keyboard controller and
thus GRUB payloads are disabled at this time. Suspend does not currently
work, and this is believed to be due to the EC controlling the DRAM
reset gate which is required to prevent DRAM from being reset on resume.
With some tweaks, the e6400-flash-unlock utility also works on this
system, though both flash chips can be accessed through removal of only
the keyboard.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
More than 90% of cats were thus terminated.
read (shell built-in) is better at reading, and dogs are better pets.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Leah Rowe