set to release="n" for now until the eDP targets
are fixed.
the regular non-eDP targets are stable, and will be
released.
Signed-off-by: Leah Rowe <leah@libreboot.org>
some latitudes still used the old style for variables
in target.cfg, specifically arch="x86_64" - lbmk used to
then check that on a big if/else and translate it to the
correct target name for crossgcc, e.g. i386-elf, arm-eabi
now it just puts the arch directly, in a new variable:
xarch
change arch="x86_64" to xarch="i386-elf" in these files.
also remove a few obsolete variables. should build now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
github is unreliable. i host these files myself.
coreboot uses intel.com again now in the latest revisions, and
intel broke it before. i'm going to start backing up the acpica
releases onto my rsync server from now on, and keep patching
coreboot to use my files.
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 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>
On T60 with Libreboot 20231106 and the GRUB payload, a user
reported this error in GRUB when a battery was connected:
"alloc magic is broken at 0x7b1aedf0: 0"
This error disappears when a battery is not connected, or
when using Libreboot 20230625. The issue has persisted
through to LIbreboot 20240225 and after, and I believe the
issue will be somewhere in coreboot, not in GRUB itself.
For now, switch i945 laptops (X60, T60, Macbook2,1) back to
the February 2023 coreboot revision used in Libreboot 20230625.
A bisect can be done before the next Libreboot release, ETA
May 2024, if time permits. Otherwise, this revert should solve
the problem for now, at least so far as Libreboot is concerned.
The following coreboot patches have been backported:
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
These patches fixed S3 on GM45 machines, though it will be useful on
the i945 machines aswell.
The reason I'm doing it this way it is because I don't have a battery
for my X60 or T60, and my T60 isn't in a very good state either,
so I can't reproduce the error myself yet.
Signed-off-by: Leah Rowe <leah@libreboot.org>
GRUB has not pushed many patches to master since the recent 2.12
release, but there are a number of interesting fixes.
libreboot 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 libreboot
"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 <leah@libreboot.org>
i added mkukri's patch but didn't enable it. this was intentional.
this patch enables tpm by default, on all 9020 sff/mt targets.
most users probably won't need it, but enabling it won't hurt.
Signed-off-by: Leah Rowe <leah@libreboot.org>
at present, the inject scripts compress refcode in a way
that is not reproducible, so there's no way to verify
that the firmware is correct, via checksum verification,
when injecting vendor code on release images
the lack of reproducibility in recompression will have to be
addressed, but the issue is that lbmk does not provide its own
sources for compression utilities, instead opting to use the
system's own compression utility
so the solution might be for lbmk not to use the host's utility,
and compile its own, or insert the refcode uncompressed. for now,
simply disable the hp 820 g2 target in libreboot releases
this uses the same logic recently implemented for excluding
mrc-based haswell images in libreboot releases
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>
sff happened to work, but mt would not boot with the patch,
because it called die() on unknown chassis type, and the gpio
happened to have a bad value in the old patch, because it wasn't
reading the right gpio.
i tested the fix on the old patch, but then decided to use
mate's new patch because instead of calling die(), it simply
boots with fan control disabled (max fan speed in that case),
if this happens again.
mt and sff have both been tested with this new version of the
patch. both of them boot, and they both have proper fan control.
Signed-off-by: Leah Rowe <leah@libreboot.org>
a hangover from earlier days, but i still disable it. i forgot
to do so on this config, when updating the nri code. do it now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
hell added a patch fixing S3 on haswell NRI, but it seems
you still need to set 8MB CBFS size as with the MRC
tested on a t440p. S3 now works on haswell NRI.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the t440p/w541 configs were re-done from scratch, because
the coreboot revisions are nearly two years apart.
i also added corebootfb configs.
hell updated their patchset. this patchset uses the following patch:
https://review.coreboot.org/c/coreboot/+/81948/1
it uses this, along with parent patches in the haswell nri patch series
Signed-off-by: Leah Rowe <leah@libreboot.org>
see:
https://review.coreboot.org/c/coreboot/+/81529
what i've merged is patchset 4. i had to rebase it slightly,
because the libreboot version has the iommu toggle on cmos
configs, which are files that mate's patch also changes,
leading to merge conflict.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the grub payload was previously disabled, because the libre
mrc code sets up xhci rather than ehci, and grub did not have
xhci support (not natively).
libreboot now has xhci support in the grub payload, so enable
grub on these configurations.
Signed-off-by: Leah Rowe <leah@libreboot.org>
broadwell mrc enables both igpu and dgpu to be enabled
at any given time. if the onboard (intel) gpu is set as
primary, the logic to disable it is not executed within
coreboot; instead, the igpu is used for vga decode.
on some t440p/w541 thinkpads, both an intel and nvidia
gpu are present. in this setup, the intel gpu must be
used for vga, and all output, but rendering can be
offloaded to the nvidia gpu (nvidia optimus).
optimus would never work on haswell mrc.bin, because it
always disables the igpu when a dgpu is present, so a hack
exists in coreboot that hides the dgpu from mrc, so that the
igpu remains enabled. broadwell mrc doesn't do this, so the
option to hide PEG devices has been disabled in these
configs.
the broadwell mrc has better peg device handling, and can
support 16gb modules on broadwell hardware; it may well
support these modules on haswell hardware too, though ddr3
sodimms are very hard to find (and expensive). (and currently
untested, with this patch)
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>
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. libreboot will have
to maintain these from now on. the patches have been rebased for
use with grub 2.12.
Signed-off-by: Leah Rowe <leah@libreboot.org>
3rd sata slot (of 3) broken on 9020 sff, and the 3rd and 4th (of 4)
slots are broken on 9020 mt
this patch fixes them on both, so that all ports work properly
Signed-off-by: Leah Rowe <leah@libreboot.org>
Needed to make graphics cards work. Turn it on if you're using
only the Intel GPU.
With IOMMU *enabled*, graphics cards do not work reliably at all.
The cause still needs to be investigated, but the symptoms are
graphical corruption on the screen, and Xorg usually crashes.
In some cases (on some cards), TTYs can still be used; the payload
can still be used reliably, on a graphics card, but Xorg fails to
work properly.
This could be a bug in Linux drivers, instead of anything that
coreboot does (not yet tested in factory BIOS).
Leaving it off by default will ensure reliable operation on all
setups, whether an iGPU or dGPU is used.
Signed-off-by: Leah Rowe <leah@libreboot.org>
It is now possible to disable the IOMMU on Haswell
boards, by doing this on your ROM image:
./nvramtool -C libreboot.rom -w iommu=Disable
To enable it again, do this:
./nvramtool -C libreboot.rom -w iommu=Enable
If not specified, the default behaviour is *on*.
A follow-up patch will turn IOMMU *off* by default,
on Dell OptiPlex 9020 SFF/MT, by setting it as such
in cmos.default. This is to make graphics cards work
properly to work around a bug when it's turned on.
Leaving the IOMMU enabled is recommended, if it works.
It works in most cases, including on 9020 SFF/MT when
using the Intel GPU without a graphics card inserted.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the current entry is fine, but it would then not support
other configs of different flash sizes, unless they are
explicitly defined.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is required by the Latitude E5530, which uses a Broadcom NIC
instead of the Intel ones. The original port was missing this file.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Iru Cai's port from Gerrit:
https://review.coreboot.org/c/coreboot/+/39398
Now with the proper MXM structure, which removes the 30 second POST
delay. Tested with i7-2670QM, Quadro 2000M and 32GB RAM.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
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>
The OptiPlex 9020/7020 port was merged first and was numbered 31.
Increment the numbering of the Latitude patches to reflect this.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
i enabled it but it's buggy according to comments on gerrit.
disable for now. dgpu didn't work anyway, even with it turned
off, when i had this tested.
Signed-off-by: Leah Rowe <leah@libreboot.org>
keep dell9020mt_12mb
dell9020mtvga_12mb doesn't actually work (was tried for
running a graphics card on its own, with no igpu init)
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was done automatically by running:
./update trees -u coreboot
this has to be done when adding patches for now board ports,
because of the way lbmk and also coreboot's build systems work.
the configs just have to be re-generated to include a line
that says the entry for the newly added boards isn't set. look
at the diff of this commit as an example.
Signed-off-by: Leah Rowe <leah@libreboot.org>
on a dgpu setup, igpu was still in use, when tested
by a user. do separate roms that don't enable anything
vga in coreboot, relying instead only on seabios to
execute a vga rom. these roms will only work if you
have a graphics card.
Signed-off-by: Leah Rowe <info@minifree.org>
Specifically the MT versions. The SFF versions will
be added separately, in a later commit.
See: https://review.coreboot.org/c/coreboot/+/55232
This patch has been added, from patchset 31. It still
has some unresolved issues, on that patchset, but
it should boot. See commit message there.
Of note: I've enabled PCI REBAR, though it's unknown
whether it will work (some comments there about it though,
on that gerrit page).
I've also set CBFS size to 8MB, not the full size of
the BIOS region; this is required on the T440p which
uses the same mrc.bin file, to get S3 working.
TSEG stage cache disabled, as on other Haswell boards.
The setup: SeaBIOS-only as first payload, but with GRUB
enabled as secondary payload. The _grubonly setup has
been enabled here. This way, the config will work on
iGPU and dGPU setups without issue.
Signed-off-by: Leah Rowe <info@minifree.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>
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>
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>
re-use the same patches, and drop the same patches.
this tree uses hell's special ddr2 fix, which we apply
for the dell latitude e6400.
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>
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>
in a build test, canoeboot 0.1 builds, but master doesn't,
and neither does lbmk. i changed a few of them when doing
the crossgcc build optimisation patches.
i'm just copying the configs from there. unlike in the
canoeboot version of this patch, i've re-enabled microcode
updates in these lbmk configs.
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>
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>
with neutered ME, fan control fails. while there are
ways to mitigate it, many users will not, and will
likely see their system overheat, which is very
dangerous.
this bug (failed fan control on neutered ME) only
affects arrandale machines such as lenovo x201.
the newer machines are not affected by this.
other arrandale machines will probably not be added
to libreboot because of this, or they will be subject
to further testing.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is of Broadwell platform, one generation above Haswell.
Of note: this uses HP Sure Start. Although the flash is 16MB,
our CBFS section (and IFD configuration) assumes 12MB flash,
so the final 4MB will be left unflashed on installation,
after blanking the private flash. The coreboot documents have
more information about this.
Some minor design changes in lbmk were made, to accomodate
this port:
Support for extracting refcode binaries added (pulled from
Google recovery images). The refcode file is an ELF that
initialises the MRC and the PCH. It is also responsible for
enabling or disabling the Intel GbE device, where Google
does not enable it, but lbmk modifies it per the instructions
on the coreboot documentation, so as to enable Intel GbE.
Google's recovery image stores the refcode as a stage file,
but coreboot changed the format (for CBFS files) after 4.13
so coreboot 4.13's cbfstool is used to extract refcode. This
realisation made me also change the script logic to use a
cbfstool and ifdtool version matching the coreboot tree, for
all parts of lbmk, whereas lbmk previously used only the
default tree for cbfstool/ifdtool, on insertion and deletion
of vendor files - it was 81dc20e744 that broke extraction of
refcode on google's recovery images, where google used an older
version of cbfstool to insert the files in their coreboot ROMs.
A further backported patch has been added, copying coreboot
revision f22f408956 which is a build fix from Nico Huber.
Iru Cai submitted an ACPI bugfix after the revision lbmk
currently uses, for coreboot/default, and this fix is
needed for rebooting to work on Linux 6.1 or higher. This
patch has been backported to lbmk, while it still uses the
same October 2023 revision of coreboot.
Broadwell MRC is inserted at the same offset as Haswell,
so I didn't need to tweak that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Actually, it's 2 commits after 2.12, because there was a
patch added afterwards, fixing a build issue on Gentoo.
These changes are present in GRUB 2.12, relative to the
revision that we previously used on lbmk:
* b835601c7 build: Include grub-core/extra_deps.lst in dist
* 8961305b4 Bump version to 2.13
* 5ca9db22e Release 2.12
* 477a0dbd5 efi: Add support for reproducible builds
* dcc1af5d6 efi: Generate stack protector canary at build time if urandom is available
* e424e945c efi: Initialize canary to non-zero value
* 7c8ae7dcb gfxmenu/gui_image: Fix double free of bitmap
* 63fc253fc commands/acpi: Fix calculation of ACPI tables addresses when processing RSDT and XSDT
* f20123072 libnvpair: Support prefixed nvlist symbol names as found on NetBSD
* a13df3d15 bootstrap: Don't check gettext version
* 6d2aa7ee0 kern/mm: Use %x and cast for displaying sizeof()
* b3d49a697 configure: Add RPATH for freetype on NetBSD
* 52dbf66ea configure: Add *BSD font paths
* 2d6a89980 autogen: Accept python3.10 as a python alternative
* 3d4cb5a43 build: Rename HAVE_LIBZFS to USE_LIBZFS
* e4dbe5cfa gnulib: Tolerate always_inline attribute being ignored
* 31e47cfe2 util/editenv: Don't use %m formatter
* f5905f656 osdep/bsd/hostdisk: Fix NetBSD compilation
* cb1824a87 osdep/generic/blocklist: Fix compilation
* 2f3faf02c disk/diskfilter: Remove unused variable
* 3815acc57 build: Tolerate unused-but-set in generated lexer/bison files
* c129e44e7 loader/i386/bsdXX: Fix loading after unaligned module
* 89fbe0cac grub-core/Makefile.am: Make path to extra_deps.lst relative to $(top_srcdir)/grub-core
* 353beb80c util/grub-install: Move platdir path canonicalization after files were copied to grubdir
* f18a899ab util/grub-mkstandalone: Ensure deterministic tar file creation by sorting contents
* ed74bc376 util/grub-mkstandalone: Ensure stable timestamps for generated images
* 069cc46c9 net/http: Fix gcc-13 errors relating to type signedness
* e7a831963 templates: Reinstate unused version comparison functions with warning
* 3f9eace2d util/grub-install: Delay copying files to {grubdir,platdir} after install_device was validated
* e60015f57 efi: Set shim_lock_enabled even if validation is disabled
* e35683317 docs: Improve bli module documentation
* 57059ccb6 bli: Add explicit dependency on the part_gpt module
* 154dcb1ae build: Allow explicit module dependencies
* 17c68472d kern/ieee1275/init/ppc64: Display upper_mem_limit when debugging
* 5f8e091b6 kern/ieee1275/init/ppc64: Fix a comment
* dc569b077 kern/ieee1275/ieee1275: Display successful memory claims when debugging
* 0ac3d938a loader/powerpc/ieee1275: Use new allocation function for kernel and initrd
* 2a9a8518e kern/ieee1275/cmain/ppc64: Introduce flags to identify KVM and PowerVM
* 679691a13 kern/ieee1275/init/ppc64: Rename regions_claim() to grub_regions_claim()
* d49e86db2 kern/ieee1275/init/ppc64: Add support for alignment requirements
* fe5d5e857 kern/ieee1275/init/ppc64: Return allocated address using context
* ea2c93484 kern/ieee1275/init/ppc64: Decide by request whether to initialize region
* 0bb59fa9a kern/ieee1275/init/ppc64: Introduce a request for regions_claim()
* aa7c13226 fs/xfs: Add large extent counters incompat feature support
Most notable in the above log, that are beneficial to Libreboot
users, are:
aa7c13226 which improves XFS support (large extents), which is default
now on many setups.
ed74bc376 which introduces more stable timestamp generation when using
grub-mkstandalone. this is what lbmk uses to generate grub.elf, whereas
grub previously only implemented this fix on mkimage which we don't use
f18a899ab which ensures deterministic (reproducible) tar file creation
by sorting contents (file names / directories). this is done by sorting
the entries
f5905f656 which improves grub build system reliability on netbsd and
openbsd systems - useful for us because an ambition of lbmk is to port
the build system to run on bsd systems, and we will still want grub -
several other of the changes here are beneficial for BSD aswell, all
or most of them by Vladimir Serbinenko
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is now used in grub, for the FS_PAYLOAD_MODULES
option in the make command
lbmk should generalise as much logic as possible. in
some parts of it, logic is hurrently hardcoded, specific
to a given project that lbmk uses, but lbmk is essentially
a source-based package manager, like what you might find
on a small linux distro, so we need to try to
be as generic as possible.
lbmk is the "build system of build systems", so it has to
work generically with as many of them as possible
Signed-off-by: Leah Rowe <leah@libreboot.org>
it is no longer hardcoded just to be handled for uefiextract.
it is now defined as cmakedir in target.cfg, for a single or
multi tree project. if multi tree, it is applied to the specific
tree, and has to be defined per tree
the way it works is: as per cmakelist, a project will define
which directory is to be built, and it will then generate
a makefile in the main source tree (the build tree in cmake
language, where the main CMakeLists.txt file exists)
when the makefile has been generated, the project is then treated
like any other project. the way cmake works, if a makefile has
already been generated by it, in a given directory, running it
again will fail and not affect anything; if it fails but the
makefile doesn't exist, then something is wrong, but if the
makefile does exist, then it's all fine and nothing happens
at present, this is only used for uefiextract, which is part
of src/uefitool
Signed-off-by: Leah Rowe <leah@libreboot.org>
at present, the bootstrap and configure script is only
directly executed for grub, because grub is the only
project that uses them in lbmk
however, when i start adding linuxboot support, i will
have to start building a lot of projects, some of which
make use autoconf and bootstrap scripts
e.g.
./bootstrap --foo
./configure --bar
the "bootstrap" script is often used on GNU programs,
because they like to over-engineer absolutely everything
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>
i had to run make-oldconfig on all of them, because
of the port that riku added the other day. lbmk doesn't
use defconfigs, it uses full configs, so we have to
make sure they're kept in sync
this patch is the result of running the following command
in a fresh clone of lbmk:
./update trees -u coreboot
i should probably switch to defconfigs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
riku committed a new patch, that fixes build errors
when PICO_DEFAULT_LED_PIN is not defined, on a given
board. in such cases, riku's new patch just disables
handling of the status LED, but LEDs continue to work
on boards where it is defined.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the new revision sets drive level to 12mA instead
of the default 4mA. 16-20mA is the maximum tolerated
level for data lines, on most flash ICs, so 12mA is
relatively safe.
riku did this a while ago, tested on pico pi.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the e6400_4mb target has libgfxinit and (if seabios) vgarom
initialisation, but has issues on the nvidia model, even when
using nomodeset. with this target, e6400nvidia_4mb, only
the vgarom initialisation is used, libgfxinit is disabled.
on nvidia models, this one should work a little bit better.
specifically: nouveau crashes on this machine, with libreboot
installed, but you can use nomodeset. however, when libgfxinit
is also enabled, nomodeset no longer works properly.
so this target disables all video initialisation in coreboot.
only seabios will initialise anything video-related, by
executing the vga option rom.
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>
this affects 8460p and 8470p only, as the others' updates
aren't common across different boards
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
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>
Leah Rowe