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
From now on, the following rules are available for all
mainboards, in resources/coreboot/boardname/board.cfg:
* blobs_required="n" or "y"
* microcode_required="n" or "y"
The blobs setting, if set to "n", simply renames filename.rom to
filename_noblobs.rom.
The microcode setting, if set to "n", copies the ROM (with or
without _noblobs) to filename_nomicrocode.rom (if blobs="n",
it would be filename_noblobs_nomicrocode.rom).
Where "nomicrocode" is set, ROMs with microcode will still be
provided by lbmk and in relesase, but ROMs will also be provided
alongside it that lacks any microcode updates.
If the *original* ROM already lacks microcode updates, then the
original ROM will be *renamed* to include "nomicrocode" in the name.
This is done on images for ARM platforms, for instance, where
microcode is never used whatsoever.
Example filenames now generated:
seabios_e6400_4mb_libgfxinit_corebootfb_noblobs_nomicrocode.rom
seabios_e6400_4mb_libgfxinit_corebootfb_noblobs.rom
seabios_withgrub_hp8300usdt_16mb_libgfxinit_corebootfb_colemak_nomicrocode.rom
seabios_withgrub_hp8300usdt_16mb_libgfxinit_corebootfb_colemak.rom
uboot_payload_gru_kevin_libgfxinit_corebootfb_noblobs_nomicrocode.rom
A vocal minority of people were not happy with some of the changes
made in Libreboot last year, including on existing supported
hardware from before those changes were made. I did this before the
last release, out of respect:
https://libreboot.org/news/gm45microcode.html
(re-add mitigations for no-microcode setup on GM45)
This new change is done as an further, extended courtesy. Tested
and works fine. (testing using cbfstool-print)
Actual Libreboot policy about binary blobs is nuanced. See:
https://libreboot.org/news/policy.html (reduction policy) and:
https://libreboot.org/freedom-status.html (implementation)
Well, the status page talks about descriptor vs non-descriptor
on Intel platforms, and where me_cleaner is used (on platforms
that need Intel ME firmware), it regards the descriptored setups
to be blob-free if coreboot does not require binary blobs.
In this paradigm, microcode updates are not considered to be
binary blobs, because they aren't technically software, they're
more like config files that just turn certain features on or off
within the CPU.
However, for lbmk purposes, "noblobs" means that, after the ROM
is fully ready to flash on the chip, there will be no blobs in
it (except microcode). So for example, an X200 that does not
require ME firmware is considered blob-free under this paradigm,
even though Libreboot policy regards X230 as equally libre when
me_cleaner is used; in this setup, ROMs will not contain "blobfree"
in the filename, for X230 (as one example).
Signed-off-by: Leah Rowe <leah@libreboot.org>
Since many boards use the same ME firmware, we could save
everyone's bandwidth and time by caching the update files.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Still on Gerrit. ME downloader failed with HP update file, so let's just
use Lenovo's instead. Both contain identical ME8_5M_Production.bin files.
Tested and working:
* Native raminit with both DIMMs
* Libgfxinit textmode and framebuffer on both DisplayPorts and VGA
* External USB2 and USB3 ports: they all work
* USB 3.0 SuperSpeed (rear, 4 ports)
* Ethernet
* Mini-PCIe WLAN
* SATA: 2.5" SSD and optical drive bay
* SeaBIOS and GRUB (boot to linux)
* PS/2 keyboard and mouse
* S3 suspend and resume, wake using USB keyboard
* Headphone output, line out, internal speaker
* Wake on LAN
* Rebooting
* CMOS options & nvramcui
Untested:
* Line in, mic input
* MXM graphics card
* EHCI debug
Not working:
* Mini-PCIe USB: I couldn't get it working on vendor BIOS either, so
maybe it just isn't present
* PS/2 keyboard wake from S3
* mSATA (I have no mSATA drives)
Tested with Johan Ehnberg (johan@molnix.com)
The following is tested and confirmed working:
- backlight control
- touchpad
- USB (external, smart card, fingerprint, bluetooth, webcam, WWAN)
- touchpad
- Wi-Fi
- 2,5" SATA
- USB 3.0
- SD card
- Memory: 2+2 (matched or unmatched), 8+2, 8+8
- internal flashing from libreboot
- SeaBIOS and GRUB payloads
- Boots Devuan and Ubuntu
Untested:
- ExpressCard
- DVD
- dock
- external displays
- eSATA
- trackpoint (not present on this aftermarket keyboard)
Leah Rowe