In general, we don't want to mess with the hostcc, unless
we have to. To avoid other breakage, clear what we did
after crossgcc has compiled.
This is a follow-up to the previous patches, matching gcc
to gnat versions and vice versa, when compiling crossgcc.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i intend for this function to work generically,
matching gnat to gcc or gcc to gnat, but there was
a hangover from the previous code where it specifically
assumed we were matching gnat
this bug manifested when i tested with gnat being v13
and gcc being v14 in path, where gcc-13 was also
available in path.
Signed-off-by: Leah Rowe <leah@libreboot.org>
on debian trixie/sid after updating from stable,
sometimes gcc 13 and gnat 13 are both available, but
gcc resolves to gcc-14 and gnat-14 isn't available.
even when gnat-14 and gcc-14 are available, gnat will
still either resolve to gnat-13, or nothing at all.
in cases where gnat-14 is unavailable, but gcc and gnat 13
are both available, we should match gcc to gnat.
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>
We were checking the shorthand version number, but
the precise version numbers need to match.
Also: when we searched $PATH/gnat-$gccver, we assumed
that the full version would then match, without checking
it, so now it is checked precisely.
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>
because if it says yes to everything, and the package
manager would otherwise ask whether you want to give
it your first born son, you are therefore agreeing to it.
so remove -y for safety
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>
Hyperthreading is a risk factor for spectre/meltdown
and other attacks.
Disabling it is a best practise. Those who need it
can always turn this option back on. Otherwise, disabling
it by default is a simply courtesy to the average user,
in the interest of security.
Signed-off-by: Leah Rowe <leah@libreboot.org>
SeaBIOS was lagging a lot, on startup and when executing
almost any payload, especially when doing anything in the
ESC menu.
I set the debug level to *21*, and thoroughly analysed the
logs. I found entries such as this:
Checking for bootsplash
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_StirRandom = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_GetRandom = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_HierarchyChangeAuth = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc16e
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc1c5
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc211
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc25d
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc2a9
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc2f5
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc341
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc38d
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc3d9
Searching bootorder for: HALT
Mapping hd drive 0x000f49e0 to 0
I'm not quite certain what the problem is, but disabling TPM2
made the problem go away; SeaBIOS is snappy again.
TPM is security threatre anyway.
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>
this brings support for a new microcontroller platform rp2530.
total number of pico boards supported now: 97
TEST: built them all
Tested-by: Riku Viitanen <riku.viitanen@protonmail.com>
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
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>
change python3-distutils to python3-distutils-extra
the latter is still available in debian sid, but not
the former. however, installing this should still
provide the additional files required.
with this, the debian script is now compatible with
both debian sid and debian stable(bookworm, presently).
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
We only use ./mk now.
./build still exists for now. This will be removed
in a future revision, when the trees script is removed
and merged with the main script.
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 appdir.patch file was used on the older deguard
version, prior to Mate Kukri's rewrite. This patch is
no longer required, and no longer used, so it can be
removed safely from lbmk.
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>
libreboot has a lot of users worldwide, some of whom live in
countries that punish being gay; if they look at libreboot or
boot it and it has the pride colours on it, it could actually
get them in trouble.
this fact occured to me, and i've decided therefore to revert
back to the boring plain logo.
though, perhaps we could actually properly design a new logo?
a new, modern logo, and a nicer website.
we'll see!
This reverts commit 401efb24b2.
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>
see patch for rationale. this should prevent instability caused
when the nvme randomly replugs under linux. sometimes e.g. nvme0n1
becomes nvme0n2 while the system is running.
in my case, that caused my raid1 to become unsynced every few days.
this issue was fixed on t480 by disabling pcie hotplug for its nvme
device, so the same fix has been applied for dell optiplex 3050 micro.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was done with the following command:
./mk -u coreboot t480s_fsp_16mb t480_fsp_16mb
it was set to 256 but should be 512. the SPD is what
contains configuration data for raminit, which training
code uses so that the timings will be correct. if the SPD
size is wrong, the machine won't boot
in practise, lbmk always runs "make oldconfig" on
a coreboot config, before building it, so this was
already being corrected automatically at build time.
however, if that fact ever changes in the future, this
wrong configuration would cause the machines not to boot.
therefore, this can be considered a preventative or perhaps
pre-emptive bug fix.
this fix does not need to be applied to the 20241206 release,
because of the behaviour described above. the final ROM images
do have the spd size set correctly to 512, because of this
design feature in lbmk.
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>
Leah Rowe