write to .version and .versiondate, instead
of version and versiondate.
this will hide them to avoid visual clutter while
analysing files within lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead of running pwd all the time, run it once in lib.sh,
and export PWD.
for lbmk-specific use of PWD, use xbmkpwd, which contains
the value of PWD as was set by the pwd utility in lib.sh.
many parts of lbmk rely on pwd, and it *must* be correct.
this change adds basic error handling, since pwd can in
fact return errors in some cases.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's incorrect for PATH not to be set, but some users
may foolishly blank it out before running lbmk.
prevent such issues, by initialising it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
PWD could be anything, if the user manually exported
it before running lbmk.
always run pwd instead, to get the real string.
Signed-off-by: Leah Rowe <leah@libreboot.org>
several code lines were condensed together, which
make them less readable. make the code more readable
by having separate commands on separate lines.
i previously did this during my manic build system
audits of 2023 and 2024; condensing lines like this
is overly pedantic and serves no real purpose.
Signed-off-by: Leah Rowe <leah@libreboot.org>
See:
https://docs.python.org/3/library/sys.html#sys.version_info
The sys.version_info tuple is a more reliable way to
get the version. Our previous logic assumed that Python
would always output "Python versionnumber", but this may
not always be how it works. We've seen this for example
where Debian modifies some GNU toolchains to include Debian
something in the output.
Python has a standard method built in for outputting exact
the information we need. In my system, what I got was this:
(3, 11, 2, 'final', 0)
That output was from running this command:
python -c 'import sys; print(sys.version_info[:])'
This is much more robust, so use this instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we already check the python version, and set a variable
for it, so that we can reliably use python3, even if
python in PATH doesn't correspond to python3. for
example if a system has python as python2 and python3
as python3
well, we use that when running deguard for example, but
various upstream projects that we use may need python,
and all of them use python3, not 2
so, re-use the python variable set up by lbmk, and
set it up in PATH accordingly. this now makes the note
about python3 obsolete, on docs/build.md in lbwww.git
Signed-off-by: Leah Rowe <leah@libreboot.org>
it should fix more build errors that might have appeared
in the aforementioned revision, mentioned in the previous
commit message
Signed-off-by: Leah Rowe <leah@libreboot.org>
the bug was actually caused by chkvars
add an escape for the quotes and bam. fixed.
without this, i got the following e.g.
For command: ./mk dependencies debian
Output:
./mk: 1: [: apt-get: unexpected operator
ERROR ./mk: pkg_add unset
Someone reported a similar issue with the Arch one,
which is also now fixed. This regression was caused
by the previous commit:
commit 0cf58c2273
Author: Leah Rowe <leah@libreboot.org>
Date: Thu Jan 2 23:52:45 2025 +0000
fix lbmk shellcheck errors
I forgot to escape the double quotes in an eval.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i also removed that printf, because the path it prints is
actually wrong sometimes; in the recent re-write of vendor.sh,
it prints the correct path instead
Signed-off-by: Leah Rowe <leah@libreboot.org>
There was also a condition in run_make_command that is now
an OR, where it was an AND, on script/trees, to fix the use
of mixed (and erroneous) OR/AND operators.
I'm planning a much more invasive audit than this. These are
light fixes, intended for Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I believed that the compressed nature of refcode was the only
non-reproducible thing, but turns out you also need to run
rmodtool on the refcode to make the binary relocatable in
cbfs. This is based on my reading of the coreboot Makefile.
With this change, I can now provide release binaries for
the HP EliteBook 820 G2.
Signed-off-by: Leah Rowe <leah@libreboot.org>
./mk dependencies debian --reinstall
Add --reinstall and it'll do:
apt-get install --reinstall
This can be useful when updating from a stable release
to a testing release. The variable, "reinstall" can be
configured for other distros, but it's currently only
configured for Debian-based distros.
Also, it can be anything. For example, you could add -y;
however, a 4th argument will not be accepted. For example,
you cannot do:
./mk dependencies debian --reinstall -y
If you do this, it'll only see --reinstall; similarly, if
you did this command:
./mk dependencies debian -y --reinstall
then -y would be passed, but not --reinstall. This is an
intentional design decision, in case you accidentally pasted
or subshelled something that outputted something undesirable,
to prevent possible abuse.
Signed-off-by: Leah Rowe <leah@libreboot.org>
When doing ./mk release, the build system would create
symlinks inside xbmkpath/ relative to the current work tree,
which will differ from what's in PATH.
Since XBMK_CACHE is already set globally, from the main work
tree and the release-build work tree, that means we can know
reliably that PATH is always correct if we put xbmkpath/
inside XBMK_CACHE.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Remove all symlinks each time, to ensure that no
stragglers are left behind, since they are being
re-generated each time anyway.
The code for determining version numbers has now
been unified under gnu_setver()
Signed-off-by: Leah Rowe <leah@libreboot.org>
When doing e.g. $@ we should use double quotes to prevent globbing.
Thanks go to XRevan86 for pointing this out.
Signed-off-by: Leah Rowe <leah@libreboot.org>
When I tested Debian Trixie, and Debian Sid, I saw that
GCC in PATH pointed to gcc-14, but gnat in path pointed
to GNAT-13, even if you manually install gnat-14.
GNAT 14 was marked experimental, but GCC 14 was marked
for use, in the apt repositories.
So this patch doesn't address the mismatch when doing e.g.
apt-get install gcc gnat
I will address the actual package dependency in a follow-up
patch, on the Debian dependencies config.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The exit was dependent upon install_packages returning
zero status, which it always would in practise, due to
its design, but this exit must always be observed, so
the code has been modified to honour this design.
A direct exit violates lbmk's design in most instances,
where a temporary directory and lock file has already
been created; at this stage, no such act was performed,
so a direct exit is perfectly acceptable.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Currently seems to stall when booted from the GRUB
payload, but works when booted from the SeaBIOS menu.
I also tested it as a standalone payload and it seems
to boot. Will test on hardware next, and start adding
it to more mainboards.
Signed-off-by: Leah Rowe <leah@libreboot.org>
NOTE: Support added for xarch target x86_64-elf,
but U-Boot failed to build with this error:
OBJCOPY lib/efi_loader/helloworld.efi
x86_64-elf-objcopy: lib/efi_loader/helloworld_efi.so: invalid bfd target
make[2]: *** [scripts/Makefile.lib:476: lib/efi_loader/helloworld.efi] Error 1
Since I'm building U-Boot for x86_64 *on* an x86-64
host, and since that is currently the recommended type
of machine to use for lbmk development, and since the
other x86 payloads currently don't cross compile anyway,
this is an acceptable compromise for now. This is because
at present, I'm not making U-Boot the primary payload on x86,
instead preferring to chain it from GRUB and SeaBIOS.
The target.cfg file for x86 u-boot shows xarch/xtree commented.
Uncomment these to compile on crossgcc instead of hostcc.
I mention 64-bit because I initially did this first, but decided
to do 32-bit first. I'll work on the 64-bit one next (SPL).
It's only enabled in QEMU for now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
single-tree projects cannot be handled in bulk, e.g.
./mk -f project1 project2 project3
that is still the case, from the shell, but internally
it is now possible:
mk -f project1 project2 project3
mk() is a function that simply handles the given flag,
and all projects specified.
it does not handle cases without argument, for example
you cannot do:
mk -f
arguments must be provided. it can be used internally,
to simplify cases where multiple single-tree projects
must be handled, but *also* allows multi-tree projects
to be specified, without being able to actually handle
trees within that multi-tree project; so for example,
you can only specify coreboot, and then it would run
on every coreboot tree.
Signed-off-by: Leah Rowe <leah@libreboot.org>
XBMK_CACHE is now used, instead of hardcoding cache/
this is exported initialised to cache/, if unset.
this means you can set your own directory, and it means
./update release will use the same directory.
this means bandwidth wastage is further avoided.
Signed-off-by: Leah Rowe <leah@libreboot.org>
lib.sh download() is used by subfile handling in git.sh,
e.g. crossgcc tarballs, and also the vendor scripts.
vendor files are cached, but not subfiles for repos.
cache both, under cache/file/, saved with the name equal
to the checksum, so: cache/file/CHECKSUM
also move vendorfiles/app/ to cache/app/ in this change.
Signed-off-by: Leah Rowe <leah@libreboot.org>
stub it from the trees script. the way it works now,
there is less code in the build system.
./build roms
this is no longer a thing
./build roms serprog
this is also no longer a thing. instead, do:
./update trees -b coreboot targetnamehere
./update trees -b pico-serprog
./update trees -b stm32-vserprog
the old commands still works, which causes the new
commands to run
coreboot roms now appear in elf/, not bin/, as before,
but those images now contain payloads.
NOTE: to contradict the above: ./build roms is no
longer a thing, in that it's now deprecated, but
backward compatibility is present for now. it will
be removed in a future release.
./build roms list also still works! it will do:
./update trees -b coreboot list
also:
./update trees -b grub list
this is now possible too
if a target "list" is provided, for multi-tree sources,
the targets are shown.
there is another difference: seagrub roms are now seagrub_,
instead of seabios_withgrub.
seabios-only roms are no longer provided, where grub is also
enabled; only seagrub is used. the user can easily remove
the bootorder file, if they want seabios to not try grub first.
Signed-off-by: Leah Rowe <leah@libreboot.org>
testing +x is all well and good, but the variable string
may be empty, even if set. some of the checks in the build
system are relying on the latter, so handle it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
