in some cases, the build system was needlessly, and sometimes
erroneously, creating crossgcc symlinks, which then caused an
issue, namely:
in lbmk release builds, dell e6400 is build before fam15h boards,
and it sets xtree, but fam15h_rdimm doesn't, and later this would
cause fam15h_rdimm boards to use xtree="default" (because they don't
set xtree), causing the newer toolchain to be used on coreboot 4.11.
this patch fixes the issue. quite a simple problem, actually.
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>
the boarddir variable is only set *after* detect_board
is run, and is in fact checked after that. this check,
removed by this patch, is too early and causes lbmk
to exit with error states. this patch fixes the error.
the error was that lbmk was then searching for a file
that is at an empty path.
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>
the changelog file is only present in releases, so
use the presence of this file for the test.
someone who wants to fetch projects within a release
archive can simply use the git repo, or delete the file.
Signed-off-by: Leah Rowe <leah@libreboot.org>
use the git log, as follows:
git log --graph --pretty=format:'%Cred%h%Creset %s %Creset' --abbrev-commit
this creates a nice, uniform list of changes.
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>
the "kmapdir" variable was removed in an earlier audit,
but was overlooked for -k because that option was untested.
rather than initialise the variable, re-use grubcfgsdir.
this fix enables e.g. "-k usdvorak" to work again.
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>
In order for the EC to maintain the state of whether or not to set the
flash descriptor override across a power cycle, the AC adapter must be
connected, as the system leaves the voltage rail that the EC uses
powered under this condition. Without this, the utility may fail,
continually asking the user to power off and on.
On Linux, CONFIG_X86_IOPL_IOPERM must be set for the kernel, or else the
iopl call will error with "Function not implemented". Make a note of
this in case a user runs into this issue.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
the update/trees script checks this binary itself, before
deciding whether to recompile/compile, so we don't need
to do such checks here.
Signed-off-by: Leah Rowe <leah@libreboot.org>
u-boot doesn't use submodules, so there's no point in
checking for it. now we can do with just one call to
the git submodule command, for simplicity
also, general code cleanup in this file (minor code
formatting improvements)
Signed-off-by: Leah Rowe <leah@libreboot.org>
the directory is checked for deletion, but it's already
checked before download, to see whether it already exists.
lbmk already exits with zero status if the directory exists,
so the check is pointless (in this function)
also, general code style/formatting cleanup
Signed-off-by: Leah Rowe <leah@libreboot.org>
the patchfail variable was only needed in the old design,
where git am was being handled inside a subshell, and
also when we did it directly in the target directory
without using a temporary directory. with the current
design, we can just call err() and ditch the tmp repo
Signed-off-by: Leah Rowe <leah@libreboot.org>
there isn't really a problem right now, but a desired
and implemented behavioural change was that patches are
to be applied *before* updating submodules. well, the
previous commit reversed this change, under certain
conditions, such that submodules were applied first.
this patch fixes it, so that patches are done first.
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>
right now, if we want to patch a project such that certain
submodules are no tdownloaded, or diffreent submodules are
downloaded, or current ones are downloaded from other
locations, we cannot do this, because we apply submodule
updates *before* applying patches.
therefore, we should change it so that they are applied
*after* installing patches.
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>
the logic of the previous commit was correct, but one
of the functions was named the same as another function
used in this file, causing a namespace conflict, and
a build error
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>
the script can now also handle autoconf build systems,
whereas this could previously only be done for grub.
with this change, the overall sloccount is also lower
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>
while seemingly pedantic, this does actually make code
easier to read. mostly just switching to shorthand for
variable names, where no expansions or patterns are used
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 rom functions print a path to the rom they built,
which is then used, but these are called inside what
are essentially subshells, and we had no error handling
Signed-off-by: Leah Rowe <leah@libreboot.org>
cros roms are always using libgfxinit, with a coreboot
framebuffer, so the "normal" initmode is never used.
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>
lbmk used to set version/versiondate directly in
err.sh, but now it's handled there by a function,
which is called by the main script.
script/update/release hadn't yet been adapted. the
only change necessary is to call check_project()
script/update/trees also makes use of it
script/build/roms is using "projectname"
Signed-off-by: Leah Rowe <leah@libreboot.org>
when make-all is being executed on a coreboot tree,
the "./vendor download target" command is used, where
target is the tree/board name.
that script then checks whether cbfstool and ifdtool
are built, and if they're not, they then call
./update trees -b coreboot utils bla bla bla
in this scenario, project=coreboot and mode="", meaning
make-all, and the same check that checks whether the
vendor download script should be run, is executed,
which in turn then checks cbutils again
fix the infinite loop by checking whether it was coreboot
utils, as opposed to *firmware*, that is to be built, before
running ./vendor download
Signed-off-by: Leah Rowe <leah@libreboot.org>
the x_ function doesn't handle arguments with spaces
well, and this cd command is going to an asterisk, so
it's unknown what the resultant string will be.
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>
the purpose of script/update/release is not to test the
build system, but to build release archives.
testing of lbmk is done during the course of development.
remove this bloat from the release script. we run the nuke
mode anyway, to scrub blobs from releases, which will more
or less test the logic in that script (the only difference
is that it runs e.g. ifdtool --nuke instead of -i).
Signed-off-by: Leah Rowe <leah@libreboot.org>
why are we distributing gcc at all?
the coreboot build system downloads it at build time,
and the GNU rsync mirrors aren't going anywhere.
simplify script/update/release by not handling gcc.
this means: release archives will no longer contain gcc.
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>
the shellball (for extracting the coreboot rom, to get
at mrc.bin) contains lines that are not posix-friendly.
specifically, the "local" command is used, and this is
not defined for posix sh.
the shellball is essentially just a bunch of shell
functions that compress/decompress the zip file,
containing the firmware update. you can modify the
files and re-run the shellball to recompress, though
lbmk just uses the decompress function.
as pointed out by Nicholas Chin, it is possible to just
run "unzip" directly on the update, to get at bios.bin.
we don't really need all the extra checks performed by
the shellball, so let's just bypass it altogether.
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>
The component 1 and 2 densities were still set to 8 MiB and 4 MiB
respectively, which is incorrect for 16 MiB only configurations.
Change the component 1 density to 16 MiB so that the address space
gets properly mapped to SPI 1. In addition, change the number of
components field (byte 0x15) to 0x00 to indicate 1 flash chip.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Inside the BIOS update, there's 68SCE and 68SCF variants.
Based on Qubes HCL and browsing linux-hardware.org, these are
Probook 6360b and Elitebook 8460p respectively.
I checked the KBC1126 EC Firmwares within the update file, both
use the exact same firmware images. Following-up will be a very
similar but untested port for 6360b.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
remove unnecessary "continue" command. it's written
at the end of a for loop, where it'll continue anyway
Signed-off-by: Leah Rowe <leah@libreboot.org>
this part of the code *must* return. the for loop
afterwards must not be permitted to execute.
it's unlikely that this would ever occur, unless
perhaps the user is using a very buggy sh.
Signed-off-by: Leah Rowe <leah@libreboot.org>
there are special menuentries just for loading
configs, without handling luks, lvm and whatnot.
it's intended for users of cd/dvd drives. well,
now we support both extlinux and grub, with this patch.
Signed-off-by: Leah Rowe <leah@libreboot.org>
isolinux/syslinux/extlinux config files should all work,
using the syslinux parser function in grub
the current behaviour is to only search for grub.cfg,
so extlinux users can't use the default libreboot setup.
with this change, their systems should hopefully work.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the so-called EFI System Partition (ESP) is used
on many UEFI-based setups. some users may be
migrating to libreboot, so let's support it.
on BIOS setups, it would be e.g.
/boot/syslinux/syslinux.conf
on UEFI setups, it would be e.g.
/boot/EFI/syslinux/syslinux.conf
additionally, support scanning for extlinux.conf
Signed-off-by: Leah Rowe <leah@libreboot.org>
lvm/* is slow to resolve in grub, on some machines,
because grub enumeration is very slow in general.
however, many people will install distros with any
number of lvm configurations, so we should try to
support them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 20389655e4.
If the user actually has encryption, but has /boot unencrypted,
this will considerably slow down the boot, so the patch has
been reverted.
The patch was originally meant to favour encrypted /boot
setups, but the old behaviour also still works there.
when the user sets up an encrypted machine, grub.cfg
defaults to non-encrypted setups if found, first
this patch reverses the order, deferring to
non-encrypted installations only when encrypted ones
are unavailable
Signed-off-by: Leah Rowe <leah@libreboot.org>
These systems have a report that the unlock utility does not work.
Until there are multiple reports of failed unlocks and a technical
determination of why it doesn't work, they will not be listed as
explicitly unsupported.
As this utility requires access to /dev/mem, the default protections of
Linux and OpenBSD must be relaxed to allow this. Make a note of this in
the instructions.
The old Open Security Training site had a course called Advanced x86:
BIOS and SMM Internals, which had a set of slides outlining the method
to supress SMIs by changing the GBL_SMI_EN bit. Add a reference to it as
this is where I originally learned of this method.
all it did was set -v in the shell, which doesn't yield
very useful results. this is a relic of very old design
in the libreboot build system, that is no longer needed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
lbmk didn't quote certain arguments in commands, or
used ! -z instead of -n, things like that. simple fixes.
Signed-off-by: Leah Rowe <leah@libreboot.org>
most of these are probably redundant, and will never
be called, but lbmk needs to be as safe as possible
under fault conditions. fail early, fail hard.
Signed-off-by: Leah Rowe <leah@libreboot.org>
update/trees wasn't correctly returning non-zero status,
even though it was printing an error message, when git-am
failed. this is due to the way subshells work, and it was
overlooked in previous auditing.
additionally: don't directly copy trees to the destination,
instead patch/reset first, then copy only under normal
condition, just as with single-tree projects.
when running build/roms, the script would continue after
a bad git-am, without exit. this patch fixes it in the
most paranoid way possible. i'm now fairly confident that
lbmk will fail gracefully and efficiently, under error
conditions. this should prevent bad image builds.
Signed-off-by: Leah Rowe <leah@libreboot.org>
install libfreetype-dev, instead of libfreetype6-dev
this still works in debian stable (currently 12.2) but
fixes debian sid, as of 15 November 2023. my test machine
with debian sid could not install libfreetype6-dev, but
could install libfreetype-dev
Signed-off-by: Leah Rowe <leah@libreboot.org>
apparently some people use fat file systems for /boot
on linux systems
this is apparently a thing
it's ridiculous, but also a thing
a user reported they could not boot their t400 because
of those, because they have such a distro installed
on their machine
apparently it was a gentoo user
i don't really care. re-add 1980s dos file system support.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Now the revision is:
64e3cee72ab8f5876abfebb263b5e6cf7c4a9a4e
The old revision was:
e58b870ff926415e23fc386af41ff81b2f588763
With this new revision update, the following patches have
been imported from the upstream GRUB project:
* 64e3cee72 gpt: Add compile time asserts for guid and gpt_partentry sizes
* 7de6fe963 types: Split aligned and packed guids
* 5fc985bfd gpt_partition: Mark grub_gpt_partentry as having natural alignment
* 7ad30299d efi: Deduplicate configuration table search function
* c6cf807fc lsefi: Add missing static qualifier
* a964e359b types: Fix typo
* 3f79e3b15 util/grub-mount: Check file path sanity
* 85e40b36e configure: Make the DJVU_FONT_SOURCE configurable with --with-dejavufont=FILE
* 2d6631d2a configure: Make the Unifont FONT_SOURCE configurable with --with-unifont=FILE
* 07318ee7e fs/xfs: Fix XFS directory extent parsing
* ad7fb8e2e fs/xfs: Incorrect short form directory data boundary check
* 4e10213de Revert "zfsinfo: Correct a check for error allocating memory"
* 4266fd2bb disk/i386/pc/biosdisk: Read up to 63 sectors in LBA mode
* cab04dcda kern/i386/pc/init: Flush cache only on VIA C3 and earlier
* 3c7e84257 fs/btrfs: Zero file data not backed by extents
* 4bcf6f747 kern/ieee1275/init: Restrict high memory in presence of fadump on ppc64
* cf58eca2a tests/util/grub-shell: Enable RNG device to better test stack smashing
* c3bdf263f kern/efi/init: Disable stack smashing protection on grub_efi_init()
* 95963d97f disk/cryptodisk: Add support for LUKS2 in (proc)/luks_script
* 016f14257 disk/cryptodisk: Optimize luks_script_get()
* f7a663c00 term/serial: Ensure proper NULL termination after grub_strncpy()
* a19e47ca4 commands/efi/lsefisystab: Print the UEFI specification revision in human readable form
Signed-off-by: Leah Rowe <leah@libreboot.org>
in cases where lbmk must always return from a function,
there are some cases where it relies on non-zero exit
status, which in practise is always the case, but may
change in the future if the relevant part is modified
e.g. do_something && return 0
the proper form is:
do_something
return 0
also do this for unconditional exits
Signed-off-by: Leah Rowe <leah@libreboot.org>
don't run it directly at the bottom of err.sh,
because otherwise the version and versiondate
files will be generated when running "./build
dependencies distroname" which would then create
these files, but as root because the user runs
that specific command as root.
the rest of lbmk, for any other command, prevents
use of the root account, so running check_project
during "./build dependencies distroname" will cause
the build system to fail (because as non-root user,
the user will run lbmk and it will try to update
those files, and fail because it can't, due to lack
of permissions)
this patch fixes the issue, by only generating those
files if the user is *not* root
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
now the docs are complete, in releases. they
contain the libreboot site, libreboot images,
the untitled static site generator and untitled
static site generator documentation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this replaces the previous behaviour, which erred
on a specific value of grub_errno, which was a
problem if other types of errors used that value.
due to the way i patch out the prefix error messages,
this new patch ensures that only those errors are
silenced. all other messages will be printed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it still printed "error: ." on screen, instead
of the prefix message.
now it's silent. it just says:
Welcome to GRUB!
Signed-off-by: Leah Rowe <leah@libreboot.org>
it can annoy some users, so just silence it. we don't need
a lot of modules so we only have a few, but some distro
grub configs can load modules frivilously.
Signed-off-by: Leah Rowe <leah@libreboot.org>
TSEG Stage Cache enabled again, because disabling it
did not affect S3 in any way.
Many configs have changed, and debug level is set to 7.
In testing with V-T60 on IRC, it wasn't just removal of
the DDR2 patch that I did, but I re-did the configs too,
in exactly the same way I've done them here, when testing
on an X200 to fix boot issues.
Libreboot does not use defconfigs, instead it uses full
configs, and these have to be updated. I normally just
run make-oldconfig on every config, for revision updates.
However, every now and then, we need to re-do them.
Play it safe and re-do every config. I've double- and
triple-checked that the configs are correct.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the ddr2 fix broke *ddr3* on gm45 thinkpads in
testing, depending on memory modules. this was
established by removing patches, re-doing
configs etc, on a user's X200 (testing gentoo
and freebsd). the X200 kept randomly rebooting
or having random glitches.
the configs themselves (gm45 thinkpads) will
also be re-done, because i found minor issues
unrelated, but this patch moves dell e6400 to
its own tree. the ddr2 fix is no longer present
in coreboot/default, only coreboot/dell.
i noticed minor differences in gm45 thinkpad
configs, when re-doing the configs, versus
what are currently in lbmk master; for instance,
vbt was not enabled anymore, on thinkpad x200.
modifications to these will be done separately.
Signed-off-by: Leah Rowe <leah@libreboot.org>
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.
with this, you can just do:
cd src/docs
./build
the html files would then be available for
publishing, if you wish, or you could set up
a local httpd to view them.
if you have pandoc installed, this will build the
markdown files into html
untitled static site generator is what generates
the html files, from the markdown files, on the
website. it will now also be included in releases.
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>
this is to ensure alphanumeric sorting, with
capital letters first; and numbers before letters.
we always relied on this, but until now lbmk would
just assume the host is configured this way.
this fixes a longstanding design flaw in lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
when printing the name of the rom being created, it's
done before the check to rename based on vendorfiles
in target.cfg. this patch fixes that bug.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's preferable that the vram setting be as high as
feasible, for users. we overlooked this on some
newer platforms that were added, over several
releases. these levels won't offend most users,
and people who want less can always turn it down
Signed-off-by: Leah Rowe <leah@libreboot.org>
Faulty keyboards make GRUB unusable. Normally it happens
when a user plugs in a faulty USB keyboard, but if it's
the laptop keyboard, then GRUB becomes unusable and the
user cannot boot anything.
So, your laptop keyboard is a ticking timebomb if you use
GRUB; with this patch, that's no longer the case.
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>
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 included in this revision is pulled from:
https://review.coreboot.org/c/coreboot/+/54024/2
contrary to hell's assertion of "not for merge", this does
in fact work nicely on a dell e6400; nicholas chin tested
on e6400 and found that those RCOMP values are the same
nicholas was testing some errant modules that seemed to
fail raminit in coreboot. in some cases, dell e6400 would
regularly fail coldboot even though reboot was ok; this was
therefore the cause of suspicioun for it being raminit-related
with this patch from hell (Angel Pons, but knows as hell
on IRC) it should fix boot issue on Dell Latitude E6400
Signed-off-by: Leah Rowe <leah@libreboot.org>
note: me6_update_parser needs to be written, similar
to me7_update_parser, to generate the partition
tables within intel me6 on lenovo bios updates.
the current logic in lbmk goes like this:
mkdir -p vendorfiles/cache/
and save your factory dump as:
vendorfiles/cache/x201_factory.rom
the build system has been modified, in such a way
as to support extracting me.bin (which is the full
one) and then neutering from this.
this is done automatically, if the file is present,
but you must first insert that file there, which means
you'll need a dump of the original boot flash on your
thinkpad x201
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>
the logic for naming coreboot roms is based on whether
cpu_microcode_blob.bin would exist in cbfs, and whether
deletion was therefore successful.
lbmk was naming nomicrocode on fam15h roms on this basis,
but the microcode was being inserted as microcode_amd.bin
and microcode_amd_fam15h.bin
in the recent 20231021 release, the roms were exclusively
labeled _nomicrocode in the rom names, but they do in fact
contain microcode.
i'm fixing it by telling lbmk *not* to delete microcode.
if microcode_required is not set, or it's set to y, then
only roms *with* microcode updates are provided; even if
the rom doesn't actually contain it, lbmk will only label
it _nomicrocode if that setting is set to n.
i'm not bothering to add further complexity to the rom
handling logic, because canoeboot now exists anyway (at
website https://canoeboot.org/) which is my new version
re-implementing the older, inferior version of libreboot
so i'm going to:
1) document this as errata in the release
2) cross reference in the freedom status page
3) if someone still isn't happy, i'll say use canoeboot
job done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it wasn't being copied right
the roms under elf/ were being copied, but not the ones
under bin/ - i need to audit it further
for now, i run modify_coreboot_roms from build/roms
instead of update/trees
so, the ones under elf/ no longer have bootblocks copied.
it's only done in bin/
Signed-off-by: Leah Rowe <leah@libreboot.org>
when building only for u-boot, the current script
works just fine. however, when building for other
payloads in additional to u-boot, the final u-boot
stage fails because other payloads are already
inserted via cbfs.
when we build u-boot, we do that last because we want
u-boot setups to only be u-boot, nothing else.
this patch enables qemu x86 to build properly with
u-boot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Add a U-Boot build for the qemu_x86_12mb board. The config is a copy of
the upstream "coreboot" defconfig, but with OF_EMBED=y.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add my upstream U-Boot series enabling video console support by default
for QEMU ARM virtual machines. Similarly, enable the related config
options for our builds using savedefconfig and olddefconfig.
The resulting ROM can be booted with a command line like:
qemu-system-aarch64 \
-machine virt,secure=on,virtualization=on \
-cpu cortex-a72 -m 1G \
-serial stdio -device VGA \
-device qemu-xhci \
-device usb-kbd -device usb-mouse \
-bios bin/qemu_arm64_12mb/*.rom
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
gru_bob fails to build without python-setuptools. this isn't a huge issue,
because most users probably have it already as many other python programs
depend on it too. that's probably why no one noticed until now,
when i tried to do this on a fresh artix install uncontaminated by python.
i also sorted and deduplicated the packages with 'sort -u'.
github's httpd b0rked the fuck out and i didn't want to wait
for them to fix it (ssl cert error) before i continued a build.
i now host the relevant acpica tarball on libreboot rsync,
mirrored to princeton.
Signed-off-by: Leah Rowe <leah@libreboot.org>
keymaps weren't being set in keymay.cfg of cbfs, due
to use of x_ in the rom script, and x_ doesn't handle
quotes or spaces in arguments well.
i'm going to remove use of x_ and xx_ (it's in my todo),
for next release.
for now, hot patch the release. i've gone through and
replaced use of x_ with || err, in some places.
not just the keymap.cfg command, but others too. in case
there are more issues we missed.
this commit is being tagged "20231021fix" and i'm using
this tag to re-build the 20231021 release. i'll just
replace the tarballs in rsync and add errata to the news
page announcing the release. all i did was break peoples
umlauts, i didn't brick their machines fortunately!
very minor bug. anyway, x_/xx_ is a great idea, but sh
isn't really designed for that style of programming. i'll
go back to using just || err in the next release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's not used by anywhere else in lbmk, but the release build
script will automatically download each project named as per
file names in config/git/
this is a stupidly simply way to prove documentation in
libreboot releases, and i've used current revisions corresponding
to the Libreboot 20231021 release, for this 20231021 release
of lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's been a while since we did encrypted /boot
and the current name sucks.
it's unlikely that anyone still uses it, but
people will soon
change the default assumed lvm name to grubcrypt
and stick to that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
clean it up after copying the tarballs
i really hate how this logic is written, it's clunky
but it should work; the only issue is that it's quite
slow, and inefficient on use of disk space.
however, i've not yet figured out how to reproducible
add files to a tarball, once the tarball has been created,
and i rely on sorting (of file names) when creating them.
it's really not a problem because normal people won't
use this script, only i or anyone who wants to test out
the libreboot release infrastructure. this script is
largely intended to *work*
but i'm still annoyed by how crappy it is. i'll fix it
after the Libreboot 20231021 release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
notabug is unreliable, even as a backup.
why, just today, it was offline! all day.
i originally moved libreboot away from notabug,
to codeberg instead, but kept the notabug account
online, and i still push to it when it's online.
however, notabug seems to be in a terminal state
of neglect by its admins, so lbmk should not use it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
everything downloaded, then tarballed, then built,
now crossgcc is downloaded by coreboot.
now extract, copy crossgcc tarballs, re-compress.
TODO: simply add files to the archive, without re-
compressing the whole thing.
this is still more efficient than the old way: build
everything, then clean and compress, making another
build test on the release archive necessary; with this,
there is still only one build test per release.
with this, and the previous revisions dealing with
submodules, the source archives should now be complete.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in release archives, .git is excluded but the version
and versiondate files are included. from these, the
git history is re-created with the exact date (but not
taking into account timezone, at present).
in this way, lbmk will have git history in a release
archive. some build systems, like coreboot, prefer that
there be git history available, so this is a nice
workaround on those build systems.
Signed-off-by: Leah Rowe <leah@libreboot.org>
flashrom-stable isn't really going anywhere
i'll decide at some future point what to do
with flashrom. for now, just give latest rev
Signed-off-by: Leah Rowe <leah@libreboot.org>
the grub backup was the same gnu server
i decided to host grub on codeberg, as backup
(gnu links as primary is ok)
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's ok for now to use it as a backup.
where only github was specified, i mirrored each
given repository to codeberg as main repo for lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's not actually needed in lbmk
flashrom can be downloaded separately by the user,
if they want to flash their chip
Signed-off-by: Leah Rowe <leah@libreboot.org>
do it using find -exec
this is more robust, and it will never need to be
maintained over time (famous last words).
this is done because now we download submodules
for all git projects, so it's hard to predict.
Signed-off-by: Leah Rowe <leah@libreboot.org>
when [] is used right at the end of a function, or
certain loops/subshells, some sh implementations will
just return a non-zero exit
Signed-off-by: Leah Rowe <leah@libreboot.org>
only fetch if .gitmodules exists
in some cases, lbmk is compiling source trees that
use submodules, without having downloaded them first.
in all cases, those submodules are either optional,
or the build system auto-fetches them (or if it can,
we sometimes disable it as with grub and gnulib).
this is a nice fallback behaviour, for situations where
we forget to put submodules as dependencies under
config/git (and disable submodules in the given project).
with this change, release archives are guaranteed to
be complete, sans crossgcc downloads in coreboot; this
will be handled in a follow-up commit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
config/git has been re-arranged in a prior revision,
ensuring that each file only refers to a main source
tree defined within those files.
the erstwhile "./build clean all" functionality is now
once again possible in lbmk
Signed-off-by: Leah Rowe <leah@libreboot.org>
don't put multiple downloads in the same files, except
when they are dependencies that go inside the directory
of another download.
by doing this, the following functionality will become
possible: clean every project or build every project,
or maybe fetch every project, based entirely on the
names of these files.
this will be used later to simplify the release script.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in some cases, use of x_ or xx_ can be error-prone,
due to the way $@ is handled; commands requiring
quotes, or with funny file names as arguments such
as spaces in the file name, or other special
characters, can make the x/xx functions break.
in those cases, where x/xx must not be used, the
commands use || err instead
in other cases, use of x/xx is superfluous, and has
been removed in some commands.
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>
i forgot to include option.sh in this script,
during previous re-factoring. the cbfstoos variable
is now defined exclusively in option.sh, but other
scripts can set it to something else.
Signed-off-by: Leah Rowe <leah@libreboot.org>
move it all to other files where items are used, and not
used anywhere else. this reduces the size of vendor.sh.
also remove a few redundant variables, or variables that
are not meaningfully used.
a few items have been moved to include/option.sh
Signed-off-by: Leah Rowe <leah@libreboot.org>
they are the functions only used by the download
script, so they don't belong in vendor.sh
an include file should only contain variables and
functions used by multiple main scripts
Signed-off-by: Leah Rowe <leah@libreboot.org>
i previously added this just for kicks, but it's not
actually needed; gnat isn't used on fam15h boards so
lbmk doesn't even use it (it's disabled).
in fact, i tested lbmk with crossgcc_ada handling
taken out, but with said patch; i still got build
errors with gnat anyway, on that old coreboot
revision (but gnat isn't needed there anymore).
Signed-off-by: Leah Rowe <leah@libreboot.org>
We don't really need a custom coreboot tree for Chromebooks. I had added
one, because at a cursory glance to the available config/coreboot/board
subdirectories I had the impression that I should. But upstreams have
one tree for every board and I think we should move towards that too.
Move the one important BL31 makefile patch into the default coreboot
patches, update the gru boards' configs by running savedefconfig in the
cros tree and then running olddefconfig in the default tree.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
By default U-Boot stores EFI variables in a ubootefi.var file in
whatever EFI System Partition it finds, which would be a FAT filesystem.
I'm occasionally finding out while testing that my ESPs somehow end up
with a corrupted filesystem, and I'm suspecting it's this.
For now, disable storing EFI environment variables on disk so that
U-Boot doesn't try to manipulate the filesystem.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Enable U-Boot commands to manipulate EFI environment storage, to
self-test EFI implementation, and to run a basic EFI test application.
These are so that we can test and debug EFI functionality easier.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
U-Boot upstream is switching to a new code framework for discovering and
booting OSes ("Standard Boot", or "bootstd"). Enable more features for
it, including commands we can use for introspection and debugging.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Normally U-Boot immediately resets the board on a panic. I had run into
"Synchronous Abort"s from shim and rEFInd, and having a traceback in
those cases can be useful. Hang instead of resetting, so the panic
reason stays on the screen.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
We should be able to power the board off from U-Boot command line.
Enable the "poweroff" command for gru boards so we can.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
U-Boot can keep a "copy" framebuffer to read from, for devices where
reading from hardware framebuffer is expensive. This needs the video
driver to support it. The Rockchip video driver doesn't need or support
it, so this option does nothing on gru boards. Disable it.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
U-Boot upstream used to have 16KB for EFI variables, and this was
causing problems with shim. Commit f0236acbc6 ("u-boot: Increase EFI
variable buffer size") fixed this by raising it to 32KB in our builds.
It has now been raised to 64K upstream, so raise it here as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
For Rockchip boards U-Boot tries to build SPI and MMC images that
require an externally built BL31 file to be provided, and the build
fails otherwise. This is not really as configurable as it should be.
In Libreboot, we only care about the build outputs for U-Boot proper.
There is a BL31 built during our coreboot builds, but using that in
U-Boot builds is a chicken-and-egg problem. Building BL31 outside the
coreboot build and passing it to both projects is possible, but needs
work.
For now, stop trying to build these U-Boot-only images as a workaround,
by removing the binman image descriptions from the device-tree sources.
Additionally, disable in our configs the BINMAN_FDT functionality that
allows using these at runtime as it requires them to be present.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
U-Boot upstream has added a reference counting for regulator enable
actions which somehow makes gru-kevin unbootable. Add a workaround
that makes it work again.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Set default U-Boot revision to v2023.01 and rebase patches on top of
that. Another series about 16x32 fonts was merged upstream, so drop some
now-unnecessary patches we had for that. For the video damage tracking
series, switch to the version I'm trying to upstream.
Upstream kconfig status is a bit unstable, so updating configs with
`make oldconfig` would miss important upstream changes, since they rely
on carrying defaults via upstream defconfigs. Update the configs as
such:
- Turn old configs into defconfigs (./update project trees -s u-boot)
- Save the diff from old upstream defconfig (diffconfig $theirs $ours)
- Update U-Boot revision, rebase patches, and clean old trees
- Prepare new U-Boot tree (./update project trees -f u-boot)
- Review the diffconfigs to see if any options were renamed upstream
- Copy over the new upstream defconfigs and apply earlier diff
- Turn new defconfigs into configs (./update project trees -l u-boot)
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add an "-s" flag for "make savedefconfig", "-l" for "make olddefconfig"
and "-n" for "make nconfig" to the update script. The first two are
mainly useful for U-Boot, to compare our configs to the upstream
defconfigs and stay in sync with any upstream changes. The latter is
because the ncurses one has a nice "Symbol Search" that can point out
the menu entry for a config symbol we know.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The U-Boot build for qemu_arm64_12mb board refers to a code revision
whereas it uses the common "default" tree, remove the bad reference.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The "u-boot.bin" file generated by U-Boot builds is a raw binary. When
adding payloads to a CBFS, we need to use ELF files with add-payload
or manually pass the entry point and load address of the payload binary
with add-flat-binary.
We primarily use the "u-boot.elf" which gets build with the REMAKE_ELF
option, as it also has the necessary device-tree binary that U-Boot
usually needs to work. When the option is not set (e.g. for QEMU), we
need to use the "u-boot" file which is an ELF.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
i wasn't getting the very first line of tar --version,
so it wasn't doing the check properly.
further sort the files by name within the tar archive.
for reliability, don't bother using versiondate anymore:
set a *fixed* date, and fixed timezone, to ensure
that it works reliably for reproducible tarball creation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This way, the handling of configs is unified into one
script, which reduces the possibility of bugs later,
and it reduces the repetition of code.
Signed-off-by: Leah Rowe <leah@libreboot.org>
use find and touch, to force all files, directories and
links to the desired timestamp (versiondate file)
Signed-off-by: Leah Rowe <leah@libreboot.org>
e.g. src/coreboot/coreboot must not appear in a release,
because we instead have directories like
src/coreboot/default or src/coreboot/cros
lbmk resets src/coreboot/coreboot to HEAD, but then resets
revisions properly in copies of it
therefore, for reproducibility, we must not include
src/coreboot/coreboot, src/u-boot/u-boot or
src/seabios/seabios into libreboot releases
Signed-off-by: Leah Rowe <leah@libreboot.org>
with --mtime, files added to the archive can be set
to a static date (in this case, the unix epoch)
the one used here is derived from git commit dates,
and it is static; if not being handled in lbmk.git,
the versiondate file never changes
this is the first patch in a series of patches designed
to bring about reproducible builds in libreboot
a solution will need to be found, for non-GNU tar
implementations, because they did not have an
equivalent option according to their manpages.
for example, BSD tar implementations.
perhaps i could systematically go around changing
file dates, on each file, as a fallback behaviour?
Signed-off-by: Leah Rowe <leah@libreboot.org>
this way, the src tarball is guaranteed to be clean.
the downside is that lbmk itself does not currently
handle crossgcc downloads, and there may be some
stragglers such as third party modules automatically
downloaded by certain codebases that libreboot uses.
this will have to be audited later (and it will be).
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's sometimes done unconditionally. this change
ensures that it is not repeated needlessly.
i observed otherwise that cbfstool would be
re-built from time to time, even if it was built.
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>
coreboot closely matches upstream, whose current release
is version 1.2 from 2018, and coreboot has not changed it
in any meaningful way.
the upstream did add patches since, but they are documentation
patches only.
this means: we do not need to use the upstream version
Signed-off-by: Leah Rowe <leah@libreboot.org>
under the current logic, errno would be ECANCELED
if neither checksum is valid, or I/O related if
pwrite fails; alternatively, the for loop exits
and the file has been written, where it is quite
correctly reset already.
ergo, the errno reset at the start of
writeGbeFile is superfluous. remove this bloat.
Signed-off-by: Leah Rowe <leah@libreboot.org>
previously, a bad checksum would have caused a non-zero
exit, even if the other checksum was correct (observed
when using the swap command)
Signed-off-by: Leah Rowe <leah@libreboot.org>
also rename elf/coreboot to something scary
some users were flashing roms built under elf/, which
lack payloads. lbmk builds no-payload roms (and payloads)
under elf/ then inserts them, creating full (flashable)
images under bin/
Signed-off-by: Leah Rowe <leah@libreboot.org>
This updates lbmk's copy of e6400-flash-unlock to commit c5567fece479
(README.md: Update with info about broader device support) in my
upstream repo.
Changes:
- Theoretical support for any Dell system that implements that flash
descriptor override command. This is done by reading base address
registers at runtime instead of hard coding them for specific devices.
Tested on the Latitude E6400 and Latitude E6430.
- Support for OpenBSD. It compiles, runs, and behaves as expected,
though I have not actually tested internally flashing with flashrom
yet. It should work though, as the program checks if the descriptor
override is set and the BIOS Write Enable is able to be set to 1, which
is all that is needed to internal flash.
- Integrated changes made in the lbmk copy
- Moved operating system accessor implementations to their own file
It should be fully functional, though minor formatting and cleanup
changes are still planned.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
it's already executed in "build"
running it in err.sh makes the user have to set
git name/email as root, when running dependencies
scripts. this is a regression, that this patch
fixes. git isn't needed to install dependencies.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is for the latest ubuntu release.
the ubuntu2004 config (for ubuntu 20.04) still exists,
and will remain in place.
Signed-off-by: Leah Rowe <leah@libreboot.org>
a user installed these dependencies in popos, but autopoint
was missing during the grub build.
add autopoint to the debian dependencies config.
Signed-off-by: Leah Rowe <leah@libreboot.org>
some users reported build errors. technically, there's
nothing wrong with lbmk but it relies on hostcc, and
hostcc is hit or miss when it comes to cross compiling
32-bit, depending on the build system of whatever project.
lbmk needs to handle cross compilation. for now, i'm just
disabling memtest86plus on non-64-bit hosts.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The logic has been re-written, where source archives are
concerned. This clones the current repository, and starts
a new build from scratch. A custom release directory is
possible, by passing -d
This eliminates a step during build-testing, saving hours
of time, because it builds the release archive *inside* the
release archive, with git files removed, thus replicating
the same setup that the user would have.
This also makes everything a bit more consistent, because
it's guaranteed that a release archive will always have
the same files; previously, the release build script would
only copy what was already built, without building anything.
Now, this script builds everything itself.
The script also builds serprog images, not just coreboot.
Usage:
./update project release
If -d is not passed, release/ is used inside lbmk.
Otherwise, you could do:
./update project release -d /path/to/directory
If the directory exists, this script will exit (error).
Other minor fixes: build/fw/coreboot: make version in
coreboot-version (file) not contain hyphens, to work
around a quirk in coreboot's build system when not building
on regular libreboot releases. this quirk only appears
when lbmk is not being compiled under git.
The other main benefit of this change is that the new
script will probably require a lot less maintenance.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the script used to be called once per target, now it
handles every target. the grub background image wasn't
being set, so if it changed at build time, it would
stay changed.
keep the default in place for each run, while still
allowing target.cfg files to change it per target.
Signed-off-by: Leah Rowe <leah@libreboot.org>
most of the changes since last revision aren't very
useful to us; most of them pertain to fs/ntfs, but
there is one that is interesting:
48f569c78a496d3e11a4605b0999bc34fa5bc977
kern/acpi: Skip NULL entries in RSDT and XSDT
Signed-off-by: Leah Rowe <leah@libreboot.org>
Just one script.
Just one!
Well, two, but the 2nd one already existed:
logic in update/project/trees and
update/project/repo was merged into
include/git.sh and update/project/build
was renamed to update/project/trees; an -f
option was added, which calls the functions
under git.sh
so git clones are now handled by the main build
script (for handling makefiles and defconfigs)
but the logic there is a stub, where git.sh
does all the actual heavy lifting
this cuts the file count down by two, and reduces
sloccount a reasonable amount because much of
the logic already exists in the build script, when
it comes to handling targets. git.sh was adjusted
to integrate with this, rather than act standalone
Signed-off-by: Leah Rowe <leah@libreboot.org>
otherwise, if src/grub/ was already compiled, this
would not print anything on the screen. however, the
files will have been created under elf/grub
this message just makes lbmk a bit more user friendly
Signed-off-by: Leah Rowe <leah@libreboot.org>
The benefit now is that it can be cleaned. E.g.
./update project build -b coreboot utils
./update project build -b coreboot utils default
./update project build -c coreboot utils
./update project build -c coreboot utils default
the update/project/build script checks when arguments
are provided after the project name. if the first one
is "utils", then it acts in the same way as the old
build/coreboot/util script
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's buggy. "./build fw coreboot" was made to work,
but it caused lots of unknown issues when mixing other
args
the old way wasn't broken. now, once again, you must
pass the "all" argument. e.g.:
./build fw coreboot all
Also, the confirmation messages at the end are a bit
clearer, when listing which ROM images were compiled.
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>
during the switch to src/ for all downloads, i
overlooked that the path check was hardcoded.
now the check for this binary is corrected.
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>
return with error status if no images were compiled
if a rom image fails to compile, then it will also
exit with error status, but sometimes you can pass
argument "cros" or "default", and it would not give
you rom images due to no target.cfg files, but these
are also ignored because of that.
this restores the same behaviour that existed before,
for this final error check.
Signed-off-by: Leah Rowe <leah@libreboot.org>
re-link update to build
build/update are the only two build modes now
i'm on a crusade to reduce the number
of files and directories, and reduce the number
of source lines, while not reducing functionality
Signed-off-by: Leah Rowe <leah@libreboot.org>
for the first time ever, this is a single script.
with recent simplifications in how variables are
handled, and techniques i've developed during
auditing, it's now feasible design-wise for this
to be a single script, without a helper script.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Previously, this script only checked for "Makefile",
but "makefile" is another valid name; additionally, if
GNU Make is used, "GNUmakefile" is an accepted default.
Signed-off-by: Leah Rowe <leah@libreboot.org>
There is no reason to err if no Makefile exists.
Just exit with zero status. This makes the following
command work:
./handle make file -c util/*
Within util/, there is me7 update parser which does
not have a makefile (it's a python script).
Signed-off-by: Leah Rowe <leah@libreboot.org>
The previous patch to the file was correct, except for
off by one at the end, resulting in no argument being
passed for project names.
Now the extra commands are run *before* handle_dependencies,
instead of running at the end of main. This prevents error.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The pager causes trouble in some cases, where the user has
to press enter at boot time depending on the configuration.
Interactive use is one thing, but we should leave this
disabled for smoother experience. If the user *wishes* to
use the shell, they can always just enable the pager
themselves by doing:
set pager=1
Signed-off-by: Leah Rowe <leah@libreboot.org>
At the end of the function, this script will now
run itself again if there are more arguments. This
enables the following:
./handle make file -c project1 project2 project3
Whereas previously, it could only do this:
./handle make file -c project1
Substitude -b and it's the same.
Signed-off-by: Leah Rowe <leah@libreboot.org>
general code cleanup, but a few exit commands were also
wrong. for example, relying on listitems to always return
zero status and then calling lbmk_exit 1
Signed-off-by: Leah Rowe <leah@libreboot.org>
some x_ calls are made that aren't needed. this is now
corrected. additionally, some x_ calls were being made
that are quite error-prone, like ones that use $PWD.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the one at the end of main is unnecessary, because
it's handled inside the for loop.
this file isn't used anywhere else, so it's OK.
Signed-off-by: Leah Rowe <leah@libreboot.org>
as it turns out, i delete "seen" inside the for loop,
which is a more thorough way to do it.
thus, the first rm command is unnecessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
slight sloccount reduction. light renaming of
functions between the two scripts, placing more
logic in main() under include/boot.sh
Signed-off-by: Leah Rowe <leah@libreboot.org>
errors are not defined for mktemp, and the /tmp file
system should be assumed reliable.
if /tmp is *unreliable*, then this is not something that
lbmk either can or should fix; the user clearly has
bigger problems.
manpages for mktemp do not define errors. it is assumed
to be completely reliable.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Instead of having detailed error messages, run most
commands through a function that calls err() under
fault conditions.
Where detail is still required, err() is still called
manually. Where it isn't, the error message is simply
whatever command was executed to cause the error.
This results in a massive sloccount reduction for lbmk;
specifically, 178 sloc reduction, or a 8.1% reduction.
The total sloccount is now 2022, for shell scripts.
Signed-off-by: Leah Rowe <leah@libreboot.org>
also: further reduce the number of arguments passed,
to certain functions as and when feasible, in cases
where those are global variables that never change.
the cbfstool argument in mkUbootRom wasn't even used.
that function was only using the global variable, which
again is only set once.
i also shortened a few messages, removed a few errant
line breaks and reduced sloccount by exactly 1 in main()
by re-arranging how the shift command is used.
it's mainly about shortening variable names, to then
reduce the number of line breaks, but it's a surgical
code size reduction in build/boot/roms.
Signed-off-by: Leah Rowe <leah@libreboot.org>
These are only ever initialised globally, and set once.
Other instances where they are set are only in cases
where they are passed as argument, at the start of
a function, so they are being *needlessly* re-set.
Set them only once and use them globally.
Signed-off-by: Leah Rowe <leah@libreboot.org>
-k, -p and -d let you set keymap, payload and displaymode
respectively, but the handling for this is buggy when
passing multiple arguments.
Support only one argument, for simplicity. This is how
people use them anyway, and it makes lbmk less buggy.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The *same* main() function is now used on both scripts.
However, merging both scripts together would be less efficient
on sloccount, and would be error-prone. The purpose of having
roms_helper is that the variables get re-initialised the same
way each time, for each board, automatically.
Signed-off-by: Leah Rowe <leah@libreboot.org>
If one of them doesn't exist, error out.
Previously, a build would start but then it would
error out later on. This implements the mentality:
fail early, fail hard
Signed-off-by: Leah Rowe <leah@libreboot.org>
e.g. -k ukqwerty
previously, this would not work:
./build boot roms -k ukqwerty all
only this would work:
./build boot roms all
this patch fixes the bug.
Signed-off-by: Leah Rowe <leah@libreboot.org>
update/blobs/download and update/project/repo both use
the same logic, for setting variables with awk and a
specially formatted configuration file.
unify this logic under include/option.sh, and use that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
mkdirs() should be in include/blobutil.sh, as should
extract_archive(), because that is primarily where
they are used.
script/update/blobs/download calls these functions
aswell, but it sources include/blobutil.sh so it's OK.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Don't use only wget. Some systems may only have curl.
The user can always install wget anyway, but why not
support both? I've added the right user agent string.
Signed-off-by: Leah Rowe <leah@libreboot.org>
They are only ever used by script/update/blobs/*, so
put them all in blobutil.sh. This cuts down on the
number of scripts in lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
mrc.bin is now handled by include/mrc.sh, adapted
from now-deleted script/update/blobs/mrc
much of the logic has been re-written or adapted for
inside script/update/blobs/download
mrc links/hashes now defined in config/blobs/sources
the new code is simpler (and smaller). in addition,
lbmk can now easily handle mrc.bin files for other
platforms such as broadwell. watch this space.
the full .zip download is now cached, like with other
vendor downloads. this means it won't be re-downloaded
if it was already downloaded before.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I was setting certain global variables inside for loops,
but some sh implementations won't like this.
Instead, don't run eval inside the for loops. Set a string
for eval inside the for loops, then execute eval outside of
the loops. This should work on every shell.
Signed-off-by: Leah Rowe <leah@libreboot.org>
individual functions for downloading each archive have
been removed. instead, eval is used in fetch_update(),
which is now renamed to fetch().
Signed-off-by: Leah Rowe <leah@libreboot.org>
the called functions directly call err() under fault condition,
so this additional handling is redundant.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This script is incomplete, buggy and its use is ill advised.
This script can be re-added later, when more work is done.
The download and/or inject script is recommended.
Signed-off-by: Leah Rowe <leah@libreboot.org>
use the variable names directly, as defined in defconfig.
do not hardcode the if/else chain in detect_firmware, use
eval instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
do not update them in project/repos - despite what
the previous commit message says, this behaviour is
error prone and should be avoided.
Signed-off-by: Leah Rowe <leah@libreboot.org>
With this change, lbmk now also updates submodules on
simple git clones, not just multi-tree clones.
This is OK, because git does not return non-zero status
when git submodule update is ran, where git submodules
are not actually defined.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is done recursively, with the following rule:
files first, then directories.
Where all patch files are applied from within the
patch directory, subdirectories (within the patch
directory) are then tried in alphanumerical order.
Then, within each subdirectory tried, the same rule
is once again applied. This is done recursively,
until every patch file is applied.
The code no longer applies *.patch, but instead any
file. Additionally, symlinks are avoided.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This functionality has never been used, except in the
erstwhile osboot project, and even then only experimentally.
It was intended for use with coreboot's gerrit site, but
it became Libreboot project policy that this not be relied
upon, instead preferring to include patches directly within
lbmk. This functionality can be re-added, if necessary.
Signed-off-by: Leah Rowe <leah@libreboot.org>
also: the grub-mkstandalone command didn't have
a || at the end, even though it did specify an err
call. This has been corrected, so that the command
now defers to err() under fault conditions.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This results in much cleaner copyright and license declarations.
SPDX headers are legally recognised and make auditing easier.
Also, remove descriptions of each script, from each script.
Libreboot documentation at docs/maintain/ describes them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
With this change, it's still possible to have a single
file at config/git/revisions, but this has been scrapped.
Instead, multiple files now exist under config/git/ with
the same modules declared, but the files are separated
logically. List of files under config/git:
* bios_extract
* biosutilities
* coreboot
* flashrom
* grub (gnulib also defined here)
* me_cleaner
* memtest86plus
* seabios
* serprog (multiple projects defined)
* u-boot
* uefitool
The rationale behind this change is simple: in the future,
we will stop relying on build systems within imported
projects for the import of git submodules. Instead, we
will handle them directly in lbmk.
Additionally, a Linux payload is planned for Libreboot, made
easier by the recent audit (script handle/make/config makes
it easy to integrate Linux, and handle cross-compilers for
userland utilities); a "linux" file under config/git/ could
also define rules for each project besides linux, such as
musl libc, busybox and other utilities.
Signed-off-by: Leah Rowe <leah@libreboot.org>
It's now 44 revisions above 2.12-rc1, not 17 above.
The additional patches (in GRUB master) contain several
important fixes, including cryptodisk and ZFS fixes plus
a few other interesting changes, namely:
14c95e57fddb6c826bee7755232de62efc8eb45b:
kern/misc: Make grub_vsnprintf() C99/POSIX conformant
296d3ec835ed6e3b90d740e497bb534f14fe4b79:
disk/cryptodisk: Fix missing change when updating to use grub_uuidcasecmp()
42a831d7462ec3a114156d56ef8a03e1d47f19e7:
ZFS: support inode type embed into its ID
96446ce14e2d1fe9f5b36ec4ac45a2efd92a40d1:
ZFS: Fix invalid memcmp
444089eec6042250ce3a7184cb09bd8a2ab16808:
ZFS: Don't iterate over null objsets
7ce5b4911005b2a0bfd716d92466b6711844068c:
ZFS: Check bonustype in addition to dnode type
There are more patches than this, but these are the
ones that strike me as interesting for Libreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
at this stage in the code, the file name will be NULL
value, so it would be improper to use it in a string.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the previous code size optimisations removed mention
of the file name, on file-related err() calls.
almost every error the user runs across will be file
related, so put the path on err() called from err_if()
Signed-off-by: Leah Rowe <leah@libreboot.org>
there is no need to have these as defines, when err_if
exists; get rid of xunveil and xpledge. use the bare
pledge and unveil functions directly, with err_if().
268 sloccount now on nvmutil.c, versus 289 sloccount
before this change, with no loss of functionality.
Signed-off-by: Leah Rowe <leah@libreboot.org>
non-zero exit, whereas it was previously an unhandled
non-zero exit as per -e - now it is simply more verbose.
Signed-off-by: Leah Rowe <leah@libreboot.org>
if ./build command options fails, it just means that
lbmk would next check whether ./buildpath mode list exists,
which it never will because that would violate lbmk design.
the generic "help" output is more than sufficient, and tells
the user to check "list" anyway, so there's no point in saying
it here. simplify this function.
Signed-off-by: Leah Rowe <leah@libreboot.org>
for example: ./build boot all
the "all" function is a relic from a much older lbmk
design, where for example we might have done:
./build clean all
./download all
this is no longer used, nor is this currently relevant
for the types of scripts present in lbmk.
we can always re-add this function later if needed,
but for now? remove unwanted code.
Signed-off-by: Leah Rowe <leah@libreboot.org>
moved cmake files into a separate build directory.
this can just be deleted for the source release.
might as well use cmake for the actual build too.
that makes repeated builds faster for some reason.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
flashrom distclean resulted in zero status upon exit,
but did not remove the actual flashrom binary.
our logic was to run distclean and defer to clean;
now, we run clean and *then* run distclean, but we
do not throw an error if distclean fails. (we do
throw one if clean fails)
Signed-off-by: Leah Rowe <leah@libreboot.org>
the builds were being created within that srcdir,
because build/release/src runs lbmk commands within
it, and one of them is building (re-building) it.
there's no point addressing this, other than rm -Rf
Signed-off-by: Leah Rowe <leah@libreboot.org>
the main lbmk script already creates these files,
and these files are then copied by build/release/src
so we don't need to re-create them here
Signed-off-by: Leah Rowe <leah@libreboot.org>
previously, it was possible that the distclean or
crossgcc-clean modes were being executed on the same
project tree, needlessly. this patch fixes that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
these commands weren't being run at all, leading
to binaries (such as xgcc) not being removed, and
thus they were present in tested release archives.
this bug did not affect libreboot 20230625. it
appeared during my audit, post-20230625.
Signed-off-by: Leah Rowe <leah@libreboot.org>
there were a few missing err calls
i actually went through all of lbmk and found no
instances where err calls were missing except in
build/boot/roms_helper
Signed-off-by: Leah Rowe <leah@libreboot.org>
if you copy a symlink, you create a whole new file with the
contents of what that symlink points to.
what we need to do instead is re-create the symlinks. this
is relevant for all symlinks to the main lbmk script, from
the main directory of lbmk.git.
this avoids there being multiple copies of the main lbmk
script, in release archives.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in some cases, messages that should be considered errors
or warnings, were being written to the standard output,
rather than written as error messages.
also: one or two printf statements should specifically
avoid printing errors (to any file); in these cases,
stdout has been redirected to /dev/null
Signed-off-by: Leah Rowe <leah@libreboot.org>
these scripts used to be in the main directory of
lbmk, and thus needed to check for root user, and
also git credentials. now they are called by the main
lbmk script, which also runs the same checks.
avoid waste of resources by not running the same
check twice.
Signed-off-by: Leah Rowe <leah@libreboot.org>
on e6400_4mb, the release build scripts remove nvidia's vga
rom which is used on dgpu models. however, microcode is also
removed in separately copied rom images
the inject script was inserting vgaroms directly into these
no-microcode roms, but the microcode blob is bigger than the
vga rom, and cbfstool inserts into the first available free
spot within cbfs, so it was inserting into the spot where
cpu microcode went. this caused the rom checksum to not match
what was generated during build/release/roms being executed
the only real fix is to guarantee offsets within cbfs for all
files, by recording what offsets were used and then calculating
that during insertion
so this patch is a workaround, but fixes the issue. the workaround
is: don't insert blobs directly on no-microcode roms, instead
insert only on microcode-based roms, then re-copy those roms
and remove microcode in aptly named copies
it's a bit more convoluted, but works perfectly fine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
sha-1 has known collision issues, which may not be readily
exploitable yet (in our context), but we should ideally use
a more secure method for checking file integrity.
therefore, use sha-2 (sha512sum) for checking files. this is
slower than sha-1, but checksum verification is only a minor
part of what lbmk does, so the overall effect on build times
is quite negligible.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Tested on a Nucleo-F042K6.
That has an onboard stlink:
`st-flash --format ihex write bin/serprog_stm32/serprog_nucleo-f042k6.hex`
The usb port used for flashing is separate, its is exposed on
the pin header instead. Check boards/nucleo-f042k6.h for usb pinout.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
where it is set to "both" (grub_scan_disk), inserting
scan.cfg is superfluous, because grub.cfg defaults to
both anyway, unless otherwise specified by scan.cfg,
and only if that file exists within cbfs.
thus, save a bit of build time (only a slight saving)
Signed-off-by: Leah Rowe <leah@libreboot.org>
target.cfg can now specify e.g.
grub_timeout=20
this would then be inserted as timeout.cfg in cbfs,
containing the instruction:
set timeout=20
HP laptops need a bit of extra time, due to the delay
caused by the EC bug workaround deployed in GRUB
desktops in general need extra time. this too is set to
10s, like the HP laptops.
only insert timeout.cfg if actually needed (declared in
target.cfg), otherwise grub.cfg will default to 5s
Signed-off-by: Leah Rowe <leah@libreboot.org>
My previous patch b0rked memtest and others because when making sure
their parent directory (the project root) exists, it would instead create
the project directory (memtest86lus). The later move would then put the
git repo inside that (memtest86plus/memtest86plus_123456).
We just need to make sure we don't create the target directory itself.
This way, there's no need to hardcode any project names.
Tested by ./updating rpi-pico-serprog, memtest86plus, grub and seabios.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
for example, the beep sound in debian's installer needs
this module.
the cute ding in the arch/artix menu also needs it
Signed-off-by: Leah Rowe <leah@libreboot.org>
it doesn't really make sense to have nvmutil.h
since this is only a very small program and not
intended for use as a library
Signed-off-by: Leah Rowe <leah@libreboot.org>
we are copying large numbers of ROM images, and the
host system may have /tmp under a tmpfs; that same
host system may or may not have a lot of memory.
respect the user's machine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we must conserve memory usage, in the event that the
user's /tmp is a tmpfs. copying of ROM images into
tmpfs is ill advised; we must copy them, due to how
the release process works (e.g. stripping of blobs,
but this must be done in a way so as to not interfere
with regular builds, thus they are copied instead)
Signed-off-by: Leah Rowe <leah@libreboot.org>
now under coreboot mainboards, target.cfg can specify
a background. if not specified, the 1280x800 one is
assumed, and used by default. it can be overridden.
the path should be relative to:
config/grub/background/
Signed-off-by: Leah Rowe <leah@libreboot.org>
explicitly set the count to 3, so that a maximum of 3
attemps are made per download, barring fatal errors such
as http 404.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the /tmp/ file system may be a tmpfs, with conservative
memory limits, depending on host system.
it's more likely that the user will have enough disk space
under tmp/ within lbmk (if they don't, they can't use
lbmk anyway). that is to say: more likely that they would
have the disk space, but not the memory.
Signed-off-by: Leah Rowe <leah@libreboot.org>
check based on whether defconfigs are available, which
are used extensively, rather than checking based on
whether target.cfg is available, which is not used
Signed-off-by: Leah Rowe <leah@libreboot.org>
also: only return zero status if rom images were succesfully
built, and print a list of each rom image directory based on
what was actually compiled, rather than just saying that the
rom images are stored under bin/
Signed-off-by: Leah Rowe <leah@libreboot.org>
the handling of target.cfg is *not* required, in
this script. other mechanisms are also used for
error checking. this script only uses defconfigs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this causes a saving of about 131KB uncompressed, when
i tested. we don't need mach kernel support. nobody will
ever use it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this causes a 6.7% decrease in the payload size
these file systems are microsoft(fat, ntfs) or mostly
oldschool amiga and beos file systems
also remove minix modules, and some old linux file
systems that nobody will use in 2023
Signed-off-by: Leah Rowe <leah@libreboot.org>
they weren't even handled at all, but they were referenced
under coreboot configuration
they don't need to be handled. lbmk simply includes these files.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it doesn't really make sense for them to be under
blobs/ - nominally, they are blobs, but they are
well-understood data files containing config data,
that is easily parsed by tools like ich9show or
ifdtool (and tools like bincfg or nvmutil)
blobs/ has been re-purposed: this directory no longer
exists in lbmk, but it is created (and on .gitignore)
when needed, by blobutil
thus, the blobs/ directory shall only contain vendor
files, and only those files that libreboot scrubs from
releases. therefore, build/release/src can (and has
been) simplified; it currently copies just the ifd and
gbe files from blobs/, selectively, and this logic is
quite error prone, requiring maintenance. now, the
build/release/src script simply copies config/ (which
only ever contains distributable files) and entirely
ignores the blobs/ directory
the blob download script already creates the required
directory, except for the sch5545 download; this is
now fixed
lbmk code size is slightly smaller, due to this patch
Signed-off-by: Leah Rowe <leah@libreboot.org>
the resulting changes are what i will push. this prevents
the coreboot build system from asking for user input.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This cuts down on build time, and it will allow libreboot
to remove large chunks of code.
these ifd/gbe configs are just binary-encoded config files,
in a format well-understood. they can easily be opened up
and displayed, using ich9show or ifdtool, and manipulated
by these tools; bincfg can generate them from scratch, and
nvmutil can change mac addresses, for example.
so, do this and remove from lbmk the following:
* ich9utils (which contains ich9gen) - not needed anymore
* code in lbmk for handling ich9gen and insertions; the
coreboot build system is now used, for this same purpose,
so remove such code from lbmk
this results in a massive code size reduction (thousands of
lines) in lbmk; smaller when only looking at the build
system, but much larger when you consider that ich9utils
is also removed (about 3k sloc)
Signed-off-by: Leah Rowe <leah@libreboot.org>
a follow-up patch will make use of these, rather than ich9gen,
and ich9gen will be deleted.
these files were in fact generated *by* ich9gen.
coreboot has ifdtool and bincfg, the latter of which can
generate both ifd and gbe files for ich9m. that, and nvmutil
which is part of libreboot, can change gbe mac addresses.
i was going to replace ich9gen with a script that would run
bincfg, ifdtool and nvmutil, to greatly reduce code size,
because ich9gen is about 3k sloc.
however, in practise we would always generate the same ifd
config, and basically only change the mac address if that's
what the user wants; nvmutil can already do that just fine.
so, just include the binaries directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the mkdir command in update/project/repo, added for
pico-pi integration, broke a bunch of other downloads.
the fix is a bit of a hack but it should hold for now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This was only tested on the iGPU model, though a dGPU model does exist.
The vendor firmware used a 16KiB gbe.bin, which was modified with a
random MAC address as well as shrinking it to 8KiB. As with the E6400,
GRUB doesn't like the way the EC implements the keyboard controller and
thus GRUB payloads are disabled at this time. Suspend does not currently
work, and this is believed to be due to the EC controlling the DRAM
reset gate which is required to prevent DRAM from being reset on resume.
With some tweaks, the e6400-flash-unlock utility also works on this
system, though both flash chips can be accessed through removal of only
the keyboard.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
More than 90% of cats were thus terminated.
read (shell built-in) is better at reading, and dogs are better pets.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
the way this script works, it only copies what was built,
but it currently operatios as though coreboot/default
always exists, and then cleans the kbc1126 util
this patch fixes such buggy behaviour
Signed-off-by: Leah Rowe <leah@libreboot.org>
The -c option is added for distclean, and -x for crossgcc-clean,
in handle/make/config
about 100 sloc removed from lbmk
Signed-off-by: Leah Rowe <leah@libreboot.org>
The -T option specifies how many threads xz shall use.
The -T value of zero shall dictate that xz use so many
threads as there are CPUs, on the host system.
This will probably speed up the release process a bit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i have in fact tested whether many of these targets (ivy,
sandy and haswell on intel) boot without microcode, and many
do, but it's not as well tested
the older targets like i945, x4x, pineview and gm45 are
well-tested without microcode; ditto fam10/15h amd.
lbmk supports providing roms with and/or without microcode.
for the targets touched in this commit, lbmk now only
provides images with microcode included by default.
manual removal (with cbfstool) is still possible, if you want
to do that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The same ROM images that you flash on Intel GPU variants,
are now flashed on Nvidia models. The same ROM will work
on both. If an Intel GPU variant is present, libgfxinit
is used, and the VGA ROM is used if an Nvidia GPU variant;
however, release ROMs will scrub the nvidia option ROM,
so release ROMs will only work on Intel GPUs unless you
run the blobutil inject command.
I decided to no longer have this under WIP, but to put
it in master. The issue with it pertains to video drivers,
which is not Libreboot's problem.
Nouveau crashes under Linux, so use "nomodeset" if it does.
The "nv" drivers in BSD systems work very well.
The nvidia model of E6400 isn't recommended for other
reasons, namely: poor thermal cooling (thermal pad on
the GPU) and that Nvidia GPU doesn't get very good
performance on any libre drivers anyway. The Intel GPU
variant is better, in terms of power efficiency and
software support; the intel variant also works with
native graphics initialisation in coreboot.
This board port already only enables SeaBIOS, which will
simply execute the VGA ROM. Blobutil already supports
reading the config, detecting that a VGA ROM is needed,
because that part of the WIP E6400 branch was already
merged in lbmk master.
Signed-off-by: Leah Rowe <leah@libreboot.org>
they weren't being copied back, after running the
make command. i overlooked this when testing in
the previous optimisations, because i only tested
building, not modification or updating of configs
Signed-off-by: Leah Rowe <leah@libreboot.org>
the current check only worked if it had already
been built, when checking for the Makefile
however, running this during build/release/src
caused problems, hence the current check
so: perform the same check, but as a fallback for
cmake failing (and if that check fails, only then
will err be called)
Signed-off-by: Leah Rowe <leah@libreboot.org>
lbmk never needed a makefile, because the build system
is all shell scripting; the former makefile simply called
those scripts, in a way that was mostly superfluous
build/release/src was still trying to copy it, so let's
remove it from that file
Signed-off-by: Leah Rowe <leah@libreboot.org>
it was previously trying to "continue", despite not being
inside a loop. the correct instruction would have
been "return 0", but then I thought it'd be better to
err here
Signed-off-by: Leah Rowe <leah@libreboot.org>
this means the unified /tmp handling is now provided for
in both the former "fetch" and "fetch_trees" script, which
are now (respectively):
./update project repo
./update project trees
if the fetch scripts weren't cleaning /tmp before, they
now are, because lbmk handles it
Signed-off-by: Leah Rowe <leah@libreboot.org>
export TMPDIR to scripts, and handle it in a way that
we know lbmk set it
delete it at the end of the parent process, but not child
processes; when the lbmk script calls itself, child processes
will not delete the tmp directory.
some scripts in lbmk weren't cleaning up the tmpfiles they
made, and they still don't, but this mitigates that.
now in follow-up commits, i can start cleaning up those
scripts too.
not handled by this patch:
if the user cancels lbmk (ctrl+c), the tmp directory will
still be there. this too will be handled, in subsequent
patches
Signed-off-by: Leah Rowe <leah@libreboot.org>
libreboot's build system, lbmk, *is* available to use
in releases aswell (use the _src tarball), but it is
mostly intended for development, in lbmk.git
well, there's not much point wasting time / disk space
generating no-microcode roms within lbmk
they should be generated only at release time, alongside
the default ones
this patch implements that, thus speeding up the build
process and saving disk usage during development
the other alternative was to add a new option in
build/boot/roms, -m, that would opt in to removing them,
but this is extra complexity for something that is ill
advised and only provided to appease certain people
Signed-off-by: Leah Rowe <leah@libreboot.org>
most of these steps do not need to be repeated, per image.
move it into handle/make/config, so that the steps are
performed on files that go under elf/coreboot (this will
save on build time).
the logic for handling 4MB ROM images on sandy/ivy was unused,
and has been removed.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the error messages that it shows are benign, but users
see them and worry that something went wrong
this patch reduces the number of people asking pointless
questions on irc
Signed-off-by: Leah Rowe <leah@libreboot.org>
new behaviour:
* grub.cfg and grubtest.cfg no longer inserted to cbfs
* grub.cfg in memdisk instead
* grub.cfg in memdisk defers to cbfs/grub.cfg if added
(not added by default, anymore)
* does not defer to grubtest.cfg even if available
* only shows link to grubtest.cfg if available,
as a menuentry item
keymaps:
if /keymap.gkb exists in cbfs, it uses that by default,
but by default this isn't added. instead, it looks for
a file named keymap.cfg and sources that, which then
sets the keymap to one that is located under memdisk.
this file is inserted for each rom, per layout.
if keymap.gkb and keymap.cfg both absent, grub.cfg in
memdisk shall defer to usqwerty as the default keymap
grub_scan_disk: grub.cfg looks for cbfs file "scan.cfg"
and sources that if found, which will be inserted with
the string: set grub_scandisk=setting_goes_here (based
on target.cfg, generated by build/boot/roms automatically).
If no scan.cfg is found, it defaults to "both"
The "background.png" file remains unchanged, and present in
CBFS, used by grub.cfg if present (and it is, by default)
This change actually *saves* space in CBFS, due to compression,
and means that the grub.cfg is now compressed heavily. This
is also safer, because now the user overrides grub.cfg by
adding it, and they can still add grubtest.cfg for testing
first. If they accidentally delete both configs from cbfs,
Libreboot will fall back to the one in memdisk which would
presumably not be deleted.
This also means that lbmk can now more easily be used by
other build systems, that just want the GRUB part to re-use
in their own project. For example, people who want to build
custom coreboot images without using Libreboot's build system.
This change also *speeds* up the build process considerably,
on the parts where ROM images are copied. It's less than half
a second now, whereas previously it took about 30-45 seconds
for ROM images to copy, because of grub.elf being re-added in
each ROM via cbfstool, where compression is used; I believe
the compression part is what caused slowness.
Much, much faster, more versatile builds.
Signed-off-by: Leah Rowe <leah@libreboot.org>
After that, do not allow anything to run if the user is
root. This logic flow is more robust, and reduces the
chance of bugs in the future.
We must not permit the user to run lbmk as root.
Running it as root *is* possible, by just removing
the check, and wily enough users will do that, but
this behaviour in lbmk is good practise because it
prevents accidentally running as root. If the user
went into root just for installing dependencies, they
might accidentally forget to switch back. This is a
safeguard against such folly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was an oversight, in a previous commit.
there was a space, between variable name and
the equals sign, and then another space, so it
was trying to *execute* the rom
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was an oversight on my part. the script cannot be
run as root, except to install distro dependencies e.g.:
as root: ./build dependencies debian
however, ./checkgit was being run *before* checking that,
making it required to set git config as root.
this patch fixes that bug.
Signed-off-by: Leah Rowe <leah@libreboot.org>
lbmk's new style is inspired by the bsd coding styles:
top-down logic, main simplified to a skeleton showing
overall program structure, variables well-defined,
rigorous (yet deceptively simple) error checking.
this was attempted before, but caused problems; coreboot
wasn't being cleaned properly, and rather than audit it,
i simply reverted this back to the old style.
this is actually attempt number 5, because i made 3 more
attempts between then and this one. i've build-tested this
using "./build boot roms all" (which is what b0rked on
the first attempt, months ago). it should be stable(tm).
the code is much nicer to read / work on now. this is the
beating heart of lbmk. get this script wrong, and you break
all of libreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
With this change, about 54KB of compressed space is saved
inside of CBFS, on setups that use the GRUB payload.
The uncompressed saving is about 720KB, but payloads are
compressed inside each coreboot image, so the compressed
saving is much smaller. That 54KB saving means a lot,
especially on small (1MB or smaller) flash sizes.
The following modules were removed:
adler32, afsplitter, aout, archelp, backtrace, blocklist,
bswap_test, cat, cmdline_cat_test, cmosdump, cmostest, cmp,
cmp_test, cpuid, cs5536, ctz_test, date, datehook, datetime,
disk, diskfilter, div, div_test, dm_nv, efiemu, eval,
exfctest, extcmd, file, fshelp, functional_test, gdb,
gettext, gptsync, hashsum, hdparm, hello, hfspluscomp, http,
json, json, ldm, loadenv, macbless, macho, mda_text, morse,
mpi, msdospart, mul_test, net, ntfscomp, offsetio,
part_acorn, part_amiga, part_apple, part_dvh, part_plan,
part_sun, part_sunpc, parttool, pbkdf2, pbkdf2_test, pci,
play, priority_queue, probe, progress, random, rdmsr, read,
relocator, setjmp, setjmp_test, shift_test, signature_test,
sleep, sleep_test, smbios, strtoull_test, terminal,
terminfo, test_blockarg, testload, testspeed, tftp, tga,
time, tr, trig, usbtest, video_bochs, video_cirrus,
videoinfo, videotest, videotest_checksum, wrmsr, xnu_uuid,
xnu_uuid_test
These were retained, but moved to modules instead of
install modules:
geli, udf, ufs1, ufs1_be, ufs2
Signed-off-by: Leah Rowe <leah@libreboot.org>
the way the old script worked was extremely hacky
it's cleaner just to make the user configure git
i haven't used anything from the old .gitcheck script,
which is now deleted. i completely re-wrote this, in
a much simpler way.
this is less maintenance now, when things change in
the upstream projects. coreboot makes heavy use of git
within its build system
Signed-off-by: Leah Rowe <leah@libreboot.org>
and only where grub was already enabled; on boards
that did not enable grub, grub is still disabled
on desktops, it's possible that the user may insert
a graphics card. if their first payload was grub,
it won't work because lbmk doesn't configure coreboot
itself to execute vga roms at present
i found when testing t1650 (dell) that if a vgarom is
loaded from seabios (from a graphics card), the grub
payload still works; if booting in corebootfb mode,
text mode is still used when booting with the card
to decrease the probability of bricks with any given
set of users, make seabios the only payload that starts
first, but make grub available in the esc menu on seabios
it's possible to add a bootorder file and disable the
seabios menu, if you only want a grub payload accessible
Signed-off-by: Leah Rowe <leah@libreboot.org>
e.g. ./build boot roms list
./update blobs inject listboards
./build boot list
./build clean list
also this is now possible:
./build list
or maybe
./update list
^ would list directories in resources/scripts/build
and resources/scripts/update respectively
this script is added:
resources/scripts/build/command/options
call it like so, e.g.
./build command options resources/coreboot
this script is now used, for list functions in
other scripts.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we don't use it in lbmk. it's there mostly because
it was technically feasible, and it still is
however, i've been doing massive re-factoring of
lbmk and the makefile and i just don't feel like
constantly patching up the makefile
if someone wants to re-add it, that's fine. but i
don't see the point in maintaining something that
we don't need.
the makefile is not needed. all it did was call
lbmk directly. the makefile had no logic itself.
Signed-off-by: Leah Rowe <leah@libreboot.org>
lbmk is much more likely to crash now, in error conditions,
which is a boon for further auditing.
also: in "fetch", remove the downloaded program
if fail() was called.
this would also be done for gnulib, when downloading
grub, but done in such a way that gnulib goes first.
where calls to err write "ERROR" in the string, they
no longer say "ERROR" because the "err" function itself
now does that automatically.
also: listmodes/listoptions (in "lbmk") now reports an
error if no scripts and/or directories are found.
also: where a warning is given, but not an error, i've
gone through in some places and redirected the output
to stderr, not stdout
as part of error checks: running anything as root, except
for the "./build dependencies *" commands, is no longer
permitted and lbmk will throw an error
mrc downloads: debugfs output no longer redirected to /dev/null,
and stderr no longer redirected to stdout. everything is verbose.
certain non-error states are also more verbose. for example,
patch_rom in blobs/inject will now state when injection succeeds
certain actual errors(bugs) were fixed:
for example, build/release/roms now correctly prepares the blobs
hash files for a given target, containing only the files and
checksums in the list. Previously, a printf message was included.
Now, with this new code: blobutil/inject rightly verifies hashes.
doing all of this in one giant patch is cleaner
than 100 patches changing each file. even this is yet part
of a much larger audit going on in the Libreboot project.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the user may have re-downloaded a coreboot tree,
in a release. this is supported. therefore, some
may have .git, and some will not
Signed-off-by: Leah Rowe <leah@libreboot.org>
we also run it in releases, so to compensate:
it now checks for .git/, but only in project
directories, not the main lbmk directory of
the git repository or a release.
this is because in a release, it's possible
that the user may still delete coreboot/
directories and re-download coreboot trees
this is not intended, but we must not assume
that users use libreboot the way it's intended!
"much stricter" because there was previously
none, intentionally, due to the above fact. the
checking of .git/ should mitigate this (the
script will exit with zero status if it isn't
there)
Signed-off-by: Leah Rowe <leah@libreboot.org>
there were stragglers left over from the last audit,
and these stragglers still exist even after all the
major re-factoring as of late
the new style is: bsd-like coding style and error
handling. verbose yet simple error handling. we use
an "err" function in a way reminiscent of most C
programs that you see in openbsd base (err.h)
this style is very clean, resulting in readable code
Signed-off-by: Leah Rowe <leah@libreboot.org>
this same change has been applied, selectively, to
certain return statements. the general rule is this:
the return statement should only be used to direct
logic within a script, where certain non-errors
states are used to skip certain actions; the exit
command should *never* be used to return non-zero,
except by err(). in so doing, we ensure easier
debugging of the build system
also: strip_rom_image in build/release/roms was
running "continue" when a rom file didn't exist,
despite not being a while/for loop. i make it
return (non-error condition) instead
it's ok for a script to exit 0, where appropriate,
but perhaps a function could also be written for it
Signed-off-by: Leah Rowe <leah@libreboot.org>
moving it defeats the purpose of the caching mechanism
that's in place. this should avoid unnecessary downloads
Signed-off-by: Leah Rowe <leah@libreboot.org>
u-boot and seabios are now handled by the same logic
as coreboot, in lbmk, and these files are used for
recursive downloads in the build system
Signed-off-by: Leah Rowe <leah@libreboot.org>
uses 32-bit variant for x86_32 arch. 64-bit for x86_64.
resources/scripts/build/src/for:
modified it a bit. when building e.g. "memtest86plus/build32"
it correctly fetches "memtest86plus" instead.
but builds memtest86plus/build32, which is inside that git repo
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
in update/blobs/download, i saw instances where
appdir was being deleted with rm -r, but the more
appropriate command would rm -Rf. this is now fixed.
other than that, i've mostly just simplified a bunch
of if statements and consolidated some duplicated
logic (e.g. if/else block for dependencies in
build_dependencies() of update/blobs/download
one or two functions and/or variables have been
renamed, for greater clarity in the code, also
removed a few messages that were redundant
used printf instead of echo, in a few places, also
fixed up the indentation in a few places
Signed-off-by: Leah Rowe <leah@libreboot.org>
they fundamentally perform the same action: copy
the .config file and run make, but build runs
make-all, while modify runs make-oldconfig or
make-menuconfig
merge this functionality together
also:
./handle config file
^ this is the new syntax, not:
./build defconfig for
for example:
./handle config file -b coreboot x200_8mb <-- build x200 rom
./handle config file -m coreboot x200_8mb <-- modify configs
./handle config file -u coreboot x200_8mb <-- make-oldconfig
./handle config file -u seabios
./handle config file -b u-boot
yes, 1 script and a sloccount reduction of 52. and the audit?
it continues.
Signed-off-by: Leah Rowe <leah@libreboot.org>
thanks Riku Viitanen for pointing out the bug
i b0rked it myself in an earlier revision, while
auditing.
it's funny because i made this exact same mistake
during the last audit, and in the exact same way
it's fixed once again
Signed-off-by: Leah Rowe <leah@libreboot.org>
the unified logic is so small that i simply added it
to the main "build" script
commands are identical. example:
./build dependencies debian
Signed-off-by: Leah Rowe <leah@libreboot.org>
handle it all in the 1 script
quite a few clean scripts are still present,
so resources/scripts/build/clean/ still exists.
23 sloc reduction.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Some of them weren't even used at all, such as the flashrom
build script. the bios_extract build script existed but was
never used, because we only called (from blobutil) a python
script from in there, without actually compiling anything!
resources/script/build/src/for
Usage, e.g.:
./build src for memtest86plus
It also handles fetch. This script is intended largely for
those codebases that are quite simple, requiring trivial
or no intervention besides running "make".
37 sloc reduction. Not a lot, but the audit continues! These
optimisations add up. I started at 3300 sloc in
resources/scripts and me target is 2k (2000) sloc.
Signed-off-by: Leah Rowe <leah@libreboot.org>
new commands are thus,
build grub payloads:
./build grub payload
(formerly ./build payload grub)
build grub utils:
./build grub utils
(formerly ./build module grub)
The scripts is build/module/ will mostly be
deleted. I say mostly, because some of them
are being moved instead.
The deleted ones will be ones that basically
just run "make" in the target directory. They
will be unified, in a follow-up patch.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Patches pulled from:
https://git.nicholasjohnson.ch/grub
This is the author of the rebased patches:
https://nicholasjohnson.ch/
(Nicholas Johnson <nick@nicholasjohnson.ch>)
However, this is a *rebase* performed by Nicholas,
based on these patches:
https://aur.archlinux.org/cgit/aur.git/tree/?h=grub-improved-luks2-git
...at revision: 1c7932d90f1f62d0fd5485c5eb8ad79fa4c2f50d
The AUR patches were based on GRUB 2.06, whereas Nicholas's
rebase is upon grub 2.12, which Libreboot currently uses.
These patches import the PHC implementation of argon2i/id
key derivation functions, seen here:
https://github.com/P-H-C/phc-winner-argon2
GRUB (upstream) does not merge these patches and probably won't,
because even though they're libre, they're not copylefted or
otherwise under GPL terms that GRUB can accept.
Therefore, we in Libreboot must maintain these from now on,
for our version of GRUB. The upshot? LUKSv2 decryption should
now work, perfectly, in GRUB!
Signed-off-by: Leah Rowe <leah@libreboot.org>
17 commits above 2.12-rc1, with some fixes.
i'm about to merge luks2 argon2 patches in a
follow-up commit, and they're based upon this
revision of grub
Signed-off-by: Leah Rowe <leah@libreboot.org>
./update seabios configs? gone
.modify coreboot configs? gone
it's now all 1 script, called e.g.
./modify defconfig options -u coreboot <-- runs make oldconfig
./modify defconfig options -m seabios <-- runs make menuconfig
./modify defconfig options -u u-boot gru_bob <-- oldconfig, and only gru_bob
./modify defconfig options -u coreboot x60 x200_8mb
etc. you get the idea. same behaviour as before with all
the separate scripts, but now its one unified script.
184 sloc reduction in resources/scripts/
Signed-off-by: Leah Rowe <leah@libreboot.org>
x86 u-boot is a bit flaky and this board never builds.
re-add it ot a later date.
u-boot is only really used in arm machines,
for our purposes at least.
Signed-off-by: Leah Rowe <leah@libreboot.org>
See file:
resources/scripts/build/defconfig/for
It is based on:
resources/scripts/build/payload/u-boot
The u-boot payload script has been deleted, as has the
seabios payload script; the build/boot/roms logic has
been heavily simplified too, by removing the logic for
building of elf files based on defconfig.
SeaBIOS, U-Boot and coreboot all use defconfig-type
infrastructure for their build systems, and they are
fundamentally the *same* in how to compile each codebase,
at least in an lbmk context, regardless of actual (and
very huge) differences in these codebases.
Several hundred sources-lines of code have been eliminated
by this change, drastically simplifying everything; U-Boot
payload compiling also now errors out when a single build
fails, instead of continuing. Also: build/boot/roms no longer
re-compiles a coreboot target that was already compiled,
which is the same behaviour observed for payloads.
(this means you must now manually delete a target, when you
wish to re-build it; the build/boot/roms logic now more or
less just runs cbfstool; blobutil is handled from
build/defconfig/for)
ALSO: Since crossgcc is now handled by build/defconfig/for, not
build/boot/roms, standalone compiling of u-boot is now possible.
This has been tested. You compile it like so:
./build defconfig for u-boot
or specific trees, e.g.
./build defconfig for u-boot default
One other consequence of this patch is that re-building the same
ROM image is now much faster, because the same builds are re-used
unless deleted. This could be useful when testing grub.cfg changes,
for example, if that's all you change. With things like ccache used
(not yet used robustly in lbmk), this could speed things up more,
depending on the codebase.
This patch demonstrates the raw power of lbmk; it is a very
simple and highly efficient build system, and now much more so!
Signed-off-by: Leah Rowe <leah@libreboot.org>
With newer hostcc, trying to build GCC 8.3.0 will raise an error from ld:
undefined reference to `__gnat_begin_handler_v1'
This commit adds a patch for GCC found on coreboot [1] correcting this
error by backporting the GNAT exception handler v1 to GCC 8.3.0 allowing
GNAT to be built with newer hostcc like GCC 10+.
[1]https://review.coreboot.org/c/coreboot/+/42158
Signed-off-by: Adrien 'neox' Bourmault <neox@gnu.org>
Acked-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
it's bloat, and was only there for backwards compatibility
with the old commands, but the new commands are e.g.
./update blobs inject
instead of:
./blobutil inject
this results in a slight code size reduction in lbmk
Signed-off-by: Leah Rowe <leah@libreboot.org>
most of them were just calling the gitclone script,
so remove them.
the grub script was treating gnulib as a dependency.
i've now added the ability to grab 1 dependency, in
the gitclone script (it should be expanded later to
support multiple dependencies)
the gitclone script has been renamed to "fetch".
the "fetch_trees" script does more or less the same
thing, but calls "fetch" and handles multiple revisions
if a project needs that
this is more efficient, and slightly reduces the code
size of lbmk!
Signed-off-by: Leah Rowe <leah@libreboot.org>
make it output messages that tell the user important
information. it's only subtle but it makes a difference
to some people, who need confirmation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
they are fundamentally the same, in an lbmk context.
they are downloaded in the same way, and compiled in
the same way!
(Kconfig infrastructure, board-specific code, the way
submodules are used in git, etc)
~200 sloc reduction in resources/scripts
the audit begins
Signed-off-by: Leah Rowe <leah@libreboot.org>
Very nice ivybridge board that supports ECC RAM.
NOTE: I couldn't get onboard graphics working yet, but
this was confirmed working with a graphics card (in my
case nvidia quadra k420) booted in text mode on the SeaBIOS
payload. The GRUB payload also works, when loaded from SeaBIOS.
Therefore, this is a SeaBIOS-only board (as far as first payload
is concerned), but you can pick GRUB from the menu.
You could make it "GRUB-only" in practise by setting SeaBIOS
boot order to only load GRUB, and disable the SeaBIOS menu.
We refer to this as "SeaGRUB".
I've made lbmk use biosutilities and uefiextract, to
get at the SMSC SCH5545 Environmental Control (EC) firmware.
This firmware is needed for fan control. This is automatically
downloaded and extracted, from Dell UEFI firmware updates.
As with other blobs such as Intel ME, this firmware is then
scrubbed by the release build scripts. The blobutil "inject"
script can be used to re-insert it.
Of note: there is no fixed offset, but no other blobs to
be inserted in CBFS either, so the offset when re-inserting
on release ROMs should still be the same, and thus the ROM
checksums should match, when running blobutil inject.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this revision:
1281e340ad1d90c0cc8e8d902bb34f1871eb48cf
from 30 May 2023
It contains a few nice fixs, including an integer
overflow fix, but not many changes have been made
to seabios since the last revision.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is specifically the following Git revision:
7a994c87f571ac99745645be0bdde9827297321a
from 10 July 2023
The keyboard fix for HP EliteBooks was merged upstream,
so lbmk no longer needs this patch; it comes with GRUB.
Signed-off-by: Leah Rowe <leah@libreboot.org>
coreboot revision:
d86260a134575b083f35103e1cd5c7c7ad883bce
from 2 August 2023
The patches were updated. HP 8300 USDT has now been merged upstream,
so that patch is no longer included in lbmk.
SD card fix for E6400 merged upstream, so now it's removed in lbmk.
The nvidia E6400 patch (devicetree.cb) has not yet merged upstream.
The ifdtool --nuke option has been rebased.
Patches as follow-ups to earlier patches removed; for example, patches
that set VRAM to 352MB on GM45 have been removed, and replaced with
patches that just set 256MB in the first place (this is more stable).
This was mostly a clean rebase, of all the patches. It went smooth.
I haven't updated cros/haswell yet; the 4.11_branch revision used
on fam15h will also remain, for now.
The coreboot configurations have been updated, for this new
revision of coreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
blobdir is incorrect, and it means that the directory
will appear under blobs/, in this case. this was an
oversight on my part.
this behaviour did not break anything in practise, but
this patch makes the behaviour more consistent with rules.
Signed-off-by: Leah Rowe <leah@libreboot.org>
At present, the logic only tries backup URLs when an
actual download fails (bad internet connection or the
server is down).
If the main download succeeds, but it has a bad checksum,
the backup download is not attempted.
Since wrongly hashed files are to be assumed useless, we
may aswell delete and try the next file. This will guard
against the possibility of a vendor changing their file,
without changing the file name (non-versioned files, for
example, may be subject to such changes).
Signed-off-by: Leah Rowe <leah@libreboot.org>
ME extraction didn't support unar (RAR format), for regular
extraction, after downloading a vendor file.
For bruteforce ME extraction, after extracting a vendor
archive, unar(RAR) and inno(innoextract) was not supported.
This patch fixes both issues. It should be noted that as of
now, the unar method has only been tested with certain HP
vendor updates, and it's currently not used on any of those.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Immediately after the last revision, which was a hacky
workaround to the problem, I realised the actual problem,
and the real solution:
In the switch block, check *backup* first. Then it breaks,
continuing on the iteration.
If it's variable for a main URL, it'll reliably go to the
next check in the block, whereas if it's backup, it'll
default to the first one in each case.
This bug has been annoying the sh*t out of me for ages,
and I've finally nailed it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The script was actually downloading the backup, at
all times, for each given URL. The way we handle
this is quite buggy.
This patch is a workaround, a dirty hack in fact, but
it will do for now, because our backup URLs are always
wayback links where the original URL (matching the
correct main URL in the sources file) is always present,
in the URL.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Make it look like a normal web browser, downloading files.
Some HTTP servers might block Wget unless this is done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This was an oversight on my part.
Should extraction fail, we must abort. This is in preparation
for addition of future mainboards, where further tweaking is
required in blobutil. This error check will warn us about it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 7c90a4077f.
causes another build bug. i'm helping someone with the bug now,
i think the workaround for now would be to just use bash, on
this script. until i can figure something better out.
they were outside the scope, outside of the if statements.
in some shells, this is ok.
we use "sh" so the user could have any shell.
be a bit nicer to the more asininely technically
correct sh implementations out there
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was taken from old libreboot. the last libreboot
revisions that had these boards were under the old
policy.
i left microcode disabled at first, because the old
coreboot 4.11 behaviour was to always insert microcode
regardless, so old libreboot patched out microcode
from the coreboot build system
however, 4.11_branch appears to actually honour microcode
configuration, so i do actually need to make sure it's
enabled in configs
Signed-off-by: Leah Rowe <leah@libreboot.org>
the upstream link died. this patch makes it grab the
acpica tarball (for iasl) via libreboot rsync, where
i've added the corresponding tarball
Signed-off-by: Leah Rowe <leah@libreboot.org>
Libreboot 20220710 was the last release to support these
boards. I plan to eventually port code differences between
D8/D16 to Dasharo, for KCMA-D8 support in Dasharo, to then
use in Libreboot for both KCMA-D8 and KGPE-D16, but I have
no plans to update the KFSN4-DRE code, at least for now.
Libreboot 20220710 used coreboot 4.11, whereas this patch
makes use of coreboot 4.11_branch; the crossgcc toolchains
no longer compile on modern distros, so I spent time patching
those (tested in Debian Sid, will also work on Arch Linux and
so on).
The acpica downloads now fail, in 4.11_branch, because Intel
made some changes upstream for these tarball downloads. Newer
coreboot works around this by grabbing tarballs from github,
itself a non-ideal solution, but I digress; this patch changes
coreboot crossgcc (in 4.11_branch) to download the acpica
tarball from libreboot rsync, where I've added it.
This patch also re-introduces the PIKE2008 fix, where empty
option ROMs for these are inserted into CBFS. This prevents
SeaBIOS from loading the real option ROMs, which would cause
SeaBIOS to hang. This means that SAS drives are not supported
in SeaBIOS, for these boards in Libreboot.
I previously said, in the Censored Libreboot c20230710
announcement, that I would *only* merge D8/D16 when I've
added Dasharo support to Libreboot, and use that, but the
work to make coreboot 4.11_branch compile is something I'm
quite proud of and I see no reason to exclude from lbmk
master branch.
Honestly, there's not much different than 4.11, code-wise.
I *probably* won't use 4.11_branch for the next Libreboot
release, on D8/D16. By then, I might have Dasharo integrated
in lbmk instead. We shall see.
Signed-off-by: Leah Rowe <leah@libreboot.org>
upstream died. i put the corresponding tarball on
libreboot rsync. this is used by the coreboot build
system, specifically in crossgcc (cross compilers)
Signed-off-by: Leah Rowe <leah@libreboot.org>
This error was observed, in the coreboot build system:
In file included from src/lib/version.c:4:
build/build.h:10:32: error: 'libreboot' undeclared here (not in a function)
10 | #define COREBOOT_MAJOR_VERSION libreboot-20230625
| ^~~~~~~~~
src/lib/version.c:35:46: note: in expansion of macro 'COREBOOT_MAJOR_VERSION'
35 | const unsigned int coreboot_major_revision = COREBOOT_MAJOR_VERSION;
| ^~~~~~~~~~~~~~~~~~~~~~
This happened on the 20230625 *release archive*, when a user tried to
build for W541 MRC on an Arch Linux container.
This change fixes the error. I never got the error on my end when
build testing the release archives, but this will prevent the error.
Fix it by only inserting libreboot version string YYYYMMDD representing
the Libreboot version. (libreboot uses ISO dates as version numbers)
Signed-off-by: Leah Rowe <leah@libreboot.org>
I keep getting random linker issues when running:
./build boot roms all
I think the issue lies somewhere in here, from when
I did that massive audit. So I'm undoing the audit
which mostly re-factored the code style here.
These changes are being backported:
f338697b build/boot/roms: Support removing microcode
941fbcb run coreboot utils from own directory
f256ce98 build/boot/roms: say board name on stderr
I removed this change:
6d6bd5ee (the script now uses dedicated utils directory)
additionally:
cbutils is built much earlier on in the script, first
thing after initialising variables
the other changes not backported are all code style
changes, and I believe these are responsible.
if no other fixes occur to this fire before the next
libreboot release, then my hunch was right.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 2099545078.
Wasn't this config's fault, the problem happens elsewhere too.
I'm going to revert build/boot/roms to an older version and backport
a few recent changes, to see if that fixes the problem. If it does,
then I know that the recent linker issues happen due to recent changes
in build/boot/roms
The linker errors typically appear in util/kconfig/ but can happen
elsewhere, seemingly random, which means I'm not handling distclean
properly. Something isn't getting cleaned properly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
That way, I can more easily debug build issues with
specific boards, e.g.
./build boot roms all 2>lbmk.err.log
Signed-off-by: Leah Rowe <leah@libreboot.org>
I don't know why, but removing this BL31 make argument lets gru-kevin
power off properly when shut down from Linux. Needs investigation.
Do it as a cros-only HACK patch so people don't have to hold the power
button after every shutdown.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Debian's signed shim allocates too many EFI variables to fit in the EFI
variable memory buffer. Normally it would then try to continue booting
in non-secure-boot mode, but its error handling throws a synchronous
abort that reboots the board, making it impossible to boot into Debian
unless one manually loads GRUB instead of shim. Increase EFI variable
buffer size to avoid triggering the bug.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
turns out it's just picky ram.
errant reports of "no boot" (users did not have debug
dongles) were likely "bad" ram
notes will be written on libreboot.org about this
Signed-off-by: Leah Rowe <leah@libreboot.org>
not well-tested, and existing testing has revealed video
issues on some of them (or just no boot)
for now, retain only qemu and gru-* on arm
Signed-off-by: Leah Rowe <leah@libreboot.org>
fixes ./build boot roms all
in detect_firmware(), "set" is used to get values from
configs, to know if things like ME/MRC are needed
on some "board" configs under resources/coreboot/, no
actual coreboot configs are provided, because they are
used as a reference (coreboot revision, tree name etc)
for actual boards, with actual coreboot configs
when attempting to build for such a board, running "set"
on such non-existent files would cause a non-zero exit,
when we want zero. the non-zero exit then caused the
build/boot/roms command to fail, when running "all" if
it found, for example, resources/coreboot/cros/ which
has the above problem, in this context
work around it by verifying that coreboot configs exist
for the given target name, in the blobutil download script.
if no such configs exist, then exit zero (success)
doing so is correct, because the script is intended to
do just that, erroring only if it is detected that blobs
are needed for a given board, but other errors occur; if
no coreboot configs exist, then no roms will be built and,
therefore, no blobs are needed
Signed-off-by: Leah Rowe <leah@libreboot.org>
script is -e anyway, so this is redundant, but best
put it here anyway. it can only help. correct behaviour
is always to fail on error, except in certain cases that
would be handled on a case-by-case basis in each script
From now on, the following rules are available for all
mainboards, in resources/coreboot/boardname/board.cfg:
* blobs_required="n" or "y"
* microcode_required="n" or "y"
The blobs setting, if set to "n", simply renames filename.rom to
filename_noblobs.rom.
The microcode setting, if set to "n", copies the ROM (with or
without _noblobs) to filename_nomicrocode.rom (if blobs="n",
it would be filename_noblobs_nomicrocode.rom).
Where "nomicrocode" is set, ROMs with microcode will still be
provided by lbmk and in relesase, but ROMs will also be provided
alongside it that lacks any microcode updates.
If the *original* ROM already lacks microcode updates, then the
original ROM will be *renamed* to include "nomicrocode" in the name.
This is done on images for ARM platforms, for instance, where
microcode is never used whatsoever.
Example filenames now generated:
seabios_e6400_4mb_libgfxinit_corebootfb_noblobs_nomicrocode.rom
seabios_e6400_4mb_libgfxinit_corebootfb_noblobs.rom
seabios_withgrub_hp8300usdt_16mb_libgfxinit_corebootfb_colemak_nomicrocode.rom
seabios_withgrub_hp8300usdt_16mb_libgfxinit_corebootfb_colemak.rom
uboot_payload_gru_kevin_libgfxinit_corebootfb_noblobs_nomicrocode.rom
A vocal minority of people were not happy with some of the changes
made in Libreboot last year, including on existing supported
hardware from before those changes were made. I did this before the
last release, out of respect:
https://libreboot.org/news/gm45microcode.html
(re-add mitigations for no-microcode setup on GM45)
This new change is done as an further, extended courtesy. Tested
and works fine. (testing using cbfstool-print)
Actual Libreboot policy about binary blobs is nuanced. See:
https://libreboot.org/news/policy.html (reduction policy) and:
https://libreboot.org/freedom-status.html (implementation)
Well, the status page talks about descriptor vs non-descriptor
on Intel platforms, and where me_cleaner is used (on platforms
that need Intel ME firmware), it regards the descriptored setups
to be blob-free if coreboot does not require binary blobs.
In this paradigm, microcode updates are not considered to be
binary blobs, because they aren't technically software, they're
more like config files that just turn certain features on or off
within the CPU.
However, for lbmk purposes, "noblobs" means that, after the ROM
is fully ready to flash on the chip, there will be no blobs in
it (except microcode). So for example, an X200 that does not
require ME firmware is considered blob-free under this paradigm,
even though Libreboot policy regards X230 as equally libre when
me_cleaner is used; in this setup, ROMs will not contain "blobfree"
in the filename, for X230 (as one example).
Signed-off-by: Leah Rowe <leah@libreboot.org>
Since many boards use the same ME firmware, we could save
everyone's bandwidth and time by caching the update files.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Still on Gerrit. ME downloader failed with HP update file, so let's just
use Lenovo's instead. Both contain identical ME8_5M_Production.bin files.
Tested and working:
* Native raminit with both DIMMs
* Libgfxinit textmode and framebuffer on both DisplayPorts and VGA
* External USB2 and USB3 ports: they all work
* USB 3.0 SuperSpeed (rear, 4 ports)
* Ethernet
* Mini-PCIe WLAN
* SATA: 2.5" SSD and optical drive bay
* SeaBIOS and GRUB (boot to linux)
* PS/2 keyboard and mouse
* S3 suspend and resume, wake using USB keyboard
* Headphone output, line out, internal speaker
* Wake on LAN
* Rebooting
* CMOS options & nvramcui
Untested:
* Line in, mic input
* MXM graphics card
* EHCI debug
Not working:
* Mini-PCIe USB: I couldn't get it working on vendor BIOS either, so
maybe it just isn't present
* PS/2 keyboard wake from S3
* mSATA (I have no mSATA drives)
Tested with Johan Ehnberg (johan@molnix.com)
The following is tested and confirmed working:
- backlight control
- touchpad
- USB (external, smart card, fingerprint, bluetooth, webcam, WWAN)
- touchpad
- Wi-Fi
- 2,5" SATA
- USB 3.0
- SD card
- Memory: 2+2 (matched or unmatched), 8+2, 8+8
- internal flashing from libreboot
- SeaBIOS and GRUB payloads
- Boots Devuan and Ubuntu
Untested:
- ExpressCard
- DVD
- dock
- external displays
- eSATA
- trackpoint (not present on this aftermarket keyboard)
the loop in main() already checks EOF, and errno is
properly handled at the end of main()
we only need to call ferror(), to check error state
this fixes a bogus error message when pressing ctrl+D
to terminate the program, *which is the intended way
to terminate this program* (that, or EOF is reached
in any other another way)
do not treat intended behaviour as an error condition!
Signed-off-by: Leah Rowe <leah@libreboot.org>
i've build-tested this code with clang and that also
works. in practise, a user is going to have clang or gcc
Signed-off-by: Leah Rowe <leah@libreboot.org>
make it more obvious that this *is* a ring buffer being
handled, and make it more obvious when checking a pulse
in the next frame
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit a4ea286731.
The licensing audit has been abandoned. I will not be re-licensing
in bulk to MIT.
I can still use MIT license on new works, e.g. utilities, but there's
really no pressing need to re-license lbmk. It's just shell scripts,
and most of what it interacts with (coreboot, grub, seabios) is GPL
anyway.
So who cares?
Ferass's patch was removed due to refusal to re-license, but the
decision to re-license has been canceled.
I'm now aiming for a quick stable release.
This fixes the PCI interrupt routing tables for the E6400 so that the SD
card works. It is already merged in upstream but libreboot has not yet
updated coreboot.
- A spurious semicolon caused the arguments to printf in die() to be
executed instead of printed
- ${@} in die() needs to be in quotes or else printf prints each word on
a separate line
- The number of arguments to main() does not include main itself so it
should be comparing against 1 instead of 2 to determine if enough
arguments were supplied.
i forked spkmodem-recv from coreboot, who forked it from
gnu grub. gnu grub's version has the full header, with
copyright declared as belonging to the fsf
coreboot made changes after forking it, and later replaced
the license declaration with an equivalent SPDX header, but
they also removed the FSF's copyright declaration, which by
itself does not void the declaration
anyway, i just feel better re-adding the full declaration.
make it so!
Signed-off-by: Leah Rowe <leah@libreboot.org>
there's no point passing it as argument to a
function. it's used across more than one function,
so make it global
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's currently a build-time option
make it a runtime option instead, so that every
user can optionally make use of it, on all builds
Signed-off-by: Leah Rowe <leah@libreboot.org>
thus, there's no need to handle flushing of stdout
whatsoever, and the code can be greatly simplified
ascii bits are still reset, when no input on stdin
is given
Signed-off-by: Leah Rowe <leah@libreboot.org>
when spkmodem-recv doesn't receive anything (via stdout)
after a few frames, it's assumed that the console is dead
and the buffered output is flushed
this logic is assumed superfluous when -u is set
Signed-off-by: Leah Rowe <leah@libreboot.org>
my style was: 2 tabs. bsd-style, for extending a line, is
4 spaces. this style has grown on me, so let's do it here
Signed-off-by: Leah Rowe <leah@libreboot.org>
my style of C programming is this: always return errno
upon exit from the program, or from a thread.
handle errno in the calling/forking function.
returning errno at the end of main has this intention:
if an unhandled error occured, the program exits with
non-zero status.
a correctly written program should *never* return non-zero
at the end of main, and if it does, this indicates a bug
in the code (per my code style / philosophy).
so, warn the user with a message if this occurs. the
intention is that this message should never be printed.
do not use assert() for this. i don't believe in that.
such a test should always be present, for everyone.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This version of spkmodem uses err() to indicate an error,
and the value of errno is used as exit status at all times,
even when it is zero.
When calling err(), it is intended that errno always be
non-zero, so modify the code accordingly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
when calling fread(), errno may be set to EOVEFLOW if
the range being read will cause an integer overflow
if end-of-file is reached, errno may not be set. when
calling this function, you must check errno or check
feof() - ferror() should also be checked, so this check
is added immediately afterwards in the code
ferror() does not set errno, so ERR() is used to set
errno to ECANCELED as program exit status
further separate reading of frames into a new function
Signed-off-by: Leah Rowe <leah@libreboot.org>
The mentality behind pledge and unveil is that you should
think ahead, so that large parts of code can run under
extremely tight restrictions.
The pledge calls have been adjusted accordingly, also.
Disallow all unveil calls after the gbe file and the
file /dev/urandom have been unveiled.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This replaces a check in the function for O_RDONLY, and
fixes the bug where the "dump" command triggers such error.
Signed-off-by: Leah Rowe <leah@libreboot.org>
*Open* files at the start, then unveil. The same overall
behaviour is observed. In the case that invalid arguments
are given, simply opening a file does not cause much
performance impact (if any).
Restrict operations as early as possible in code.
Bonus:
writeGbeFile also hardened; if flags is O_RDONLY, it aborts.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i screwed up in an earlier commit
this change fixes a bug where on rhex(), each
call would re-open /dev/urandom, resetting rfd
Signed-off-by: Leah Rowe <leah@libreboot.org>
in practise, the file was never written unless the checksum
was valid, but in the same of sloccount reduction i made it
do the swap/copy before checking. while functionally ok, it
never sat right with me. this is one example of where sloc
count doesn't mean everything. code correctness is critical
Signed-off-by: Leah Rowe <leah@libreboot.org>
the style was already quite similar, but extended lines in
bsd are indented by 4 spaces instead of a tab. this style
has grown on me, so i'm adopting it here
Signed-off-by: Leah Rowe <leah@libreboot.org>
They don't precisely *pertain* to nvmutil, but they are
useful helper functions for calling pledge/unveil in
OpenBSD. Ideally, the main file should only contain core
logic pertaining to the execution of *nvmutil*.
Put xpledge() and xunveil() in nvmutil.h.
Signed-off-by: Leah Rowe <leah@libreboot.org>
When err() is called, it is intended that nvmutil will
always exit with non-zero status, but with errno as the
return value. Ensure that errno is *not* zero.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Make word() a macro, simplify err_if().
Could also make setWord() a macro if I forego certain
optimisations, but I'll leave it as-is.
Signed-off-by: Leah Rowe <leah@libreboot.org>
After /dev/urandom (for MAC address randomisation) and
the GbE file have been handled, unveil them. Unveil is
a system call provided by OpenBSD that, when called,
restricts access only to the files and/or directories
specified, each given specific permissions.
You can learn more about unveil here:
https://man.openbsd.org/unveil.2
An ifdef rule makes nvmutil only use unveil on OpenBSD,
because it's not available anywhere else. This is the same
as with the pledge() system call.
Where invalid arguments are given, and no action performed,
pledge promises are also reduced to just stdio, preventing
any writes to files, or reads from files.
Signed-off-by: Leah Rowe <leah@libreboot.org>
After reading a file, remove rpath.
When removing rpath, also remove wpath if flags
are not to O_RDONLY (read-only disk operation).
When wpath is permitted, and a file was successfully
written, remove wpath.
In order to permit /dev/urandom access in rhex(),
I call it as a void just before re-calling pledge.
The rhex() function has been written in such a way
that /dev/urandom only needs to be read *once*.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I assumed wpath was all that's needed, but this simply
allows writes.
rpath must be specified alongside wpath, for reads.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The utils that are pledged checked HAVE_PLEDGE which was
bogus. OpenBSD defines __OpenBSD__, which you can check
for in ifdef.
This change makes nvmutil and spkmodem-recv *actually*
use pledge, when the utils are compiled on OpenBSD.
Signed-off-by: Leah Rowe <leah@libreboot.org>
make blobutil a symlink. Example of command changes:
./blobutil download x220_8mb
is now:
./update blobs download x220_8mb
The old command still works, for compatibility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
move resources/scripts/download/ to:
resources/scripts/update/module/
This: ./download coreboot
Is now: ./update module coreboot
However, running "./download coreboot"
still works, via backwards compatibility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
unify them, by turning them into symlinks pointing
to a generic script named lbmk
the script named lbmk is a fork of the script
named "build", which just checks argument 0 and adapts
accordingly
all of these core scripts had the exact same overall
logic, and they are thus compatible
Signed-off-by: Leah Rowe <leah@libreboot.org>
The primary purpose of my intense auditing has
been to improve lbmk's coding style and fix bugs
but there is a secondary purpose: know precisely
who owns what, because I want to re-license as
much as possible of lbmk under *MIT*, instead of
the current GNU licensing. MIT is vastly superior,
because it grants *actual* freedom to the user,
permits *sublicensing* and it is vastly more
compatible with other GPL combinations; for
example, MIT license is compatible with GPL2-only
whereas lbmk's current mix of GPLv3-or-later and
GPLv3-only is legally incompatible with GPLv2-only.
Re-licensing under MIT will most likely result in
more contributions to Libreboot's build system in
the future, especially as it will attract a lot
more commercial interest. Contrary to the popular
arguments, copyleft is a liability to the free
software movement and results in less code being
written; in practise, permissively licensed code
gets more public contributions, including from
commercial entities, even if companies can
theoretically make something proprietary out of
it (in practise, anyone inclined can just use the
upstream and proprietary forks almost always die).
Copyleft propaganda is fundamentally flawed. See:
<https://unixsheikh.com/articles/the-problems-with-the-gpl.html>
Anyway, I've been doing a combination of:
* Seeking permission from other copyright holders,
for re-licensing
* Deleting, or moving, other contributions; for
example, splitting certain contributions into
separate files so that originally modified files
become unencumbered. This latter solution is a
result of *code cleanup* arising from the audit.
For Ferass's contributions, I opted to seek
*permission*, and permission was denied. In full compliance
with this legal imperative, I'm acting accordingly; this
commit removes all of Ferass's changes that converted lbmk
to posix shell scripts, thus removing his copyright on the
affected files, bypassing his authority entirely. Therefore,
lbmk is largely now bash-dependent. In practise, nobody is
going to use anything other than a GNU system to build
Libreboot, because many projects that Libreboot makes use
of rely heavily on GNU; for example, coreboot's build
system makes heavy use of GNU-specific extensions in *GNU
Make*, and likely contains many bashisms. Of course,
Libreboot also compiles GNU GRUB.
I would much rather have MIT-licensed Bash scripts
than GPL-licensed posix SCL scripts.
This reverts the changes from Ferass El Hafidi,
for the following commits, with some exceptions:
* 7f5dfebf7d
* f787044642
Exception:
download/mrc not reverted, because that was
already a fork of an existing script under
coreboot's build system, and their script was
GPLv2. i cannot/will not re-license this file
(ergo,
7f5dfebf7d
change remains intact, on this file)
resources/scripts/build/boot/roms_helper, these changes
have been kept:
* 7e6691e9 - Add ARMv7 and AArch64 support
* dec2d720 - add myself in the build/roms_helper script
(added 2021 copyright for the change below)
* b7405656 - Workaround for grub's slow boot
^ these changes will be re-factored, splitting them
out of the file into a new file. This will be done in
a future lbmk revision. (in some cases, it makes sense
to keep a change but split it, allowing the main file to
be re-licensed without the change in it)
This is part of a much larger series of
licensing audits. It's likely that lbmk will
be posix-compliant (in its shell scripts)
again some day, because I'm planning to rewrite
most of these scripts (the ones modified in this
patch), and many of them (e.g. individual download
scripts) are subject to future deletion in a planned
overhaul of the download logic for third party
projects.
In addition: these changes are being kept (no attempt
to re-license them will be made):
* cff081c6 - Fix grub's slow boot (1 year, 5 months ago) <Vitali64>
* 4c851889 - Add macbook*1 16mb configs (1 year, 6 months ago) <Vitali64>
Ferass's work that remains will be split into dedicated
files containing them, where feasible.
In the case of grub.cfg (for GNU GRUB), I don't care
because it's a script for an engine (GRUB shell) that's
under GPL anyway, so who really cares about MIT license.
Signed-off-by: Leah Rowe <leah@libreboot.org>
only alper and ferass have ownership of this file,
but ferass only submitted to it in 2022, not 2021
fix this
i've removed myself from the file, for now
i never touched this file before, so it's
not right that my name be here
put alper's name at the top, because alper
was the person who created this file first
Signed-off-by: Leah Rowe <leah@libreboot.org>
it will already fail if the coreboot download did.
if the coreboot download succeeds, the directory exists.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the "placeholder" git credentials were not being
wiped, which sometimes overwrites the user's git
credentials permanently, when working on lbmk
(permanently, until manually reset by the user)
Signed-off-by: Leah Rowe <leah@libreboot.org>
It will only be used on OpenBSD. Other operating
systems will behave in the same way.
Pledge is feature specific to OpenBSD that
restricts system operations, for security:
https://man.openbsd.org/pledge.2
Signed-off-by: Leah Rowe <leah@libreboot.org>
printf outputs to stdout, which is line buffered
by default.
Adding a -u option to disable buffering.
Exit when a non-support flag is given, but adhere
to current behaviour when no flag is given.
Signed-off-by: Leah Rowe <leah@libreboot.org>
They do not need to be initialised zero, because
global variables are always zero by default,
unless set differently by the programmer.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Imported from util/spkmodem_recv at coreboot
revision:
e70bc423f9a2e1d13827f2703efe1f9c72549f20
This is a client for spkmodem, to allow serial
console via PC speaker.
I've decided to import it in lbmk, because I
heavily modified it. The patches will be
applied next.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i'm pretty much finished now
there might be a few more changes later,
like stricter error handling, more verbose
error messages, etc
right now, it relies on -e to kill lbmk
on error, and uses the exit command
another planned change it to support
other upstreams besides coreboot.org,
such as the dasharo codebase
the latter is *why* i refactored this
download script, for asus kgped-d16
to my knowledge, this feature has never been used,
but lbmk permits resources/coreboot/boardname/extra.sh
to execute, as provided by the maintainer, with working
directory set to: coreboot/boardname
this could be used to extend lbmk in a number of ways
for example, it could be used to patch 3rdparty/
it could also be used to break coreboot in creative
and novel ways. hint hint.
the "board" variable in prepare_new_coreboot_tree()
is also declared in fetch_coreboot_trees
for the one in prepare_new_coreboot_tree, it's passed
as an argument to the function, so give it a new name
i learned that some shells have a global scope, when
using variables of the same name between functions
this should download all trees:
./download coreboot
without this patch, it doesn't
with this patch, it works
i overlooked this during earlier
refactoring. auditing revealed it.
top-down order, and *still* rfc 3676 compliant
i finished simplifying the logic, and
i split everything into smaller functions
there is still more more polishing to do
final touches will be done in new revisions
coreboot trees/patching is still handled
specifically by "./download coreboot"
command now available in lbmk:
./gitclone coreboot
this *only* creates the directory at:
coreboot/coreboot
this directory is never used in builds.
it is only used by download/coreboot to
create patched trees for each mainboard
consistent indentation, and 80-line character limit
(RFC 2646)
top-down order, a main() is introduced, split into
more functions
non-zero-status exit (with message) now, when a non-
defined target is provided, e.g. nonexistentboard_4mb
puffy!
the cbfstool command within subshell now also
exits with non-zero status, if it fails (most
likely because extraction failed, for some reason,
of the coreboot rom image for running through it)
the previous code merely exited from the subshell,
but the intended behaviour is for the entire script
to halt execution, and exit with non-zero status.
this patch fixes that bug.
top-down order for all logic, and shorter code lines,
conforming to rfc 2646 (no more than 80 characters)
the 80-character rule is violated for variables containing
long strings, such as wayback machine urls (can't be helped)
a few bugs were discovered, which will be fixed in follow-up
revisions, such as:
* exit status not handled inside subshell
* in general, exit status should be handled
more explicitly, rather than relying on -e
where the asterisk is used, it can sometimes
literally try to patch with a file named "*",
which of course does not exist
this change fixes an lbmk error when running:
./download seabios
this was caused recently, because all patches
were seabios were removed (lbmk currently uses
stock seabios, without patching it)
for our purposes, grub and gnulib are one in the same
if one fails, both have failed
exit with non-zero status if gnulib fails
the script sets -e so it will fail if grub fails to
download, which is tried before gnulib, and if that
happens, the grub directory is not created
the old code was specifing an absolute offset for
insertion of mrc.bin - cbfstool interprets anything
above 0x80000000 as top-aligned memory address in
x86, and anything below as an obsolute offset in
the flash, like with the old number
where a top-aligned address is provided to cbfstool,
the absolute position is calculated for the flash,
and cbfstool inserts it in the correct rom location
the benefit of this change is that the absolute
offset is now calculated automatically, which means
that the code will be correct even if the flash
size changes. for example, if 16MB flash is used
whereas 12MB is currently the default an support
haswell hardware
coreboot does not provide anything readably like
Kconfig, for extracting this value. it's baked
into the source code of coreboot, so you have to
find it. the correct location is hardcoded for
each platform, and always the same on each platform,
regardless of mainboard
top-down function order, with specific functions for
each type of blob. startup logic moved into main(),
also split into smaller functions
"write one program that does one thing well"
blobutil is like that, and has this added philosophy:
"write one function that does one thing well"
during the course of this re-factoring, several bugs
and issues were found, that are pre-existing. these
will be corrected in follow-up revisions
I added this in upstream to prevent people from accidentally flashing
roms without a payload resulting in a no boot situation, but in
libreboot lbmk handles the payload and thus this warning always comes
up. This has caused confusion and concern so just patch it out.
users reported it doesn't boot in recent releases, with the
february 2023 coreboot revision update
i have one in the lab, i'll just re-test it and fix whatever's
wrong for a future release
previously, "normal" initmode relied on the vgarom-based
seabios config, which enables option roms, but then lbmk
would insert pci-optionrom-exec 0 for vgarom, and 2 for normal
in libreboot, coreboot roms with "vgarom" in the filename do
pci option rom execution from coreboot, and "normal" roms
do execution from seabios(where seabios is the only payload
provided on normal setups)
this is because payloads like grub can also be used, on vgarom
setups, where coreboot must handle oprom execution
the deleted patch (in this commit) was written to fix an
issue theoretically; it hasn't been fully tested, and some
people have reported strange issues since this patch was
merged - there is no proof that this patch causes them, but
removing this patch is the correct thing to do regardless
2023-04-24 13:14:23 +01:00
623 changed files with 47094 additions and 33763 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.