the upstream died, for links used by coreboot 4.11_branch
when downloading acpica (to run iasl).
other coreboot trees don't need this fix, because coreboot
upstream already fixed it. we only need to patch this
older coreboot revision. this fixes building for:
KFSN4-DRE, KGPE-D16 and KCMA-D8 boards
the c20230710 release itself did not include this fix,
but releases already include the tarballs and so the
broken acpica link does not matter (because it's included,
and the coreboot build system will skip downloading it
as a result)
Signed-off-by: Leah Rowe <leah@libreboot.org>
The configs were made for 4.11, and several new changes
were required for 4.11_branch. Without these changes, the
builds are not automated because coreboot's build system
asks for user input on certain configuration.
This patch makes everything smooth as silk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Changes made to acpica/iasl in crossgcc, for
coreboot trees fam15h_udimm and fam15h_rdimm:
remove superfluous YYSTYPE declaration
make LuxBuffer variables static, to avoid warnings
treated as errors about multiple definitions
AcpiGbl_DbOpt_NoRegionSupport - remove this definition
in source/tools/acpiexec/aemain.c because it's already
re-defined by acpiexec. otherwise the linker complains
about multiple definitions
Signed-off-by: Leah Rowe <leah@libreboot.org>
do this with board.cfg option:
crossgcc_ada="n"
add this environmental variable when building
crossgcc, if crossgcc_ada="n":
BUILD_LANGUAGES=c
This avoids building the GNAT/Ada compiler in GCC.
Coreboot 4.11 is only used for some AGESA boards
that don't need Ada (their video init is the old
style, written in C, it's not libgfxinit)
Signed-off-by: Leah Rowe <leah@libreboot.org>
tested on debian sid, as of 9 july 2023
implicit string declaration
easy stuff. now binutils 2.32 compiles. coreboot 4.11
uses this older binutils version.
Signed-off-by: Leah Rowe <leah@libreboot.org>
lbmk uses distclean on cbfstool, which newer cbfstool
supports, but this old version (in coreboot 4.11) does
not. fix that.
it just runs make-clean
Signed-off-by: Leah Rowe <leah@libreboot.org>
c-libreboot, and GNU Boot, is a 180 U-turn versus
current libreboot policy, as seen here:
https://libreboot.org/news/policy.html
Therefore, rotate the bootsplash pic 180 degrees, for
comical effect.
Signed-off-by: Leah Rowe <leah@libreboot.org>
also kfsn4-dre
this is still based on the old coreboot 4.11 version.
i have on todo to adapt dasharo coreboot for use in the master
branch of lbmk, for mainline libreboot releases.
since i'm doing c-libreboot for the GNU project, namely GNU Boot,
and since GNU Boot has dre/d8/d16 in their tree, re-add it here
for them.
i literally just copied this from them, who in turn copied it from
libreboot in an older revision anyway.
but there is one fix:
src/vendorcode/cavium/bdk/libbdk-hal/if/bdk-if-phy-vetesse.c
^ this blob wasn't being deleted by gnuboot, nor by libreboot
in the older revision that it forked from. an oversight. i decided
to audit the deblobbing and found this one was overlooked, out of
about 900 files picked up by deblob-check.
so this re-addition of dre/d8/d16 support is actually even better
deblobbed than gnuboot, or old-libreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
see:
https://en.wikipedia.org/wiki/Book_burning
i'll actually update blobs.list for each coreboot rev
in a subsequent commit. this logic was taken from an
old libreboot revision, which uses different coreboot
revisions. as i write this, i'm running deblob-check
from linux-libre deblob scripts.
my process is: i just check each file and decide whether
it's a blob, or like, test data. in some cases it flags
other false positives, like... a C source file that has
a bunch of magic numbers in it for things (not a blob)
Signed-off-by: Leah Rowe <leah@libreboot.org>
delete all blobs. TODO: actually deblob coreboot/uboot
when downloading. i'll that in a little while, in an
upcoming commit.
yes.
purge it all, in fsf style. censor what the fsf doesn't like.
so that they can feel good about having less, because
ideological purity is better than helping more people
use coreboot, yes?
Signed-off-by: Leah Rowe <leah@libreboot.org>
because that's what fsdg policy is: censorship
fsf will censor any existence of less-than-pure hardware
from coreboot, despite the fact that coreboot provides
more freedom for the user than fully proprietary firmware,
even in cases where blobs are needed. i criticise that here:
https://libreboot.org/news/policy.html
FSF's fork of libreboot, formerly libreboot.at and now
named GNU Boot*, is still based on old lbmk from october
2022, they haven't written *any* code since December 2022
when they supposedly first started working on the fork
i'm doing a gnuboot for them, purely for fun, called
c-libreboot. c-libreboot is essentially the same as old
libreboot, prior to the osboot merge, but i'm including
all the new things such as dell latitude e6400 or gru
chromebooks, all of which are suitable under the old
libreboot policy and, by extension, GNU Boot policy
*URL: https://savannah.gnu.org/projects/gnuboot/
(it actually is a GNU project, though the FSF has
not yet announced it officially, as I write this)
Signed-off-by: Leah Rowe <leah@libreboot.org>
this way, default psdg libreboot roms that enable microcode
can be used in fsdg libreboot, unmodified.
these configs enable microcode, but this change to the
coreboot build system avoids adding them regardless of
configuration
this saves hours of work that would otherwise be required,
to reconfigure all of the coreboot images, and will allow
gnuboot to use the same configs as libreboot
fsf makes such a fuss over this, when it's really quite
simple.
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>
I don't know why, but removing this BL31 make argument lets gru-kevin
power off properly when shut down from Linux. Needs investigation.
Do it as a cros-only HACK patch so people don't have to hold the power
button after every shutdown.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Debian's signed shim allocates too many EFI variables to fit in the EFI
variable memory buffer. Normally it would then try to continue booting
in non-secure-boot mode, but its error handling throws a synchronous
abort that reboots the board, making it impossible to boot into Debian
unless one manually loads GRUB instead of shim. Increase EFI variable
buffer size to avoid triggering the bug.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
turns out it's just picky ram.
errant reports of "no boot" (users did not have debug
dongles) were likely "bad" ram
notes will be written on libreboot.org about this
Signed-off-by: Leah Rowe <leah@libreboot.org>
not well-tested, and existing testing has revealed video
issues on some of them (or just no boot)
for now, retain only qemu and gru-* on arm
Signed-off-by: Leah Rowe <leah@libreboot.org>
fixes ./build boot roms all
in detect_firmware(), "set" is used to get values from
configs, to know if things like ME/MRC are needed
on some "board" configs under resources/coreboot/, no
actual coreboot configs are provided, because they are
used as a reference (coreboot revision, tree name etc)
for actual boards, with actual coreboot configs
when attempting to build for such a board, running "set"
on such non-existent files would cause a non-zero exit,
when we want zero. the non-zero exit then caused the
build/boot/roms command to fail, when running "all" if
it found, for example, resources/coreboot/cros/ which
has the above problem, in this context
work around it by verifying that coreboot configs exist
for the given target name, in the blobutil download script.
if no such configs exist, then exit zero (success)
doing so is correct, because the script is intended to
do just that, erroring only if it is detected that blobs
are needed for a given board, but other errors occur; if
no coreboot configs exist, then no roms will be built and,
therefore, no blobs are needed
Signed-off-by: Leah Rowe <leah@libreboot.org>
script is -e anyway, so this is redundant, but best
put it here anyway. it can only help. correct behaviour
is always to fail on error, except in certain cases that
would be handled on a case-by-case basis in each script
Leah Rowe