| Age | Commit message (Collapse) | Author |
|---|
|
Commit 3ee4cc9ddec62276c374f8c7f0c0b3322cfaa9f6 (fix typo in dell
latitude coreboot coreboot config) fixed a typo from ${VARIANT_DIR) to
$(CONFIG_VARIANT_DIR). While this does work, since CONFIG_VARIANT_DIR is
a valid variable, it is not technically correct, as the default VBT path
set by coreboot's Kconfig files uses $(VARIANT_DIR), which is the same
as CONFIG_VARIANT_DIR, but with quotes stripped out.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
these configs were otherwise correct, but i typo'd a variable
in them when manually rebasing the old configs, after switching
to nicholas's new ports implemented as variants, where the old
ones in lbmk were individual board ports for those same boards.
Signed-off-by: Leah Rowe <info@minifree.org>
|
|
Several patches are now merged upstream and no longer needed
in lbmk, such as the HP EliteBook 8560w patch, and related
patches. Some patches were changed, for example the Dell Latitude
ivb/snb laptops are now variants in coreboot, instead of being
individual ports; now they re-use the same base code.
This this, the corresponding files under config/submodules
have changed, for things like 3rdparty submodules e.g. libgfxinit,
and tarballs e.g. crossgcc.
This is long overdue, and will enable more boards to be added.
This newer revision will be used in the next release, and some
follow-up patches will merge these trees into default:
* coreboot/haswell
* coreboot/dell
Signed-off-by: Leah Rowe <leah@libreboot.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. for this, "vcfg" is added as a variable
in coreboot target.cfg files, referring to a directory
in config/vendor/ containing a file named pkg.cfg, and
this file then contains the same variables as the
erstwhile config/vendor/sources
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>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
A subsequest revision will set them again as needed,
per coreboot target.
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>
|
|
working s3 means i'm happy to mark it as being stable.
Signed-off-by: Leah Rowe <leah@libreboot.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>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
also warn about issues, in a warn.txt file for each.
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>
|
|
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
Tested by Minimum_Baseball_629 on Reddit
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
nic3-14159/lbmk:latitude-ports into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/183
|
|
Tested by Martin Dawson.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
Tested by Martin Dawson.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
Tested by Martin Dawson.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
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>
|
|
CONFIG_PS2M_EISAID. this is a a string used for the
identifier on the mouse, in ACPI.
CONFIG_PS2K_EISAID this is used for the keyboard.
IASL comes back with this build error:
dsdt.asl 1884: Name(_HID, EISAID("DLLK0534"))
Error 6045 - ^ EISAID string must be of the form "UUUXXXX" (3 uppercase, 4 hex digits) (DLLK0534)
Change DLLK0534 back to PNP0303 and
change DLL0534 back to PNP0F13. These are generic identifiers
for PS/2 keyboard and mouse. Any generic driver will work with
the onboard mouse/keyboard on these machines. They do not need
to be changed. These are the default values anyway. Just leave
them explicitly defined to the default values, for now; if these
options are not set, coreboot will default to these values.
This shouldn't break anything for the users. I've reported this
to Nicholas Chin, author of those patches. Libreboot imported
the new versions of E6430/E6530 board patches in the coreboot
revision update, but the new (technically correct) values broke
IASL, so I've decided to use the old values for now.
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/+/80023
https://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>
|
|
at present, lbmk can remove microcode updates on images for
a given target, if the target specifies
microcode_required="n" in target.cfg
lbmk then provides images with microcode, and images without,
in a given release. although the user can also remove them
manually, this just makes it a bit more convenient, for those
users who do wish to run without the updates. this functionality
is provided only on those platforms where no-microcode is tested.
well, this behaviour implements a compromise on libreboot policy,
which is to always include microcode updates by default. see:
Binary Blob Reduction Policy
the *canoeboot* project now exists, developed in parallel with
libreboot, and it ships without microcode updates, on the same
targets where lbmk also handled this.
running without microcode updates is foolish, and should not
be encouraged. clean up lbmk by not providing this kludge.
the libreboot documentation will be updated, telling such users
to try canoeboot instead, or to remove the update from a given
libreboot rom - this is still possible, and mitigations such as
PECI disablement on GM45 are still in place (and will be kept),
so that this continues to work well.
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>
|
|
nic3-14159/lbmk:e6530 into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/151
|
|
Fix a few issues with the E6430 configs to make it consistent with
configs for other boards and function as intended.
- Add VBT to CBFS: Although the VBT was enabled at the board level
Kconfig in a previous commit (CONFIG_INTEL_GMA_HAVE_VBT), the config
to actually add the VBT to CBFS was still unset.
- Enable the static option table: The old config would always use the
fallback values hard coded in the coreboot tree, rather than the
settings in the cmos.default file
- Enable DRAM clear on boot: This was not set previously, even though
most other boards set this for security.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
This is pretty much the same as the E6430
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
This is to support future patches for other Ivy Bridge Dell Latitudes.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
|
|
The original E6430 patch included the Intel VBT file, but did not
actually enable it in Kconfig. Update the patch to enable it and
update the E6430 configs.
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
This reverts commit 29e9c32e32f8e947f51a3efe375dab3ef8e1987e.
|
|
this is to work around recent s3 suspend/resume issues
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/10
https://review.coreboot.org/c/coreboot/+/78815/1
Accordingly, update configs to match the new default.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
also, enable seabios_withgrub on e6400, but not grubfirst;
right now, we also support dgpu which would brick on
grubfirst. on my tested nvidia model, loading grub from
seabios worked, so i'm going to re-add seabios_grubfirst
functionality like in older libreboot revisions, enabled
selectively on a given target.
e6430 currently only has igpu support anyway, but i've done
the same thing there, in anticipation of future dgpu support.
e6400 and e6430 ec report scancode set 2 with translation
by default, but only actually output scancode set 1
grub is trying to use scancode set 2 without scancode
translation, so the key inputs get messed up
fix it by forcing scancode set 2 with translation, but
only on coreboot; other build targets on GRUB will
retain the same behaviour as before
courtesy goes to Nicholas Chin who inspired me, and
helped me to fix this. tested on Nicholas's E6400
and E6430, and my E6400; Riku also tested it on
non-Dell, as did I (some thinkpads), and all seems OK.
The new behaviour in coreboot GRUB is essentially no
different to that of SeaBIOS, which does the same.
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>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
