| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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 2099545078d5a5586743d32b2470a296b66cb5c7.
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>
|
|
This reverts commit 0f7a5386b9219111418a8de8637039c8533d99ea.
Random linker errors, must investigate after release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
don't clean it, distclean it
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
this means coreboot can now be distcleaned safely,
before and after each build of a rom image
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
this fixes blobutil not downloading me.bin for
the target, which was renamed to t440plibremrc
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/85
|
|
zopflipng is great!
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
|
|
alpernebbi/lbmk:uboot-efivar-size into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/83
|
|
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>
|
|
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>
|
|
will pass all args as a single arg, which is wrong
fix that
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Riku_V/lbmk:dl_cache into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/81
|
|
t440pmrc_12mb is the blob one.
t440p_12mb is the libre one, but this isn't clear.
rename accordingly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
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)
|
|
This reverts commit a4ea2867319471d9fe7d4ee540881e0286b4d3cf.
The licensing audit has been abandoned. I will not be re-licensing
in bulk to MIT.
I can still use MIT license on new works, e.g. utilities, but there's
really no pressing need to re-license lbmk. It's just shell scripts,
and most of what it interacts with (coreboot, grub, seabios) is GPL
anyway.
So who cares?
Ferass's patch was removed due to refusal to re-license, but the
decision to re-license has been canceled.
I'm now aiming for a quick stable release.
|
|
This fixes the PCI interrupt routing tables for the E6400 so that the SD
card works. It is already merged in upstream but libreboot has not yet
updated coreboot.
|
|
Riku_V/lbmk:hp8200sff_4mb into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/72
|
|
My patches are now merged in upstream so
just use that and drop the patch files.
|
|
This is useful for internally flashing Libreboot from OEM BIOS
since the top ~3MB is write-protected by vendor firmware.
|
|
make blobutil a symlink. Example of command changes:
./blobutil download x220_8mb
is now:
./update blobs download x220_8mb
The old command still works, for compatibility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
move resources/scripts/download/ to:
resources/scripts/update/module/
This: ./download coreboot
Is now: ./update module coreboot
However, running "./download coreboot"
still works, via backwards compatibility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
The primary purpose of my intense auditing has
been to improve lbmk's coding style and fix bugs
but there is a secondary purpose: know precisely
who owns what, because I want to re-license as
much as possible of lbmk under *MIT*, instead of
the current GNU licensing. MIT is vastly superior,
because it grants *actual* freedom to the user,
permits *sublicensing* and it is vastly more
compatible with other GPL combinations; for
example, MIT license is compatible with GPL2-only
whereas lbmk's current mix of GPLv3-or-later and
GPLv3-only is legally incompatible with GPLv2-only.
Re-licensing under MIT will most likely result in
more contributions to Libreboot's build system in
the future, especially as it will attract a lot
more commercial interest. Contrary to the popular
arguments, copyleft is a liability to the free
software movement and results in less code being
written; in practise, permissively licensed code
gets more public contributions, including from
commercial entities, even if companies can
theoretically make something proprietary out of
it (in practise, anyone inclined can just use the
upstream and proprietary forks almost always die).
Copyleft propaganda is fundamentally flawed. See:
<https://unixsheikh.com/articles/the-problems-with-the-gpl.html>
Anyway, I've been doing a combination of:
* Seeking permission from other copyright holders,
for re-licensing
* Deleting, or moving, other contributions; for
example, splitting certain contributions into
separate files so that originally modified files
become unencumbered. This latter solution is a
result of *code cleanup* arising from the audit.
For Ferass's contributions, I opted to seek
*permission*, and permission was denied. In full compliance
with this legal imperative, I'm acting accordingly; this
commit removes all of Ferass's changes that converted lbmk
to posix shell scripts, thus removing his copyright on the
affected files, bypassing his authority entirely. Therefore,
lbmk is largely now bash-dependent. In practise, nobody is
going to use anything other than a GNU system to build
Libreboot, because many projects that Libreboot makes use
of rely heavily on GNU; for example, coreboot's build
system makes heavy use of GNU-specific extensions in *GNU
Make*, and likely contains many bashisms. Of course,
Libreboot also compiles GNU GRUB.
I would much rather have MIT-licensed Bash scripts
than GPL-licensed posix SCL scripts.
This reverts the changes from Ferass El Hafidi,
for the following commits, with some exceptions:
* 7f5dfebf7d37c56d9c7993aaa17c59070cb5aec9
* f787044642236917c9c4dbcaa48a6b0648097db0
Exception:
download/mrc not reverted, because that was
already a fork of an existing script under
coreboot's build system, and their script was
GPLv2. i cannot/will not re-license this file
(ergo,
7f5dfebf7d37c56d9c7993aaa17c59070cb5aec9
change remains intact, on this file)
resources/scripts/build/boot/roms_helper, these changes
have been kept:
* 7e6691e9 - Add ARMv7 and AArch64 support
* dec2d720 - add myself in the build/roms_helper script
(added 2021 copyright for the change below)
* b7405656 - Workaround for grub's slow boot
^ these changes will be re-factored, splitting them
out of the file into a new file. This will be done in
a future lbmk revision. (in some cases, it makes sense
to keep a change but split it, allowing the main file to
be re-licensed without the change in it)
This is part of a much larger series of
licensing audits. It's likely that lbmk will
be posix-compliant (in its shell scripts)
again some day, because I'm planning to rewrite
most of these scripts (the ones modified in this
patch), and many of them (e.g. individual download
scripts) are subject to future deletion in a planned
overhaul of the download logic for third party
projects.
In addition: these changes are being kept (no attempt
to re-license them will be made):
* cff081c6 - Fix grub's slow boot (1 year, 5 months ago) <Vitali64>
* 4c851889 - Add macbook*1 16mb configs (1 year, 6 months ago) <Vitali64>
Ferass's work that remains will be split into dedicated
files containing them, where feasible.
In the case of grub.cfg (for GNU GRUB), I don't care
because it's a script for an engine (GRUB shell) that's
under GPL anyway, so who really cares about MIT license.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
|
