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>
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>
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 lbmk logic simpler. board status
will be moved to the documentation instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
export LBMK_VERSION_TYPE=x
x can be: stable, unstable
in target.cfg files, specify:
status=x
x can be: stable, unstable, broken, untested
if unset, lbmk defaults to "unknown"
if LBMK_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 LBMK_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 LBMK_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 <leah@libreboot.org>
coreboot gerrit patch 55232, patchset 31
the actual board will be enabled in a follow-up patch.
merging the patch on its own first is better practise,
to run ./update trees -u coreboot
this way, there won't be a revision that breaks builds,
due to the idiosyncratic nature of coreboot configuration.
Signed-off-by: Leah Rowe <info@minifree.org>
Base revision changed to:
commit b6cbfa977f63d57d5d6b9e9f7c1cef30162f575a
Author: Morris Hsu <morris-hsu@quanta.corp-partner.google.com>
Date: Fri Jan 5 16:48:17 2024 +0800
mb/google/dedede/var/metaknight:Add fw_config probe for multi codec
and amplifier
Of note:
Several out-of-tree ports have been adjusted to use the new SPD config
style, where it is defined in devicetree. I manually updated the E6530
patch myself, based on the update that Nicholas did on E6430 (Nicholas
will later update the E6530 patch himself, and I'll re-merge the patch).
Several upstream patches now exist in this revision, that we were able
to remove from lbmk.
The heap size patch was reverted upstream, as we did, but see:
https://review.coreboot.org/c/coreboot/+/80023https://review.coreboot.org/c/coreboot/+/79525
Although we still disable the TSEG Stage Cache, ivy/sandy/haswell should
be reliable on S3 now (leaving TSEG Stage Cache disabled, for now, anyway).
Also included in upstream now:
commit 29030d0f3dad2ec6b86000dfe2c8e951ae80bf94
Author: Bill Xie <persmule@hardenedlinux.org>
Date: Sat Oct 7 01:32:51 2023 +0800
drivers/pc80/rtc/option.c: Stop resetting CMOS during s3 resume
Further patches from upstream:
commit 432e92688eca0e85cbaebca3232f65936b305a98
Author: Bill Xie <persmule@hardenedlinux.org>
Date: Fri Nov 3 12:34:01 2023 +0800
drivers/pc80/rtc/option.c: Reset only CMOS range covered by checksum
This should fix S3 on GM45 thinkpads.
Signed-off-by: Leah Rowe <leah@libreboot.org>
arch no longer needs to be set, on multi-tree projects,
and it has been renamed to xarch
the new behaviour is: if xarch is set, treat it as a
list of crossgcc targets and go through the list. set
the first one as the target, for what lbmk builds, but
build all of the defined crossgccc targets
crossgcc_ada is now xlang, and defines which languages
to build, rather than whether to build gcc-gnat
Signed-off-by: Leah Rowe <leah@libreboot.org>
don't handle "romtype" at all, in board target.cfg files
add /dev/null as pike2008 rom on amd boards. this serves
the same purpose, adding them as empty vga roms, to add
an empty rom in cbfs. pike2008 cards cause seabios to hang,
when their oproms are executed, so we insert a fake rom
on i945 thinkpads, use the coreboot config option:
CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK
when set, this enables the same bootblock copy, for use
with bucts. these two cases, namely pike2008 roms and
i945 bootblock copies, no longer need to be handled in code
Signed-off-by: Leah Rowe <leah@libreboot.org>
only call crossgcc for coreboot and u-boot, but use
hostcc for everything else. simplify the checking of
which architecture to compile for. "arch" in target.cfg
files has been modified, to allow further simplification.
without this patch, the logic currently only *barely* avoids
using crossgcc on things like utils, and only works in practise
because, in practise, lbmk only works on x86_64 anyway.
the new logic, as per this patch, is simpler and more robust.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it didn't work in the past, but it does work nowadays;
specifically, it only worked with libgfxinit in the past,
but not on VGA ROMs.
now it does work on VGA ROMs, tested on e6400 and t1650 so
it was enabled there.
in this setup, a special image is provided where SeaBIOS is
the main payload, but it only loads GRUB; nothing else, every.
this is called SeaGRUB. this setup is useful in cases where
the user only has a GPU that lacks libgfxinit support.
Signed-off-by: Leah Rowe <leah@libreboot.org>
My previous fix to revert didn't fix S3 on GM45, one
of the platforms reported fixed by 78263; I'm merging
that instead, at patch set 10.
It is referenced by 78815/1 which was split from it,
so merge that too (restores overrides of higher values,
on certain platforms that we don't use yet).
https://review.coreboot.org/c/coreboot/+/78623/10https://review.coreboot.org/c/coreboot/+/78815/1
Accordingly, update configs to match the new default.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the patch:
https://review.coreboot.org/c/coreboot/+/78270
this has been reverted, because it caused s3 resume
issues on most intel laptops in libreboot.
i was going to merge this instead:
https://review.coreboot.org/c/coreboot/+/78623
however, it's under review, and this doesn't change
to the old behaviour; it keeps the new universal
config, but changes the default
we know the old logic works, so keep that for now.
in fact, the offending patch was only merged to
main in coreboot, one day before i recently
updated coreboot revs in coreboot/default - i used
a 12 october revision, the patch above is 11 october
i then ran "./update trees -u coreboot" which updated
the heap sizes back to the old defaults. this should
fix s3 suspend/resume where it was broken, in the
libreboot 20231021 release - a point release with this
and a few other fixes is planned soon.
Signed-off-by: Leah Rowe <leah@libreboot.org>
as opposed to the current 3-level structure.
recent build system simplifications have enabled
this change, thus:
./build fw coreboot -> ./build roms
./build fw grub -> ./build grub
./build fw serprog -> ./build serprog
./update project release -> ./update release
./update project trees -> ./update trees
./update vendor download -> ./vendor download
./update vendor inject -> ./vendor inject
alper criticised that the commands were too long,
so i made them shorter!
Signed-off-by: Leah Rowe <leah@libreboot.org>
Riku's mSATA patch for HP8300USDT was merged upstream, so the
patch has been dropped from lbmk because it is contained within
this new coreboot revision.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in the future, we may start downloading files that aren't
blobs, such as mxm port configs (on mainboards that use
MXM graphics)
this directory will contain all of those files
generally change the language used, across lbmk, to make
use of "vendorfile" instead of "blob"
Signed-off-by: Leah Rowe <leah@libreboot.org>
We don't have a directory names "srces", just "src".
Ditto ecs, mrcs <-- it's just ec and mrc
When referring to a file, e.g. blob/t1650/me.bin, that
makes much more sense, because it's a single blob, not
multiple blobs.
Don't pluralise what isn't plural
Signed-off-by: Leah Rowe <leah@libreboot.org>
build/release/src was partly re-written to accomodate this
memtest86plus was patched to have a central Makefile, and
lbmk modified to use that, rather than mess with build32
and build64. the central Makefile just builds both targets
or cleans both targets
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe