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>
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>
They may not actually always be binary blobs, at least not
software. I started referring to these as "vendor files" some
time ago, for this reason.
With this terminology, it applies properly to any sort of file
from the vendor. For example, it may be that in the future, we
start inserting the MFS section of an an Intel ME image, into
the Intel ME.
We already do that with deguard for example (set MFS config),
on MEv11 based setup. That is a vendor *file*, and though it
may still actually be a binary blob, it's not software, but
configuration.
The term "blob" normally means compiled software, in most people's
minds, but the term blob is technically accurate for any blob,
not just software; however, we have to keep people's perception
in mind.
Whereas, "vendor file" is also understood by most people to
include code supplied by the vendor.
We haven't done any releases yet with this ROM image file name
prefix, so it's perfectly OK to handle it now, without handling
the old one for backwards compatibility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Users running setmac on an X200 tarball for example, will
now see it being modified, if they didn't specify
setmac keep, so they might think vendor files are being
inserted, which they are not.
Therefore, a confirmation is provided at the end of the output.
Signed-off-by: Leah Rowe <leah@libreboot.org>
./mk inject libreboot-YYYYMMDD_board.tar.xz setmac restore
This does the same thing as a normal setmac command, except
that it does not alter the MAC address; it is also not the
same as "keep", which skips *writing* the GbE region in-ROM.
The *restore* argument writes the default, unmodified GbE file
kept by lbmk, unmodified because nvmutil is skipped when the
user specifies this argument.
This option is useful for debugging purposes, because it can
be used to verify whether anything else is being wrongly
modified by the script; the "nuke" command can be executed
afterward, and the hash file inspected versus release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
MAC addresses are generic, inside Libreboot images where
an Intel GbE region is specified.
We commonly get users flashing multiple systems for their
own use, and sometimes they complain that they networking
broke, because they don't know that the MAC address is
identical on each machine.
This still doesn't work around the case where the same machine
is used, e.g. multiple T440p thinkpads, but if they have one
of each model, it can work nicely, because we do in fact
change it for various platforms.
This change will also reduce the number of people at conferences
in the future, where there are multiple Libreboot users, having
MAC address conflicts.
Changing the MAC address is a good practise, so we enforce good
practise. The user can still retain the old behaviour by
using this command:
./mk inject libreboot-YYYYMMDD_boardname.tar.xz setmac keep
The "keep" argument clears new_mac, which will then skip
changing the MAC address. They can also still set an arbitrary
MAC address as an argument for setmac, e.g.:
./mk inject libreboot-YYYYMMDD_boardname.tar.xz setmac 00:de:ad:c0:ff:ee
This change will be covered in the documentation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
if the user ran this on an x60 tarball, the no-gbe
warning seems confusing since that one has intel gbe,
but pre-ifd, so no gbe region in the flash; on pre-ifd
systems e.g. ich7 southbridge, the mac address was baked
into a separate gbe nvm on mask rom, inaccessible to users
Signed-off-by: Leah Rowe <leah@libreboot.org>
We already have code to handle this, but it's possible
that I might break it in the future, due to the complex
logic of this script.
So, I've implemented this catch-all check at the end of
the process. It still relies on the actual setting of
the variables, upon which this check is based, to be set
correctly.
This condition will most certainly never be met, unless
I break some other part of the code in the future. That
is precisely what this overly pedantic check is for.
Example scenarios:
I forget to set xchanged=y, on a new modification.
I set has_hashes erroneously.
The variables are re-used between runs, and not properly
reset; at present, a given run of ./mk inject only
operates on a single target, but this latter fact could
change in the future.
need_files is set erroneously; vendorfiles detected as
being required, when they aren't.
These are just a few examples. As such, this is a preventative
bug fix, because it's preventing a bug.
The main reason I want this i n here is because I need to ensure
that vendor files are properly deleted, for a given release.
If I accidentally includes ones that I'm not supposed to,
inside ROM images, that could be a big problem.
Signed-off-by: Leah Rowe <leah@libreboot.org>
where the nuke command is used, we need the files to be
there; if they're not, it will try to nuke them, which will result
in an error in most cases, but there may be some cases where that
isn't true, for instance if only the Intel ME is needed; it'll be
writing zeroes over zeroes.
we want to only allow technically correct behaviour, because
technically correct is the best kind of correct.
it is theoretically possible that a double-nuke might affect
certain behaviours unpredictably. for example, if vendor.sh
later integrates another tool that works whereby the same command
inserts or nukes depending on a certain condition, but with the
same command, and where that command would return zero in both
cases.
this is a preventative bug fix, because it fixes an issue that
does not yet actually occur in practise.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the user must be well-informed as to the next step, which
this script directly influences
guide the user accordingly
Signed-off-by: Leah Rowe <leah@libreboot.org>
The message at the end that states a file was
not modified, is not currently printed when vendor
files are not needed, and setmac is not used.
This patch fixes that, so the user now sees a
confirmation of such change, or lack thereof.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is because the user may have specified setmac.
I tried without this change, on a fresh lbmk, setting
the MAC address on an X200 tarball, and it produced an
error that ifdtool was unavailable.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Observe the following prior patch:
commit 818f3d630c
Author: Leah Rowe <leah@libreboot.org>
Date: Fri Jan 3 17:06:14 2025 +0000
vendor.sh: Don't error if vcfg is unset
Now:
This patch made vendor inject more robust, and speeds
up the processing of images where no vendor files are
needed, but it broke setmac on such tar archives.
This new patch works around it. For example, I was
able to run ./mk inject on an X200 tarball to change
the MAC address; no vendorfiles are inserted, because
it's not needed.
The further check for whether a board uses Intel GbE
still protects against accidental modification.
Signed-off-by: Leah Rowe <leah@libreboot.org>
It should return 1 instead, in readcfg(), because this
is not an error condition; vcfg not being set means
that the board doesn't use vendor files, which is
perfectly normal and should not yield an error.
This fixes a build error under certain conditions,
found during release-build testing.
This bug was exposed when I fixed double quoting issues
as per shellcheck tests.
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>
Previously serprog_rp2040, but we now also support
the RP2530 boards.
Therefore, serprog_pico is a nice generic name. The
directory on release archives will now be serprog_pico
instead of serprog_rp2040; it will contain serprog images
for both RP2040 and RP2530 devices.
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>
use ./mk instead, because in a future change to lbmk,
only ./mk will be used and the other commands will
be removed.
with this change, the ./vendor, ./build and ./update
commands are no longer used. these commands still work,
for backwards compatibility, but they are deprecated.
Signed-off-by: Leah Rowe <leah@libreboot.org>
When vendor files were not needed on a given board,
the script would directly exit. This is bad, because
the inject functions are called directly from the main
script, which means the parent instance of lbmk.
This means that the lock file and temporary files were
not being removed on exit. On a subsequent run, this
would cause the error stating that a lock file is present,
which would cause further error, making the user believe
something is broken in lbmk.
Modify the behaviour accordingly; exits are now returns,
and these are handled in the calling functions, in such
a way that a proper exit occurs, whereby temporary files
and the lock file are deleted.
For context, please read the main "build" script where
it calls vendor_inject and vendor_download. At the end
of that script, it calls tmp_cleanup, which removes the
TMPDIR that was created, and the lock file. In lbmk,
the TMPDIR is not /tmp, but rather a subdirectory
under /tmp, so that further calls to mktemp create
everything under one single temporary directory, which
lbmk automatically removes on exit.
Therefore, this patch also avoids leaving temporary files
laying around on the disk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we needed these for extracting intel vga roms from
lenovoo updates, for t480, very briefly. about an hour
after i pushed that patch, mate kukri fixed libgfxinit
and then i removed the vgarom integration because it
wasn't needed anymore.
however, i forgot to remove geteltorito/mtools from
dependencies. some distros like fedora were problematic
about it.
the best thing about bugs is when you don't have to fix them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we encountered 1MB flash so far, but we may encounter other
sizes on other machines when added to libreboot later on
Signed-off-by: Leah Rowe <leah@libreboot.org>
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the previous commit changed an mv to a cp. what it hacked
was actually a relic of the vgarom download patch that i
did for t480, before mate got native video init working.
this patch is the better fix. i double checked to be sure,
and nothing was using the files at the copied location.
the _extracted directory under cache gets deleted later on,
so it's perfectly acceptable to keep.
the other alternative would have been to simply change
the path in the sch5545 function to appdir, instead of
the cache dir, but who really cares?
this patch removes bloat from lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I should have copied the extract directory, in cases
where it appears as filename_extracted/ under cache/,
but I was moving it instead.
Both locations (cache/file/*_extracted/
and vendorfiles/appdir/) get deleted, on every run of
the vendor script, per target, so this is OK.
The only sin is additional use of disk space, for
archives that are mostly very small and get immediately
deleted anyway.
This one lbmk bug, minor though it may be, prevented
the Libreboot 20241205 release, which (since it's now
the 6th of December) will become Libreboot 20241206
instead - and that gives me time to contemplate whether
I want to do one more change that I had planned for the 5th!
Signed-off-by: Leah Rowe <leah@libreboot.org>
Libreboot's binary blob reduction policy is crystal clear:
If a blob can be avoided, it must be avoided.
The ThinkPad T480 was using Intel's VGA ROM for graphics
initialisation very briefly, before Mate fixed libgfxinit.
Since libgfxinit is fixed, the Intel VGA ROM is obsolete,
so we should not be handling this at all.
Similarly, the Nvidia ROM handling has been removed, because
Mate is hard-disabling that in the coreboot code anyway, since
the Nvidia dGPU didn't work when tested anyway.
Even if it did, Libreboot's blob policy makes it clear
that Intel graphics with native init from coreboot is to
be the preferred option.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This uses the excellent deguard utility, written by
the excellent Mate Kukri.
A few bugs but it mostly works. Documentation to come
shortly, in lbwww.git.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe