We haven't seen any build errors, but it seems flashprog
sets -Werror on CFLAGS. If you provide WARNERROR=no as
a make argument, it avoids -Werror entirely.
This is a preventative fix, for over-zealous compilers.
Signed-off-by: Leah Rowe <leah@libreboot.org>
In Debian dependencies files. These are available in
Debian Stable, but liblz4-tool is a transitional
package referring to lz4; liblz4-tool transition
package is unavailable in Debian sid, so remove it
from the dependencies files.
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>
This reverts commit 781320514623653077cda2d910b9baf150949bd1.
I'm doing changes for 20241206 rev8. It was a mistake to
remove these; they will be removed again, after rev8.
The documentation standardised on ./mk a while ago now, and
it's almost time to remove these commands. However, anyone
using the old commands ought to be able to, up to and including
any revision of the Libreboot 20241206 release.
It is my intention that these legacy commands finally be
removed for the next testing release, as part of a much wider
build system audit that I'm doing between now and then.
(Libreboot Build System Audit 7 is underway, and several of
these early audit7 changes are going on 20241206 rev8; after
that, I will create a branch named 20241206_branch off of rev8,
and anything in master from then on will contain much wilder
changes, with more conservative changes in 20241206_branch)
Signed-off-by: Leah Rowe <leah@libreboot.org>
Tested on Debian Sid, as of 30 December 2024, which uses
Swig 4.3.0. Context here:
commit a63456b9191fae2fe49f4b121e025792022e3950
Author: Markus Volk <f_l_k@t-online.de>
Date: Wed Oct 30 06:07:16 2024 +0100
scripts/dtc/pylibfdt/libfdt.i_shipped: Use SWIG_AppendOutput
This patch from U-Boot upstream has been backported to the
release revision used by Libreboot. Swig has, since 4.3.0,
changed the language-specific AppendOutput functions, but
the helper macro SWIG_AppendOutput is identical; therefore,
upstream switched to this function.
The benefit of this fix is that since the newly used macro
is also the same on older Swig versions, and behaves the same,
this shouldn't fix building on older Swig versions. For reference,
the initial Libreboot 20241206 release, and revisions of it before
revision 8, was built on Debian 12 which uses Swig 4.1.0.
The rev8 release will still be compiled on Debian 12, but with
this change, it should also compile on Debian Sid, and bleeding
edge distros like Arch Linux.
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
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>
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 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>
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>
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>
it's green there. different colour scheme apparently.
still works on x86. alper said his kevin chromebook was green!
was green on the libreboot one, which should be purple.
i don't know how can-u-boot green would show up. would be
funny if it turned out purple
Signed-off-by: Leah Rowe <leah@libreboot.org>
The bootflow menu is already the default boot command on x86. Switch
arm64 boards to that as well, so instead of booting the first thing we
find, we can easily choose what to boot.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Otherwise, you have to press enter to boot your distro.
With this, a timeout is created. After a number of seconds,
which can be reconfigured, the first option selected will be booted,
when generating a bootflow menu.
The timeout is disabled when you navigate the menu; it only
kicks in if you don't input anything on the keyboard.
More information about how this works is in the U-Boot patches,
within this patch. I've set the timeout to 8 seconds.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Otherwise, you have to press enter to boot, which is unacceptable
for headless operation.
Pressing anything other than enter an an option, such as the arrow
keys, will disable the timeout.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is used for factoryy bios dumps, in cases where
boards require extraction of ME and so on,
instead of downloading online.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We need to initialize the USB subsystem before we can use USB devices
like keyboards and external disks, by running `usb start`. Use the
PREBOOT config option to run the necessary command before U-Boot tries
to automatically boot anything. It's already enabled for boards other
than gru_kevin and gru_bob, so just update those two configs.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Set default U-Boot revision to v2024.10 and rebase patches on top of
that. The video subsystem now has switched to using the 'cyclic'
mechanism, so the code around one of the video patches changed a bit.
x86 boards were already switched to v2024.10. Update U-Boot for the
remaining ARM64 boards as usual:
- Turn old configs into defconfigs (./update trees -s u-boot)
- Save the diff from old upstream defconfig (diffconfig $theirs $ours)
- Update U-Boot revision, rebase patches, and clean old trees
- Prepare new U-Boot tree (./update trees -f u-boot)
- Review the diffconfigs to see if any options were renamed upstream
- Copy over the new upstream defconfigs and apply earlier diff
- Turn new defconfigs into configs (./update trees -l u-boot)
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Otherwise, if PATH was set before, it will be re-used
again in the next pass. We previously unset CROSS_COMPILE
to avoid using the wrong cross-compiler when switching to
another target within a multi-tree project such as U-Boot.
Well, PATH was also being set, to use coreboot xgcc first.
This is fine, but the next target may not use the same one.
This patch solves a similar problem to the following patch
which was mentioned above:
commit 637c0a1521a03e3f65de85dcc5ffd478b37a5360
Author: Leah Rowe <leah@libreboot.org>
Date: Tue Nov 19 02:52:28 2024 +0000
trees: unset CROSS_COMPILE per target
Signed-off-by: Leah Rowe <leah@libreboot.org>
It wasn't being included, because we remove these files
in Canoeboot's version of U-Boot.
However, rules for including them was still in the U-Boot
build logic, leading to build issues such as:
arch/x86/dts/.cherryhill.dtb.pre.tmp:206:10: fatal error: microcode/m01406c2220.dtsi: No such file or directory
206 | #include "microcode/m01406c2220.dtsi"
This happened when building x86 U-Boot payloads. This patch
fixes the issue.
Signed-off-by: Leah Rowe <info@minifree.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>
openssl-devel was split up in Fedora 41, and this package is required to build libreboot
on Fedora 41.
This was reported by "tweezers" on #libreboot.
Signed-off-by: Mate Kukri <km@mkukri.xyz>
Leah Rowe