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>
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>
rp2040 and rp2530 platforms can't share a cmake build directory. we
could just delete the build directory after every compilation, but that
would be really wasteful (every tool would need to be recomiled every
time. instead create new build directories as new plaforms are found
and symlink them to the point where the build directory used to be.
to find out which platform we're compiling for, we crudely parse the
board headers file.
there surely would be better ways to do this, but this hack works
with all the boards in pico-sdk 2.1.0.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
set this variable in the tmpclone function. otherwise,
certain submodules might always download every time,
when handling multiple projects.
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>
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>
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>
in this setup, seabios is never the default payload, grub is,
but only if grub is enabled.
set this in target.cfg:
payload_grubsea="y"
if payload_grub isn't enabled, this is auto-set to n
ditto if initmode=normal
NOTE: if flashing libgfx setups, you should make sure
that you're not booting with a graphics card, only intel
graphics. this setting will intentionally not be documented,
because it's not recommended, but is being implemented for
testing purposes (and i implemented it for some guy who i
think is cool). i'll probably also use this myself, since
i already do grub-only setups on all my own machines.
seagrub is the default on x86 because of past instabilities
with grub. to mitigate in case of future issues, since seabios
is always stable, we reduce the chance of bricks.
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>
for some reason, when the background is in memdisk, inserting
it into cbfs afterward doesn't override, despite this
being the behaviour in grub.cfg
put it in cbfs explicitly, and skip inserting into memdisk
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>
I'm adding ThinkPad T480 support next, which requires
the new revision of deguard. Mate Kukri changed the way
deguard is used, in a rewrite of the project, so lbmk
has to change too.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Since U-Boot must be inserted at a specific offset, it's
theoretically possible that other files might overlap, but
cbfstool will work around wherever U-Boot was inserted if
it was inserted first; we don't use specific offsets for
the other files.
This is technically a preventative bug fix, but it fixes
a bug that would probably never occur in practise.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is not a main script, and should not be treated as such;
it must never be directly executed by the user.
This script was only ever used inside other scripts, so the
shebang didn't seem to do much at all, but it shouldn't be
there anyway.
Remove it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The "normal" mode in lbmk is where no built-in GPU exists,
or no libgfxinit is used, and SeaBIOS is the first payload,
and SeaBIOS executes VGA ROMs (can't know if it'll start
in VESA or text mode).
U-Boot needs a VESA framebuffer or native coreboot
framebuffer to work correctly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Same concept as SeaGRUB, but for U-Boot. SeaBIOS starts, but
has a bootorder file loading U-Boot first, from flash.
You can interrupt it with the ESC menu, to boot something else
in SeaBIOS, including GRUB.
With this, we can effectively provide extremely user-friendly
UEFI-first setups in Libreboot.
Take that, edk2!
Signed-off-by: Leah Rowe <leah@libreboot.org>
For some reason, 32-bit U-Boot only works when executed from
GRUB, but not SeaBIOS; 64-bit U-Boot only works from SeaBIOS!
This will have to be investigated. Standalone U-Boot, where
U-Boot is the primary payload, has not yet been tested in
Libreboot, and will not be provided for some time due to
stability concerns. More testing is needed!
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>
Remove what is now unnecessary bloat, for ensuring that
GRUB is the primary payload; SeaGRUB is the only preference,
as per lbmk design.
The SeaBIOS hanging issue was fixed, so SeaGRUB is OK now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the .git directory never exists anyway, when doing a release,
so the purpose this is intended is defeated by lbmk's design.
individual headers say "pcsx-redux team" as copyright anyway,
and the code for generating that COPYING file, with MIT license
and correct years (matching the entire source code for the
open bios) remains correct.
a mitigation instead of this patch might be to maintain a hardcoded
list of authors, and manually update it over time, but this is not
required. however, it may be good practise for upstream to maintain
such a file. perhaps i should contact them?
Signed-off-by: Leah Rowe <leah@libreboot.org>
The deguard utility is executed within a subshell, and
the subshell does not handle error status. This patch
fixes that, so that the main shell also exits non-zero.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I also checked the copyright declarations in the
directory src/mips/openbios where the PCSX-Redux BIOS
is, gleaning all the copyright years: 2019-2024 at this
time.
The years will be updated as and when PCSX-Redux is
updated in lbmk. Their BIOS is under MIT so I made lbmk
generate an appropriate COPYING file alongside the binary,
containing:
Copyright (c) 2019-2024 PCSX-Redux authors
Along with the actual text of the MIT license. With all
of this, the PCSX-Redux BIOS can now be included in
Libreboot releases.
No actual tarball is created. The release script in lbmk
simply copies the bin/ directory to ../roms
I'm leaving the PCSX-Redux BIOS release uncompressed,
because, and this will sound patronising because that is
my precise intention: Windows users don't know how to do
anything. If I provide a tarball to Windows users, they
won't know what to do. Libreboot releases always go on rsync
mirrors, which also have HTTP servers with indexing enabled,
for browsing release files.
I mention Windows users, because most people who use the PCSX
Redux BIOS will probably use it on a PlayStation emulator, and
most emulator users are on Windows. I can't really be bothered
to provide it as a .zip archive, and it's only 512kb, so just
provide it uncompressed in Libreboot releases!
Releases were already possible under this scheme, so this
patch really just adds the COPYING file. It's simply a courtesy
to the PCSX-Redux developers, providing proper credit to them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
on 3050micro, we disable seabios as a primary payload,
making grub a pribary payload instead.
the way it worked, the roms were still named seagrub
and the seabios rom would be compiled, but with the wrong
path, so seabios wouldn't be executed; seabios would hang
anyway, on this board.
instead, engineer it in such a way as to disable seabios_
images on this board. also, rename seagrub_ to grub_.
i normally only permit seagrub, and not grub, but i make an
exception for 3050micro because we know grub works, but seabios
currently hangs on this board (which means no bsd).
Signed-off-by: Leah Rowe <leah@libreboot.org>
SeaBIOS is known to hang on this board. It is being investigated.
Add two variable options for target.cfg files:
* seabiosname
* grubname
This string defines where it would be located in CBFS.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in some cases, on a fresh clone, the cached repo already
exists but lbmk tries to download it again. work around
this by checking that the directory exists; it's in the
main if statement, so that the "else" still applies. as
a result, the fallback to a live repo would un-fall back
to doing git-pull if the cached directory exists exists.
if it doesn't seem to make sense, it's because it doesn't.
this whole function needs to be rewritten better.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is using Mate Kukri's port, which was added in
previous lbmk revisions. I've added an IFD that sets
the HAP bit, and unlocks regions as standard.
vcfg is set to 3050micro, which defines downloading
of the MEv11 image and it will run deguard automatically.
I made a small adjustment to vendor.sh, because the hotpatch
logic for deguard uses -C in git, and when doing that, the
specified directory path is relative to that Git repository;
the .patch path has been adjusted accordingly.
Also add 3rdparty/fsp to coreboot/default modules.
This board requires the ifdtool option: -p sklkbl
The -p option tells flashrom what quirks are present in a
given IFD. We don't normally need this on other Libreboot
targets that we currently support. The -p option was needed
for creating this modified IFD, and it is therefore needed in
the inject script. Therefore, an "IFD_platform" option is
specified in a given board's target.cfg file. If this is set,
another variable is set that makes -p be used.
In this case, 3050's target.cfg says:
IFD_platform="sklkbl"
This option enables quirks for skylake/kabylake descriptors,
as required when using ifdtool.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I also added a "cleanargs" argument, similar to the makeargs
argument, to work around a build error.
This builds the PCSX-Redux PS1 BIOS. They reverse engineered
the Sony PS1 BIOS and wrote a free one under MIT license.
Run this:
./mk -b pcsx-redux
The file will appear: bin/playstation/openbios.bin
Signed-off-by: Leah Rowe <leah@libreboot.org>
Copy the downloaded deguard source code into appdir,
and patch it to run as part of lbmk, instead of
standalone. The archived one in src/ is not directly
used; instead, the hotpatched version is used.
This is because the standalone version already has
download logic for the .zip file, but we already
cache that file in cache/ and use that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the output isn't really super critical, because it pertains
to files that would just result in a coreboot build error
if they didn't extract, which would still allow me to know
if a given extract function failed.
however, the extract function shows a lot of error output
because it literally bruteforces various extract methods,
when dealing with vendor files.
mitigate this by just printing the errors to /dev/null. this
will prevent users from erroneously thinking that lbmk is
operating under error condition, when it isn't. we do sometimes
get questions about it on irc.
fewer questions on irc is better.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe