in the future, we may start downloading files that aren't
blobs, such as mxm port configs (on mainboards that use
MXM graphics)
this directory will contain all of those files
generally change the language used, across lbmk, to make
use of "vendorfile" instead of "blob"
Signed-off-by: Leah Rowe <leah@libreboot.org>
We don't have a directory names "srces", just "src".
Ditto ecs, mrcs <-- it's just ec and mrc
When referring to a file, e.g. blob/t1650/me.bin, that
makes much more sense, because it's a single blob, not
multiple blobs.
Don't pluralise what isn't plural
Signed-off-by: Leah Rowe <leah@libreboot.org>
build/release/src was partly re-written to accomodate this
memtest86plus was patched to have a central Makefile, and
lbmk modified to use that, rather than mess with build32
and build64. the central Makefile just builds both targets
or cleans both targets
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
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>
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>
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>
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>
This is useful for e.g. HP EliteBook 2560p.
In coreboot config, enable e.g. (for lbmk blobutil):
CONFIG_KBC1126_FW1="../../ec/hp2560p/ec.bin.fw1"
CONFIG_KBC1126_FW2="../../ec/hp2560p/ec.bin.fw2"
In resources/blobs/sources you would have these entries:
EC_url
EC_url_bkup
EC_hash
don't download it. keep it in lbmk.
libreboot moved to codeberg for git hosting,
and i didn't want to keep lugging around an
extra git repo just for one tiny project.
On many boards, grub takes a very long time to
search for a grub.cfg file on the disk.
The problem is the search_grub function which
takes a long time to complete.
I (vitali64) studied the grub.cfg from 2016 and
the grub.cfg from 2021 and optimized the
grub.cfg. It should be faster now.
tianocore is a liability for the libreboot project. it's a bloated mess, and
unreliable, broken on many boards, and basically impossible to audit.
i don't trust tianocore, so i'm removing it.
this is forked from the "libre" branch in osboot, which is itself a libre,
deblobbed fork of osboot, a blobbed up fork of libreboot
libreboot needed to be purged clean. this is the new libreboot development
repository. the old one has been abandoned
Leah Rowe