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>
release="n" is set in target.cfg on haswell build targets
that use mrc.bin
script/update/release exports LBMK_RELEASE="y"
script/build/roms skips building a given target if release="n"
in target.cfg *and* LBMK_RELEASE="y"
you could also do the export yourself before running ./build roms,
for example:
export LBMK_RELEASE="y"
./build roms all
This would skip these ROM images. The native haswell raminit is
now stable enough in my testing, that I wish to delete the MRC-based
targets. This is in line with Libreboot's Binary Blob Reduction Policy,
which states: if a blob can be avoided, it should be avoided.
The problem is that users often run the inject script in *lbmk* from
Git, instead of from the src release archive. I forsee some users
running this on modern lbmk with older release images. If the mrc-based
target isn't there, the user may use an NRI-based target name, and
think it works; they will insert without MRC. I foresaw this ages
ago, which is why Caleb and I ensured that the script checks hashes,
and hashes are included in releases.
Therefore: for the time being, keep the MRC-based configs in lbmk
but do not include images for them in releases. This can be done
indefinitely, but I'll probably remove those configs entirely at
some point.
On the following boards, Libreboot now will *only* provide NRI-based
ROM images for the following machines:
* Dell OptiPlex 9020 SFF
* Dell OptiPlex 9020 MT
* Lenovo ThinkPad T440p
* Lenovo ThinkPad W541/W540
I now recommend exclusive use of NRI-based images, on Haswell
hardware. It's stable enough in my testing, and now supports S3.
Signed-off-by: Leah Rowe <leah@libreboot.org>
broadwell mrc has better peg handling and can support 16gb
modules on broadwell machines - the blob can be used on haswell
machines too, instead of haswell mrc, and it might support 16gb
modules on these machines (not yet tested, but using broadwell
mrc does at least boot as reliably as haswell mrc anyway)
one little quirk with haswell mrc is that it actually handles
vga decode, disabling the igpu entirely, when a dgpu is used.
the broadwell mrc enables both GPUs and does not handle vga
decoding, so we must handle this the usual way; my patch for
this was merged upstream and i'm also adding it to libreboot,
which currently uses an older coreboot revision. this is needed
for dgpu to work. see patch:
0040-nb-haswell-Disable-iGPU-when-dGPU-is-used.patch
broadwell mrc may also make dealing with nvidia optimus setups
more reliable, on laptops that have nvidia GPUs, but this patch
does not add bmrc configs for t440p/w541
NOTE: on t440p/w541 laptops with nvidia graphics, the video output
is wired to intel but rendering can be offloaded to nvidia. in this
setup, we want vga decode to be done on intel, so i've set these
configs to enable CONFIG_ONBOARD_VGA_IS_PRIMARY (set it to y)
Signed-off-by: Leah Rowe <leah@libreboot.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>
the x220 edp patch invalidated lots of configs, so
i did: ./update trees -u coreboot
this is the resulting patch
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>
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