17 commits above 2.12-rc1, with some fixes.
i'm about to merge luks2 argon2 patches in a
follow-up commit, and they're based upon this
revision of grub
Signed-off-by: Leah Rowe <leah@libreboot.org>
./update seabios configs? gone
.modify coreboot configs? gone
it's now all 1 script, called e.g.
./modify defconfig options -u coreboot <-- runs make oldconfig
./modify defconfig options -m seabios <-- runs make menuconfig
./modify defconfig options -u u-boot gru_bob <-- oldconfig, and only gru_bob
./modify defconfig options -u coreboot x60 x200_8mb
etc. you get the idea. same behaviour as before with all
the separate scripts, but now its one unified script.
184 sloc reduction in resources/scripts/
Signed-off-by: Leah Rowe <leah@libreboot.org>
x86 u-boot is a bit flaky and this board never builds.
re-add it ot a later date.
u-boot is only really used in arm machines,
for our purposes at least.
Signed-off-by: Leah Rowe <leah@libreboot.org>
See file:
resources/scripts/build/defconfig/for
It is based on:
resources/scripts/build/payload/u-boot
The u-boot payload script has been deleted, as has the
seabios payload script; the build/boot/roms logic has
been heavily simplified too, by removing the logic for
building of elf files based on defconfig.
SeaBIOS, U-Boot and coreboot all use defconfig-type
infrastructure for their build systems, and they are
fundamentally the *same* in how to compile each codebase,
at least in an lbmk context, regardless of actual (and
very huge) differences in these codebases.
Several hundred sources-lines of code have been eliminated
by this change, drastically simplifying everything; U-Boot
payload compiling also now errors out when a single build
fails, instead of continuing. Also: build/boot/roms no longer
re-compiles a coreboot target that was already compiled,
which is the same behaviour observed for payloads.
(this means you must now manually delete a target, when you
wish to re-build it; the build/boot/roms logic now more or
less just runs cbfstool; blobutil is handled from
build/defconfig/for)
ALSO: Since crossgcc is now handled by build/defconfig/for, not
build/boot/roms, standalone compiling of u-boot is now possible.
This has been tested. You compile it like so:
./build defconfig for u-boot
or specific trees, e.g.
./build defconfig for u-boot default
One other consequence of this patch is that re-building the same
ROM image is now much faster, because the same builds are re-used
unless deleted. This could be useful when testing grub.cfg changes,
for example, if that's all you change. With things like ccache used
(not yet used robustly in lbmk), this could speed things up more,
depending on the codebase.
This patch demonstrates the raw power of lbmk; it is a very
simple and highly efficient build system, and now much more so!
Signed-off-by: Leah Rowe <leah@libreboot.org>
With newer hostcc, trying to build GCC 8.3.0 will raise an error from ld:
undefined reference to `__gnat_begin_handler_v1'
This commit adds a patch for GCC found on coreboot [1] correcting this
error by backporting the GNAT exception handler v1 to GCC 8.3.0 allowing
GNAT to be built with newer hostcc like GCC 10+.
[1]https://review.coreboot.org/c/coreboot/+/42158
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
it's bloat, and was only there for backwards compatibility
with the old commands, but the new commands are e.g.
./update blobs inject
instead of:
./blobutil inject
this results in a slight code size reduction in lbmk
Signed-off-by: Leah Rowe <leah@libreboot.org>
most of them were just calling the gitclone script,
so remove them.
the grub script was treating gnulib as a dependency.
i've now added the ability to grab 1 dependency, in
the gitclone script (it should be expanded later to
support multiple dependencies)
the gitclone script has been renamed to "fetch".
the "fetch_trees" script does more or less the same
thing, but calls "fetch" and handles multiple revisions
if a project needs that
this is more efficient, and slightly reduces the code
size of lbmk!
Signed-off-by: Leah Rowe <leah@libreboot.org>
make it output messages that tell the user important
information. it's only subtle but it makes a difference
to some people, who need confirmation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
they are fundamentally the same, in an lbmk context.
they are downloaded in the same way, and compiled in
the same way!
(Kconfig infrastructure, board-specific code, the way
submodules are used in git, etc)
~200 sloc reduction in resources/scripts
the audit begins
Signed-off-by: Leah Rowe <leah@libreboot.org>
Very nice ivybridge board that supports ECC RAM.
NOTE: I couldn't get onboard graphics working yet, but
this was confirmed working with a graphics card (in my
case nvidia quadra k420) booted in text mode on the SeaBIOS
payload. The GRUB payload also works, when loaded from SeaBIOS.
Therefore, this is a SeaBIOS-only board (as far as first payload
is concerned), but you can pick GRUB from the menu.
You could make it "GRUB-only" in practise by setting SeaBIOS
boot order to only load GRUB, and disable the SeaBIOS menu.
We refer to this as "SeaGRUB".
I've made lbmk use biosutilities and uefiextract, to
get at the SMSC SCH5545 Environmental Control (EC) firmware.
This firmware is needed for fan control. This is automatically
downloaded and extracted, from Dell UEFI firmware updates.
As with other blobs such as Intel ME, this firmware is then
scrubbed by the release build scripts. The blobutil "inject"
script can be used to re-insert it.
Of note: there is no fixed offset, but no other blobs to
be inserted in CBFS either, so the offset when re-inserting
on release ROMs should still be the same, and thus the ROM
checksums should match, when running blobutil inject.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this revision:
1281e340ad1d90c0cc8e8d902bb34f1871eb48cf
from 30 May 2023
It contains a few nice fixs, including an integer
overflow fix, but not many changes have been made
to seabios since the last revision.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is specifically the following Git revision:
7a994c87f571ac99745645be0bdde9827297321a
from 10 July 2023
The keyboard fix for HP EliteBooks was merged upstream,
so lbmk no longer needs this patch; it comes with GRUB.
Signed-off-by: Leah Rowe <leah@libreboot.org>
coreboot revision:
d86260a134575b083f35103e1cd5c7c7ad883bce
from 2 August 2023
The patches were updated. HP 8300 USDT has now been merged upstream,
so that patch is no longer included in lbmk.
SD card fix for E6400 merged upstream, so now it's removed in lbmk.
The nvidia E6400 patch (devicetree.cb) has not yet merged upstream.
The ifdtool --nuke option has been rebased.
Patches as follow-ups to earlier patches removed; for example, patches
that set VRAM to 352MB on GM45 have been removed, and replaced with
patches that just set 256MB in the first place (this is more stable).
This was mostly a clean rebase, of all the patches. It went smooth.
I haven't updated cros/haswell yet; the 4.11_branch revision used
on fam15h will also remain, for now.
The coreboot configurations have been updated, for this new
revision of coreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
blobdir is incorrect, and it means that the directory
will appear under blobs/, in this case. this was an
oversight on my part.
this behaviour did not break anything in practise, but
this patch makes the behaviour more consistent with rules.
Signed-off-by: Leah Rowe <leah@libreboot.org>
At present, the logic only tries backup URLs when an
actual download fails (bad internet connection or the
server is down).
If the main download succeeds, but it has a bad checksum,
the backup download is not attempted.
Since wrongly hashed files are to be assumed useless, we
may aswell delete and try the next file. This will guard
against the possibility of a vendor changing their file,
without changing the file name (non-versioned files, for
example, may be subject to such changes).
Signed-off-by: Leah Rowe <leah@libreboot.org>
ME extraction didn't support unar (RAR format), for regular
extraction, after downloading a vendor file.
For bruteforce ME extraction, after extracting a vendor
archive, unar(RAR) and inno(innoextract) was not supported.
This patch fixes both issues. It should be noted that as of
now, the unar method has only been tested with certain HP
vendor updates, and it's currently not used on any of those.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Immediately after the last revision, which was a hacky
workaround to the problem, I realised the actual problem,
and the real solution:
In the switch block, check *backup* first. Then it breaks,
continuing on the iteration.
If it's variable for a main URL, it'll reliably go to the
next check in the block, whereas if it's backup, it'll
default to the first one in each case.
This bug has been annoying the sh*t out of me for ages,
and I've finally nailed it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The script was actually downloading the backup, at
all times, for each given URL. The way we handle
this is quite buggy.
This patch is a workaround, a dirty hack in fact, but
it will do for now, because our backup URLs are always
wayback links where the original URL (matching the
correct main URL in the sources file) is always present,
in the URL.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Make it look like a normal web browser, downloading files.
Some HTTP servers might block Wget unless this is done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This was an oversight on my part.
Should extraction fail, we must abort. This is in preparation
for addition of future mainboards, where further tweaking is
required in blobutil. This error check will warn us about it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 7c90a4077f.
causes another build bug. i'm helping someone with the bug now,
i think the workaround for now would be to just use bash, on
this script. until i can figure something better out.
they were outside the scope, outside of the if statements.
in some shells, this is ok.
we use "sh" so the user could have any shell.
be a bit nicer to the more asininely technically
correct sh implementations out there
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was taken from old libreboot. the last libreboot
revisions that had these boards were under the old
policy.
i left microcode disabled at first, because the old
coreboot 4.11 behaviour was to always insert microcode
regardless, so old libreboot patched out microcode
from the coreboot build system
however, 4.11_branch appears to actually honour microcode
configuration, so i do actually need to make sure it's
enabled in configs
Signed-off-by: Leah Rowe <leah@libreboot.org>
the upstream link died. this patch makes it grab the
acpica tarball (for iasl) via libreboot rsync, where
i've added the corresponding tarball
Signed-off-by: Leah Rowe <leah@libreboot.org>
Libreboot 20220710 was the last release to support these
boards. I plan to eventually port code differences between
D8/D16 to Dasharo, for KCMA-D8 support in Dasharo, to then
use in Libreboot for both KCMA-D8 and KGPE-D16, but I have
no plans to update the KFSN4-DRE code, at least for now.
Libreboot 20220710 used coreboot 4.11, whereas this patch
makes use of coreboot 4.11_branch; the crossgcc toolchains
no longer compile on modern distros, so I spent time patching
those (tested in Debian Sid, will also work on Arch Linux and
so on).
The acpica downloads now fail, in 4.11_branch, because Intel
made some changes upstream for these tarball downloads. Newer
coreboot works around this by grabbing tarballs from github,
itself a non-ideal solution, but I digress; this patch changes
coreboot crossgcc (in 4.11_branch) to download the acpica
tarball from libreboot rsync, where I've added it.
This patch also re-introduces the PIKE2008 fix, where empty
option ROMs for these are inserted into CBFS. This prevents
SeaBIOS from loading the real option ROMs, which would cause
SeaBIOS to hang. This means that SAS drives are not supported
in SeaBIOS, for these boards in Libreboot.
I previously said, in the Censored Libreboot c20230710
announcement, that I would *only* merge D8/D16 when I've
added Dasharo support to Libreboot, and use that, but the
work to make coreboot 4.11_branch compile is something I'm
quite proud of and I see no reason to exclude from lbmk
master branch.
Honestly, there's not much different than 4.11, code-wise.
I *probably* won't use 4.11_branch for the next Libreboot
release, on D8/D16. By then, I might have Dasharo integrated
in lbmk instead. We shall see.
Signed-off-by: Leah Rowe <leah@libreboot.org>
upstream died. i put the corresponding tarball on
libreboot rsync. this is used by the coreboot build
system, specifically in crossgcc (cross compilers)
Signed-off-by: Leah Rowe <leah@libreboot.org>
This error was observed, in the coreboot build system:
In file included from src/lib/version.c:4:
build/build.h:10:32: error: 'libreboot' undeclared here (not in a function)
10 | #define COREBOOT_MAJOR_VERSION libreboot-20230625
| ^~~~~~~~~
src/lib/version.c:35:46: note: in expansion of macro 'COREBOOT_MAJOR_VERSION'
35 | const unsigned int coreboot_major_revision = COREBOOT_MAJOR_VERSION;
| ^~~~~~~~~~~~~~~~~~~~~~
This happened on the 20230625 *release archive*, when a user tried to
build for W541 MRC on an Arch Linux container.
This change fixes the error. I never got the error on my end when
build testing the release archives, but this will prevent the error.
Fix it by only inserting libreboot version string YYYYMMDD representing
the Libreboot version. (libreboot uses ISO dates as version numbers)
Signed-off-by: Leah Rowe <leah@libreboot.org>
I keep getting random linker issues when running:
./build boot roms all
I think the issue lies somewhere in here, from when
I did that massive audit. So I'm undoing the audit
which mostly re-factored the code style here.
These changes are being backported:
f338697b build/boot/roms: Support removing microcode
941fbcb run coreboot utils from own directory
f256ce98 build/boot/roms: say board name on stderr
I removed this change:
6d6bd5ee (the script now uses dedicated utils directory)
additionally:
cbutils is built much earlier on in the script, first
thing after initialising variables
the other changes not backported are all code style
changes, and I believe these are responsible.
if no other fixes occur to this fire before the next
libreboot release, then my hunch was right.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 2099545078.
Wasn't this config's fault, the problem happens elsewhere too.
I'm going to revert build/boot/roms to an older version and backport
a few recent changes, to see if that fixes the problem. If it does,
then I know that the recent linker issues happen due to recent changes
in build/boot/roms
The linker errors typically appear in util/kconfig/ but can happen
elsewhere, seemingly random, which means I'm not handling distclean
properly. Something isn't getting cleaned properly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
That way, I can more easily debug build issues with
specific boards, e.g.
./build boot roms all 2>lbmk.err.log
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe