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>
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)
the loop in main() already checks EOF, and errno is
properly handled at the end of main()
we only need to call ferror(), to check error state
this fixes a bogus error message when pressing ctrl+D
to terminate the program, *which is the intended way
to terminate this program* (that, or EOF is reached
in any other another way)
do not treat intended behaviour as an error condition!
Signed-off-by: Leah Rowe <leah@libreboot.org>
i've build-tested this code with clang and that also
works. in practise, a user is going to have clang or gcc
Signed-off-by: Leah Rowe <leah@libreboot.org>
make it more obvious that this *is* a ring buffer being
handled, and make it more obvious when checking a pulse
in the next frame
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe