| Age | Commit message (Collapse) | Author |
|---|
|
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 U-Boot download script does its work from the repository root
instead going into the newly created dirs, unlike the coreboot
counterpart. It should run the board-specific extra.sh files with the
downloaded paths as their working directory. Do so by a subshell.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The no-argument form of the U-Boot download script prepare trees for all
boards when run with no arguments, like the corresponding script for
coreboot. The usage text for this case was removed without any changes
to the corresponding code, assume it was by mistake and add it back.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Removing the git dirs was part of deblobbing, which Libreboot no longer
cares about. The variable that triggers it is no more. Remove the dead
code.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
|
|
|
|
|
|
this is a hangover from pre-osboot-merge libreboot. the idea
was to distribute fsdg uboot archives
lbmk has uboot support, and releases will simply
include uboot in the main src archive like with everything else
|
|
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.
|
|
|
|
|
|
|
|
|
|
python2 is eol and the only thing that needed it was build scripts
inside tianocore, back in osbmk days when tianocore was supported
in the (osboot) build system. nothing else requires it, so chuck 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>
|
|
These are almost verbatim copies of coreboot versions, but using
'u-boot' instead of 'coreboot' and 'ub*' instead of 'cb*'.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This enables building U-Boot for boards which have config files in
resources/u-boot, and copying built files that could be usable to make
coreboot payloads. Right now, there is no such board in this repo.
The most important file here is "u-boot.elf", which is a combination of
the U-Boot binary and the appropriate device-tree file for the board.
Building this needs CONFIG_REMAKE_ELF=y on the U-Boot part, and using
this with CONFIG_PAYLOAD_ELF=y on the coreboot build works fine.
Note that this isn't enough to make U-Boot-only releases, since
low-level prerequisites like arm-trusted-firmware aren't passed in to
the U-Boot build system. Coreboot builds its own copy of TF-A and sets
it up on the board, so using these U-Boot builds as payloads should
still work.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Downloading coreboot and U-Boot takes quite the disk space and bandwith.
We don't need to download entire repos, only the revisions that we are
interested in.
Use the --depth=1 option to only download the files we need. Since the
initial clones may not have our target revision, always try to fetch it.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Keeping the git repositories is useful while development, e.g. to avoid
git cloning repositories over and over again while debugging download
scripts. Setting the NODELETE environment variable keeps the blobs and
the git repositories. Allow a slightly finer-tuned version of this where
we can keep only the git-related files by setting the variable to "git".
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Add a 'v2022.07' pseudo-board for the U-Boot download script with the
default blobs list, and mark the version as supported in u-boot-libre
release script.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The coreboot download removes .git folders as they still contain the
removed blobs, remove those in the U-Boot version as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Although it's unlikely, boards might want to run extra commands after
the board-specific U-Boot directories are prepared. Copy the existing
mechanism for that from the coreboot download script to the U-Boot one.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Boards may need different sets of patches to be applied to their U-Boot
builds, copy the existing mechanism from the coreboot download script to
the U-Boot download script.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The coreboot download script tries to update submodules, since coreboot
does use git submodules to retrieve and compile the projects it depends
on. Although U-Boot doesn't use submodules, try to update them anyway to
match the coreboot download script.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The coreboot download script uses GitHub as a fallback if the upstream
coreboot is unavailable, use a similar fallback for U-Boot as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Boards may want to specify a board-specific U-Boot revision. At the very
least, pseudo-boards for u-boot-libre releases will need to specify their
U-Boot versions somehow.
Copy the existing mechanism from download/coreboot for specifying
build info with board.cfg files. Specify the commit hash for the
'v2021.07' pseudo-board, and 'master' as the default.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The U-Boot download script is designed to help with releasing
u-boot-libre and it can only prepare a generic U-Boot v2021.07 tree.
However, we will need to build board-specific versions of U-Boot to be
able to use it as a coreboot payload effectively.
As a first step toward that, make the download script prepare per-board
copies of U-Boot v2021.07. Then, add a 'v2021.07' pseudo-board for the
u-boot-libre release script to work on.
The u-boot-libre deblob script hash ends up chaning due to copying my
author attribution from the download script, update its hash.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The u-boot-libre tarball contents' mtimes are an unconventional value
due to timezone confusion. For reproducibility, timestamps like these
are usually set by a SOURCE_DATE_EPOCH which is respected by both
coreboot and U-Boot. Use it in the u-boot-libre release script as well,
and properly set the mtimes to the Unix epoch when it's not defined.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The u-boot-libre release script copies the blobs list into the release
as the deblob script, presumably due to a copy-paste error. Fix it to
correctly copy the generated deblob script.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This firmware lack corresponding source code.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
The checksums in tests/u-boot-libre.sha512 do not match the tarballs
generated by this script when ran on a different timezone, e.g. UTC+3.
Explicitly specify a timezone for the tar command that makes the
tarballs match the checksums.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
|
