| Age | Commit message (Collapse) | Author |
|---|
|
i added this in the last revision
it was put there to debug something that
i fixed before pushing
|
|
|
|
bs 12k and count 1, rather than bs 1 and count 12k
|
|
|
|
|
|
this cuttype is no longer used
lbmk creates truncated me setups now, on ifd platforms
|
|
|
|
the logic can now more or less be read chronologically
|
|
logic will be split from main into smaller
functions, in follow-up commits
|
|
consolidated some for loops
removed errant code
|
|
|
|
|
|
No more than 80 characters per line.
|
|
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
|
|
|
|
By making lbmk fully POSIX-compliant, it will be easier to port lbmk to
other systems implementing POSIX such as Alpine Linux and FreeBSD.
Signed-off-by: Ferass 'Vitali64' EL HAFIDI <vitali64pmemail@protonmail.com>
|
|
|
|
U-Boot runtime configuration is done with a device-tree file, which is
built alongside the executable in the upstream build system, and must be
available to U-Boot at runtime.
This device-tree is normally not linked into the default "u-boot" ELF
file. So far we have been handling it by re-creating a "u-boot.elf" from
the raw binary parts by setting REMAKE_ELF, and using that as the
coreboot payload. Unfortunately, that fails to build for x86 boards,
more specificly the "coreboot" boards upstream.
It's also possible (but discouraged) to set OF_EMBED to embed the
device-tree file into the U-Boot itself, in which case we could use the
"u-boot" file as the payload on the "coreboot" boards. Add support for
using the "u-boot" file as the payload if "u-boot.elf" doesn't exist.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The roms_helper script skips building crossgcc-i386 if its target
directory exists. Skip it for other architectures as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Add the coreboot-built cross-architecture toolchains to the PATH so that
modules and payloads can use them. When building for a foreign-arch
board, also export CROSS_COMPILE pointing to the appropriate prefix.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This re-applies commit a69855f7e448 ("Build 32-bit crossgcc for AArch64
as well") which was inexplicably reverted along with unrelated changes.
Mention in a comment that building crossgcc-arm is necessary for
AArch64.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
When overriding which payloads will be built with the -p command line
argument, the roms_helper script builds the Memtest86+ payload before
checking if it should be disabled. Move the build command after the
command line override.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
When overriding which payloads will be built with the -p command line
argument, the roms_helper script doesn't disable the U-Boot payload.
Disable it in this case.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
the --nuke option in ifdtool will be used instead, to nuke
the ME regions in specific rom sets (and cbfstool will be
used to delete mrc.bin files from rom sets)
the new method being implemented is heavier on disk io, but
simplifies lbmk, and disk io could still be optimised in
the following ways:
* when copying roms from boards with ME in them, use
ifdtool --nuke to get filename.rom.new, and *move* (not copy)
filename.rom.new to the new destination (for use with tar)
* possibly modify ifdtool to make efficient use of mmap for
disk i/o; it currently loads entire roms into an allocated
buffer in memory
|
|
|
|
the intended use-case scenario was one in which vga rom initialisation
would be used, on desktop configurations, but without coreboot itself
handling vga rom initialisation, instead leaving that task to seabios
it was assumed that grub, when running on the bare metal with
build option "--with-platform=coreboot" would be able to display
like this, but it is not so when tested
in such setups (add-on gpu with grub payload), it is necessary to
extract the video bios and insert it into the coreboot rom, having
coreboot handle such execution. this is beyond the scope of lbmk,
in context of automated building, because we cannot reliably predict
things such as PCI IDs
do away with this build option entirely, for it does not serve the
intended purpose. it will be necessary to run PC GRUB instead (build
option --with-platform=i386-pc). PC GRUB can still read from CBFS,
and you could provide it as a floppy image file inside CBFS for
SeaBIOS to execute. in this setup, GRUB would function as originally
intended by the seabios_withgrub option; such a configuration is
referred to as "SeaGRUB" by the libreboot project, and experimentation
was done with it in the past, to no avail
it's better to keep things simple, in the libreboot project. simpler
for users, that is
|
|
buggy, buggy, buggy, buggy, buggy, buggy, buggy
full of bugs, these boards never worked properly. i got ripped
off with these.
now i'm ripping off the band aid
use dasharo if you want d16 stuff. i'm done with it.
|
|
osboot is now part of libreboot, and will soon shut down.
libreboot now conforms to osboot policy.
|
|
In recent coreboot versions, running distclean started to erase the
cbfstool binary we built earlier in the util/cbfstool dir via the
cbutils build script call. The coreboot build puts it in a different
directory, and the roms build script can't find it when trying to add
payloads to the roms. This doesn't make the script fail (because set -e
is stupid like that), and the build appears to succeed if you don't look
close enough to see the "cbfsutil not found" error.
Build the coreboot utils we want at the places we want them after
calling distclean, so that we can actually use cbfsutil and avoid
silently-broken roms with newer coreboot versions.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This enables embedding U-Boot into the coreboot roms as the payload. For
now, the ELF file generated by enabling CONFIG_REMAKE_ELF is used, which
includes the U-Boot binary and the board-specific device-tree file. It
might be better to use the FIT payload support for U-Boot, but that was
reportedly broken and is not tested yet.
Coreboot boards can specify payload_uboot="y" in their board.cfg to
enable building a rom with U-Boot as the payload, which is built from
the U-Boot board with the same name. Boards can further specify a
uboot_config option, to choose which board-specific config file U-Boot
should be built with.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The 32-bit ARM cross compiler toolchain is used to build parts of
arm-trusted-firmware needed by AArch64 boards, compile the toolchain for
those boards as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The code that compiles coreboot crossgcc changes the working directory
to the coreboot directory, and the following code cannot find the lbmk
scripts that it needs to run. Compile ARMv7 and AArch64 cross compilers
in a subshell like in the x86 case so the rest of the script can work.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
just set it to the default, instead
|
|
or was used, instead of and
|
|
|
|
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 reverts commit 84a1bc502b1f296d8ad6389b9e38aa3e0ca94958.
|
|
|
|
mitigate missing characters in unifont for border/arrow characters. this saves
space because now it is no longer necessary to add a custom font
the background added has the libreboot logo on it, and it's 10kb in size unlike
the old gnulove background that was hundreds of KB
|
|
These option ROMs are known to cause a system hang. If you insert an empty
option ROM into CBFS, it disables any option ROM loading for those devices
when using SeaBIOS.
|
|
|
|
|
|
|
