GRUB has not pushed many patches to master since the recent 2.12
release, but there are a number of interesting fixes.
canoeboot is doing a release soon. bump to latest grub revision.
Some of the new patches in GRUB are interesting:
XFS fixes:
"fs/xfs: Handle non-continuous data blocks in directory extents"
68dd65cfdaad08b1f8ec01b84949b0bf88bc0d8c
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2254370
Apparently, XFS could not boot in some reports, though this was
likely with BIOS or UEFI GRUB; no such reports were made to canoeboot
"gfxmenu/view: Resolve false grub_errno disrupting boot process"
39c927df66c7ca62d97905d1385054ac9ce67209
"util/grub-fstest: Add a new command zfs-bootfs"
28c4405208cfb6e2cea737f6cbaf17e631bac6cd
The gnulib revision does not need to be updated at this time.
Signed-off-by: Leah Rowe <info@minifree.org>
cbmk sets TMPDIR to /tmp, and then creates a tmpdir, then
exports *that* as the value of TMPDIR. this unified TMPDIR
location then contains all subsequent files and directories,
when any script or program makes use of /tmp, via mktemp. at
least, that's the theory!
in practise, because it was only being properly exported from
the main build scripts, subscripts that are then called were
not exporting it, at least that is my assumption because in
some cases, i found that the coreboot build system was leaving
errant files behind outside of our own TMPDIR, and that build
system did not seem to be setting TMPDIR itself; more debugging
is needed.
anyway: use the exact same logic, but do it from err.sh. since
err.sh is included from every cbmk script, that means it will
always be exported when running every single part of cbmk. this
should reduce the chance that mktemp creates files and directories
outside of our custom TMPDIR location.
this is because in cbmk, we mitigate unhandled tmpdirs/files by
unifying it in the manner described, then deleting the entire
TMPDIR on exit from the main cbmk parent process (the main
script that the user called from, which is always the "build"
file).
in cbmk, effort is made to clean up temporary files properly,
without relying on this catch-all, but we can't rely on that.
the catch-all should also be as robust as possible.
Signed-off-by: Leah Rowe <info@minifree.org>
the temporary rom per build was not being deleted after
finishing the current target. this adds up in /tmp during
large builds, when building for many targets. fix this!
Signed-off-by: Leah Rowe <leah@libreboot.org>
release="n" can be set in target.cfg on coreboot targets
script/update/release exports CBMK_RELEASE="y"
script/build/roms skips building a given target if release="n"
in target.cfg *and* CBMK_RELEASE="y"
you could also do the export yourself before running ./build roms,
for example:
export CBMK_RELEASE="y"
./build roms all
this will be used in subsequent revisions, to exclude certain
targets from the next canoeboot release.
Signed-off-by: Leah Rowe <info@minifree.org>
see:
https://github.com/9elements/grub/commits/xhci-module-upstreaming-squash_v4/
grub only supports xhci on bios/uefi targets, but not coreboot.
some newer machines don't have ps/2 controllers, and boot in a
way where ehci isn't available at startup; the controller can't
be used by ehci code, there must be xhci support.
the code is from Patrick Rudolph working on behalf of 9elements.
the code was also sent here for review:
https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00111.html
however, upstream never merged these patches. canoeboot will have
to maintain these from now on. the patches have been rebased for
use with grub 2.12.
Signed-off-by: Leah Rowe <info@minifree.org>
cbmk otherwise uses nproc to set the number of build threads,
in these places:
* generic make commands in script/update/trees
* crossgcc make command in script/update/trees
the -T0 option is also used in script/update/release, when running
tar.
with this change, you can do:
export CBMK_THREADS=x
where x is the number of threads. when you then run
cbmk, your chosen number of threads will override
the default. this may be useful on a host that does
not have a lot of memory.
Signed-off-by: Leah Rowe <info@minifree.org>
in shell scripts, a function named the same as a program included in
the $PATH will override that program. for example, you could make a
function called ls() and this would override the standand "ls".
in cbmk, a part of it was first trying to run the "fail" command,
deferring to "err", because some scripts call fail() which does
some minor cleanup before calling err.
in most cases, fail() is not defined, and it's possible that the user
could have a program called "fail" in their $PATH, the behaviour of
which we could not determine, and it could have disastrous effects.
cbmk error handling has been re-engineered in such a way that the
err function is defined in a variable, which defaults to err_ which
calls err_, so defined under include/err.sh.
in functions that require cleanup prior to error handling, a fail()
function is still defined, and err is overridden, thus:
err="fail"
this change has made xx_() obsolete, so now only x_ is used. the x_
function is a wrapper that can be used to run a command and exit with
non-zero status (from cbmk) if the command fails. the xx_ command
did the same thing, but called fail() which would have called err();
now everything is $err
example:
rm -f "$filename" || err "could not delete file"
this would now be:
rm -f "$filename" || $err "could not delete file"
overriding of err= must be done *after* including err.sh. for
example:
err="fail"
. "include/err.sh"
^ this is wrong. instead, one must do:
. "include/err.sh"
err="fail"
this is because err is set as a global variable under err.sh
the new error handling is much cleaner, and safer. it also reduces
the chance of mistakes such as: calling err when you meant to
call fail. this is because the standard way is now to call $err,
so you set err="fail" at the top of the script and all is well.
Signed-off-by: Leah Rowe <info@minifree.org>
i do tend to waffle on a bit. canoeboot.org will probably see
a similar change applied to it.
the new readme more thoroughly explains everything, getting
straight to the point.
Signed-off-by: Leah Rowe <info@minifree.org>
this merges the fix from:
https://codeberg.org/libreboot/pico-serprog/pulls/1
however, PRs are not to be sent there. riku merged it in
his repository, and i pulled it in the mirror hosted
on libreboot codeberg
Signed-off-by: Leah Rowe <leah@libreboot.org>
Riku introduced three new patches:
* Add support for multiple chip selects. This allows you to
control multiple chips from the same clip, on systems with
dual flash setups, at least theoretically.
* Enable pull-up on unused chip selects - pull them high so
that chips you connect that to are deactivated while flashing
the target chip. This could be used on thinkpad W541 for
instance, where miso/mosi have 0ohm between them via the two
flash ICs. You could pull the other chip select high.
* Documentation for the above, in the pico-serprog readme.
This goes in tandem with a patch from Riku, present in the
recently integrated flashprog project, namely:
commit ddb6d926783d4f9cbee04c7392718ed8f89daa0e
Author: Riku Viitanen <riku.viitanen@protonmail.com>
Date: Mon Jan 15 19:15:49 2024 +0200
serprog: Add support for multiple SPI chip selects
This functionality will therefore be present in the next
release of Libreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Nico Huber is the rightful project lead. I do not support
the coup that occured within the flashrom project. Nico
has always been of great service to the Libreboot project,
by virtue of his work on both coreboot and flashrom.
Nico Huber was unfairly removed from the flashrom project
infrastructure, due to unfounded accusations hurled at him
by flashrom's new project lead. The accusations are unfounded
because no evidence was given.
Use Nico Huber's fork, named flashprog. We will work with
flashprog from now on.
Signed-off-by: Leah Rowe <leah@libreboot.org>
./update release -m u-boot
if someone just wants to make u-boot, they can
use this and it tars up all the trees.
Signed-off-by: Leah Rowe <info@minifree.org>
in some cases, the build system was needlessly, and sometimes
erroneously, creating crossgcc symlinks, which then caused an
issue, namely:
in lbmk release builds, dell e6400 is build before fam15h boards,
and it sets xtree, but fam15h_rdimm doesn't, and later this would
cause fam15h_rdimm boards to use xtree="default" (because they don't
set xtree), causing the newer toolchain to be used on coreboot 4.11.
this patch fixes the issue. quite a simple problem, actually.
Signed-off-by: Leah Rowe <leah@libreboot.org>
these should be using the rdimm tree for crossgcc,
so define it explicitly. the build system creates
a symlink too, but it's still best that we use it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the changelog file is only present in releases, so
use the presence of this file for the test.
someone who wants to fetch projects within a release
archive can simply use the git repo, or delete the file.
Signed-off-by: Leah Rowe <leah@libreboot.org>
use the git log, as follows:
git log --graph --pretty=format:'%Cred%h%Creset %s %Creset' --abbrev-commit
this creates a nice, uniform list of changes.
Signed-off-by: Leah Rowe <leah@libreboot.org>
a tree can specify:
tree_depend="treename"
this will make the other tree be downloaded. this is
used for coreboot trees, to ensure that dependency
trees are downloaded, because trees can now re-use
crossgcc from other trees.
Signed-off-by: Leah Rowe <leah@libreboot.org>
let them specific it, rather than falling back
to coreboot/default (can also be used for coreboot boards)
Signed-off-by: Leah Rowe <leah@libreboot.org>
merges commit:
* b71d4fd0 coreboot/fam15h: disable -Werror on binutils 2.32
work around newer build issues, on very bleeding edge distros
(disable treating warnings as errors)
Signed-off-by: Leah Rowe <info@minifree.org>
cherry-pick commit:
* 33e25a33 dependencies/arch: add pandoc to dependencies
pandoc is required by the grub build system, when
running autoconf at the start of the build process
Signed-off-by: Leah Rowe <leah@libreboot.org>
Signed-off-by: Leah Rowe <info@minifree.org>
There is no need to add multiple keymap files, because
GRUB can load keymaps from CBFS. The current build logic
is designed to avoid building multiple GRUB binaries,
which are expensive computationally because each one
would then have to be compressed for each board.
This patch provides the best of both worlds: less space
used in flash like in the old lbmk design (1 keymap per
board), but retaining the current build speeds and therefore
not re-introducing the slowness of lbmk's previous GRUB
build logic.
The grub.cfg file has been modified, accordingly. It now
only loads a keymap.gkb file from CBFS, by default. It does
this, only if that file exists; if not, GRUB already defaults
to US Qwerty layout anyway.
ALSO: compress all keymap gkb files with xz -6
GRUB automatically decompresses files when accessed.
This results in about 2KB of flash space saved in CBFS.
Here is real-world data, showing the increased flash space:
< fallback/payload 0x3eb80 simple elf 548821 none
< keymap.cfg 0xc4bc0 raw 16 none
< (empty) 0xc4c00 null 11633316 none
---
> fallback/payload 0x3eb80 simple elf 546787 none
> keymap.gkb 0xc43c0 raw 344 none
> (empty) 0xc4540 null 11635044 none
This was taken by diffing the cbfstool "print" output,
both before and after. The *after* result is with this change.
11633316. In this example, 1728 bytes have been saved. Therefore,
with compression taken into account, this patch saves about 1.7KB
of space in CBFS.
This change means that lbmk can now scale to support hundreds
of keymaps, without increasing the amount of flash space used,
in each given image. Since the keymap files are compressed in
lbmk.git, in advance, we spend no additional time on compression
at build time. The resulting change in build speed in negligible.
Adding your own keymap.gkb file was already possible, for changing
the keymap in libreboot images, if you didn't want to change the
memdisk (and thus re-compile grub.elf). Now, this is the default
behaviour, and the only way to do it. It's much more efficient.
The original keymap files can be restored, by running unxz.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the "kmapdir" variable was removed in an earlier audit,
but was overlooked for -k because that option was untested.
rather than initialise the variable, re-use grubcfgsdir.
this fix enables e.g. "-k usdvorak" to work again.
Signed-off-by: Leah Rowe <leah@libreboot.org>
In order for the EC to maintain the state of whether or not to set the
flash descriptor override across a power cycle, the AC adapter must be
connected, as the system leaves the voltage rail that the EC uses
powered under this condition. Without this, the utility may fail,
continually asking the user to power off and on.
On Linux, CONFIG_X86_IOPL_IOPERM must be set for the kernel, or else the
iopl call will error with "Function not implemented". Make a note of
this in case a user runs into this issue.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
cbmk 9429287 is the present canoeboot revision, on this day,
two commits after canoeboot 20231107
the cbmk revision was based on lbmk c4d90087, but lbmk
has developed a lot since, right up to f5b04fa5. lbmk
c4d90087 was four commits after libreboot 20231106
this patch brings cbmk up to date, versus lbmk f5b04fa5,
which is 135 commits after libreboot 20231106 (not 4)
therefore, the next canoeboot release shall import lbmk
changes made *after* lbmk revision f5b04fa5. good day!
In English (the above is for my reference, next time
I make a new canoeboot release):
This imports all of the numerous improvements from
Libreboot, sans the non-FSDG-compliant changes. You
can find a full list of such changes in the audit4 page:
https://libreboot.org/news/audit4.html
A full canoeboot-ised changelog will be available in
the next canoeboot release, with these and subsequent
changes. Most notable here is the update to the new
GRUB 2.12 release (instead of 2.12-rc1), and the
improvements Riku made to pico-serprog. And the build
system improvements from lbmk, such as improved, more
generic cmake and autoconf handling.
Canoeboot-specific changes: I also tweaked the deblob
logic, to make it less error-prone. The new design
changes imported into cbmk (based on latest lbmk) somewhat
broke the deblob logic; it was constantly reminding the
user that blobs.list was missing for coreboot,
at config/coreboot/blobs.list - coreboot is a multi-tree
project in both cbmk and lbmk, and the deblob logic was
tuned for single/multi, but was treating coreboot as both.
for simplicity, i removed the check for whether blobs.list
is present. this means that the operator must ensure that
these files are present, in any given revision, where they
are required on a given set of projects (and the files are
all present, in this update to cbmk)
Also of note: the grub.cfg improvements are included in this
cbmk update. The improved grub.cfg can find grub/syslinux
configs by default, not just grub anymore, also finds extlinux,
and will also find them on EFI System Partition - in addition,
UEFI-based install media is also more robust; although cbmk
doesn't provide UEFI configurations on x86, our GRUB palyoad
does still need to work with distro install media, and many
of them now use UEFI-based GRUB configurations in their
installation media, which just happen to work with our GRUB
Signed-off-by: Leah Rowe <leah@libreboot.org>
we skip downloading blob repositories, and we delete errant
blobs in lbmk. the CONFIG_USE_BLOBS option, if enabled, can
make the coreboot build system download certain binary blobs,
which we are to avoid in the canoeboot project.
in practise, canoeboot releases are already deblobbed. this change
just makes it less likely that there will be rgressions in future.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in the fam15h coreboot trees, this file was still present:
src/vendorcode/amd/agesa/f12/Proc/GNB/Nb/Family/LN/F12NbSmuFirmware.h
this was reported by Denis Carikli. the release errata will
be updated, accordingly, and this file will be absent in
the next canoeboot release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe