This version simply updates the revision, whereas
the corresponding lbmk patch was more invasive:
commit 9abddb82b9228be738382ddc178a9562926404b3
Author: Leah Rowe <leah@libreboot.org>
Date: Wed Nov 6 22:28:45 2024 +0000
Bump coreboot/next and merge coreboot/dell7
Canoeboot must be in sync with Libreboot at all times.
Well, the Libreboot patch also merges another tree
that Canoeboot doesn't have, containing the Dell OptiPlex
3050 Micro port, because Canoeboot can't support the
OptiPlek 3050 Micro.
So the Libreboot patch rebased many patches. This one
simply updates the revision.
Signed-off-by: Leah Rowe <leah@libreboot.org>
NOTE: Support added for xarch target x86_64-elf,
but U-Boot failed to build with this error:
OBJCOPY lib/efi_loader/helloworld.efi
x86_64-elf-objcopy: lib/efi_loader/helloworld_efi.so: invalid bfd target
make[2]: *** [scripts/Makefile.lib:476: lib/efi_loader/helloworld.efi] Error 1
Since I'm building U-Boot for x86_64 *on* an x86-64
host, and since that is currently the recommended type
of machine to use for cbmk development, and since the
other x86 payloads currently don't cross compile anyway,
this is an acceptable compromise for now. This is because
at present, I'm not making U-Boot the primary payload on x86,
instead preferring to chain it from GRUB and SeaBIOS.
The target.cfg file for x86 u-boot shows xarch/xtree commented.
Uncomment these to compile on crossgcc instead of hostcc.
I mention 64-bit because I initially did this first, but decided
to do 32-bit first. I'll work on the 64-bit one next (SPL).
It's only enabled in QEMU for now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
same revision, but re-do the patches again.
i wasn't quite as thorough with some of it yesterday.
for example, i included the ifdtool nuke patch yesterday,
which is not actually required in cbmk
Signed-off-by: Leah Rowe <info@minifree.org>
Since the E6400 was made into a variant for the E4300 dir,
the VBT file is now located in the e6400 variant directory,
instead of the main directory for the port, the latter of
which now accounts for both mainboards.
Signed-off-by: Leah Rowe <info@minifree.org>
This is based on the same change recently made in
lbmk. A lot of unnecessary patches, and I want to
clean them all up.
Also, cbmk's /default didn't actually build, whereas
lbmk did, which is the primary motive for this rebase.
With this change, it should build again.
Signed-off-by: Leah Rowe <info@minifree.org>
Thanks go to Nicholas Chin and Lorenzo Aloe for working on
and testing this code. Based on the 780 MT port.
Signed-off-by: Leah Rowe <leah@libreboot.org>
- Update the MEC5035 S3 patches to the versions that were sent upstream
to prevent conflicts with subsequent patches for that EC.
- Update the patch that enables the S3 SMI handler in mainboard code so
that all Latitudes use the handler.
- Add a new patch that tells the EC to route power button events to the
host so that the OS can decide what to do. Without it, the EC powers
off the system without letting the OS cleanly shut down.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Not needed in our use-case, and probably doesn't have any
source code. Accidentally missed during prior audits.
Signed-off-by: Leah Rowe <info@minifree.org>
people were raising a stink about futility test data
in GNU Boot recently, which is proprietary data that
they forgot to delete.
i was already deleting this data since october 2023,
when canoeboot pretty much first started, and they
recently started following suit in their project.
however, i was deleting specific files, found as a
result of intense auditing done in october 2023. to
be more cautious, this patch now simply deletes the
entire directory, so that no test data remains. this
ensures that any future additions upstream will not
be included inadvertently in releases.
not to gloat, but this was never an issue in canoeboot.
again to be clear, this is a preventative fix; titled
"irony prevention", because such a bug in a future
release would indeed be highly ironic.
irony is not allowed.
Signed-off-by: Leah Rowe <info@minifree.org>
Add patches to convert the E6400 port into a GM45 Latitude variant and
add the E4300 as another variant, and create a config for the E4300.
Tested on my E6400 and E4300.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
the coreboot413 tree is only needed for the cbfstool
revision that it has, and only on lbmk. i accidentally
added it, in the recent cbmk revision updates.
Signed-off-by: Leah Rowe <info@minifree.org>
same as the recent update in lbmk, but adapted for cbmk,
e.g. the patches to disable microcode blobs by default.
i copied it from the lbmk update but updated nuke.list
and excluded certain patches not needed in canoeboot, such
as the new dell latitude patches and haswell nri
The coreboot/dell tree was also merged to /default, just
like in lbmk. This puts Canoeboot completely in sync,
but with deblobbing as is customary for Canoeboot.
Signed-off-by: Leah Rowe <info@minifree.org>
Never, ever build images where GRUB is the primary payload.
These options have been removed from target.cfg handling:
* seabios_withgrub
* grub_withseabios
The "payload_grub" variable now does the same thing as
the old "seabios_withgrub" variable, if set.
The "grubonly" configuration is retained, and enabled by
default when SeaGRUB is enabled (non-grubonly also available).
Due to lbmk issue #216, it is no longer Libreboot policy to
make GRUB the primary payload on any board. GRUB's sheer size
and complexity, plus the large number of memory corruption issues
similar to it that *have* been fixed over the years, tells me
that GRUB is a liability when it is the primary payload.
SeaBIOS is a much safer payload to run as primary, on x86, due
to its smaller size and much more conservative development; it
is simply far less likely to break.
If GRUB breaks in the future, the user's machine is not
bricked. This is because SeaBIOS is the default payload.
Since I no longer wish to ever provide GRUB as a primary
payload, supporting it in lbmk adds needless bloat that
will later probably break anyway due to lack of testing,
so let's just assume SeaGRUB in all cases where the user
wants to use a GRUB payload.
You can mitigate potential security issues with SeaBIOS
by disabling option ROM execution, which can be done at
runtime by inserting integers into CBFS. The SeaBIOS
documentation says how to do this.
Libreboot's GRUB hardening guide still says how to add
a bootorder file in CBFS, making SeaBIOS only load GRUB
from CBFS, and nothing else. This, combined with the
disablement of option ROM execution (if using Intel
graphics), pretty much provides the same security benefits
as GRUB-as-primary, for example when setting a GRUB password
and GPG checks, with encrypted /boot as in the hardening guide.
Signed-off-by: Leah Rowe <leah@libreboot.org>
replace it with logic that simply uses "." to load
files directly.
config/git files are now directories, also containing
pkg.cfg files each with the same variables as before,
such as repository link and commit hash
this change results in a noticeable reduction in code
complexity within the build system.
unified reading of config files: new function setcfg()
added to lib.sh
setcfg checks if a config exists. if a 2nd argument is
passed, it is used as a return value for eval, otherwise
a string calling err is passed. setcfg output is passed
through eval, to set strings based on config; eval must
be used, so that the variables are set within the same
scope, otherwise they'd be set within setcfg which could
lead to some whacky results.
there's still a bit more more to do, but this single change
results in a substantial reduction in code complexity.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is bloat, because it's something the user can already
do at runtime configuration anyway.
set it to a reasonable default of 8 seconds instead of 5,
and don't honour the timeout variable in target.cfg.
this will be documented in the next release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the background is only a few kb. the whole rationale
before was to limit the space used in memdisk, but this
decision was made when the background was much bigger;
it has since been optimised greatly, and the grub modules
were heavily reduce, so it should be safe.
grub's memdisk breaks when you add too much data to it.
as part of simplifying the rest of lbmk, this change removes
some more bloat from the rest of lbmk. handling this in the
memdisk is much simpler than handling it with cbfstool.
Signed-off-by: Leah Rowe <leah@libreboot.org>
remove nvme support from the "default" grub tree
now there are three trees:
* default: no xhci or nvme patches
* nvme: contains nvme support
* xhci: contains xhci and nvme support
this is in case a bug like lbmk issue #216 ever occurs
again, as referenced before during lbmk audit 5
there is no indication that the nvme patch causes any
issues, but after previous experience i want to be sure
Signed-off-by: Leah Rowe <leah@libreboot.org>
certain code checks for build.list, to skip it, for
example in items()
we already use config/data/grub to store grub config data
that applied to all trees
create these directories too:
config/data/coreboot
config/data/u-boot
config/data/seabios
move the respective build.list files in here, and also
to config/data/grub
now multi-tree projects contain, per directory, just the
target.cfg file and the patches directory. this is much
cleaner, because some of the logic can be simplified more
Signed-off-by: Leah Rowe <leah@libreboot.org>
See:
https://codeberg.org/libreboot/lbmk/issues/216
Almost all users will be OK running GRUB, but a
minority of users have experienced a fatal error
pertaining to grub_free() or grub_realloc() (as
my investigation of GRUB sources reveal when grepping
the error reported in the link above).
We don't yet know what the bug is, only that the
error occurs, leading to an effective brick if the
user has GRUB as their primary payload.
So far, it has only been reported on some Intel
SandyBridge-based Dell Latitudes in Libreboot, but
we can't be too sure.
The user reported that memtest86+ passes just fine,
and SeaBIOS works; BIOS GRUB also works, which means
that the bug is likely only in an area of GRUB that
runs specifically on the coreboot payload, so it's
probably a driver in GRUB when running on the metal
rather than BIOS/UEFI.
The build system supports a configuration whereby
SeaBIOS is the primary payload, but GRUB is available
in the SeaBIOS boot select menu, and an additional
configuration is available where GRUB is what SeaBIOS
executes first (while still providing boot select);
both of these are now the *only* configurations
available, on all x86 targets except QEMU.
The QEMU target is fine because if the bug occurs there,
you can just close QEMU and try a different image.
Even after this bug is later identified and fixed,
the GRUB source code is vastly over-engineered and there
are likely many more such bugs. SeaBIOS is a reliable
payload; the code is small and robust. Remember always:
Code
equals
bugs
Therefore, this configuration change is likely going
to be permanent. This will apply in the next release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
blobs.list is now nuke.list
this is because i'm going to import this functionality
into lbmk (libreboot build system).
libreboot will not do full deblobbing like canoeboot does,
but there are still certain files that i like to delete
in releases, such as u-boot's strlcat.c file under tests
calling it "nukeblobs" in libreboot makes no sense, but
i like to avoid merge conflicts when cherry-picking
patches between cbmk and lbmk, so i like to make sure
that functions and variables common to both are named
the name.
simply calling it "nuke" or calling the files "nuke.list"
is probably inoffensive while conveying the same meaning.
Signed-off-by: Leah Rowe <info@minifree.org>
The E6400 uses a 100 MHz reference clock on DPLL_REF_SSCLK, whereas
libgfxinit assumed that the reference was always 96 MHz. The frequency
difference caused by a 100 MHz reference with PLL config values
calculated assuming a 96 MHz reference were not significant enough to
cause noticable issues with the more common 1280 x 800 panels, but are
enough to matter for the 1440 x 900 panels which use a higher pixel
clock. This only affected the pre-OS graphics environment provided by
libgfxinit, as Linux drivers would determine the reference clock
frequency based on data in the VBT.
Fix this by making the reference clock frequency in libgfxinit
configurable for GM45 based on a new coreboot Kconfig, which is set to
100 MHz for the E6400.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
the release variable is all we need, turning a target on
or off for a given release.
the status checks were prone to bugs, and unnecessary; it
also broke certain benchmark scripts.
it's better to keep the cbmk logic simpler. board status
will be moved to the documentation instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
was reported broken on canoeboot 0.1, which uses 2021
coreboot. we use much newer coreboot now in libreboot, but
still, better be cautious. set to release=n.
i'll set status and remove release=n if it works on testing
Signed-off-by: Leah Rowe <leah@libreboot.org>
Same idea as my never-download-microcode patch. Even if a
coreboot config enables blobs, the blobs are not actually
downloaded or inserted or otherwise handled in any way.
This means I can re-use lbmk-based coreboot configs without
as much modification, thus reducing the maintenance burden
for Canoeboot releases.
Signed-off-by: Leah Rowe <info@minifree.org>
With other recent changes, and this patch, Canoeboot is now
in sync with Libreboot lbmk, commit:
cd9685d12d2b71a00cb6766bb85f392d4db92c83
This is with updated deblobbing, and Canoeboot's no-microcode
patches, that disable microcode updates universally.
Several patches from lbmk (for coreboot) aren't needed,
due to being for boards that Canoeboot does not use, so
those patches have been somewhat rebased, and configs
adapted, but this is otherwise identical.
As in previous Canoeboot updates, I've turned off this
option in all coreboot configs:
CONFIG_USE_BLOBS
Turning off that option prevents the coreboot build system
from ever attempting to use any blobs, but in practise it
would not have done so anyway, because Canoeboot disables
all handling of microcode in the build system.
Signed-off-by: Leah Rowe <info@minifree.org>
it should be marked unstable, though these machines
are basically reliable; they have certain missing features
and quirky behaviour so it's important not to over-sell it
mark it as unstable, on all of the dell latitudes
Signed-off-by: Leah Rowe <leah@libreboot.org>
raminit has never been fully reliable on this board, and so
this board has never been stable. so, now that lbmk specifies
such status per board, mark these boards as such.
Signed-off-by: Leah Rowe <leah@libreboot.org>
export CBMK_VERSION_TYPE=x
x can be: stable, unstable
in target.cfg files, specify:
status=x
x can be: stable, unstable, broken, untested
if unset, cbmk defaults to "unknown"
if CBMK_VERSION_TYPE is set, no confirmation is asked
if the given target matches what's set (but what's set
in that environmental variable can only be stable or
unstable)
if CBMK_RELEASE="y", no confirmation is asked, unless
the target is something other than stable/unstable
"unstable" means it works, but has a few non-breaking
bugs, e.g. broken s3 on dell e6400
whereas, if raminit regularly fails or it is so absolutely
unreliable as to be unusable, then the board should be
declared "broken"
untested means: it has not been tested
With this change, it should now be easier to track whether
a given board is tested, in preparation for releases. When
working on trees/boards, status can be set for targets.
Also: in the board directory, you can add a "warn.txt" file
which will display a message. For example, if a board has a
particular quirk to watch out for, write that there. The message
will be printed during the build process, to stdout.
If status is anything *other* than stable, or it is unstable
but CBMK_VERSION_TYPE is not set to "unstable", and not building
a release, a confirmation is passed.
If the board is not specified as stable or unstable, during
a release build, the build is skipped and the ROM is not
provided in that release; this is in *addition* to
release="n" or release="y" that can be set in target.cfg,
which will skip the release build for that target if "n"
Signed-off-by: Leah Rowe <info@minifree.org>
Leah Rowe