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>
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>
this is cherry-picked from osbmk. the cherry-pick was
performed by i, leah rowe. this is adapted from shmalebx's
patch there, in osboot
specifically, these patches from osbmk are being imported:
327a39ef058d5385bf8c1a1b09bac8db6a51b016
5139ad4be4df1835ce154f39161eef4f7c31ee1a
with this change, it's unlikely we'll hit errors again. previously,
some projects used were calling "python" which in context was
python3, but on some setups, the user only has python2 and python3
but no symlink for "python" (which if exists, we assumed linked to
python3)
now it's unambiguous. docs/build/ can probably be updated now, as
a result of this change, to remove the advice about that
I was running into a race condition when rebuilding seabios with a high cpu count,
resulting in failure with this error message:
cc1: fatal error: can't open 'out/src/asm-offsets.s' for writing: No such file or directory
Performing the silentoldconfig step before the full make step seems to resolve the failure.
When running ./download all, we have the following error:
resources/scripts/download/coreboot: Line 52: $1 is not set.
The ./download all command was broken by the following commit:
2bb805e2e0 (download: Add --help in the
individual download scripts).
Reported-by: madbehaviorus[m] on #libreboot on liberachat
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Without that fix we have the following warning during the download:
Cloning into 'u-boot/u-boot'...
warning: redirecting to https://source.denx.de/u-boot/u-boot.git/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This should enable various distributions and build system to reuse
the generated script to deblob u-boot releases themselves.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This should enable various distributions and build system to reuse
that blob to deblob u-boot releases themselves.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The tar options come from the tutorial to remove archives metadata at
reproducible-builds.org[1].
[1]https://reproducible-builds.org/docs/archives/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This doesn't change the existing usage of the scripts:
- For the Coreboot script, before this change, all arguments that were
passed were considered as board to download the Coreboot source code
for.
Here we added the '--help' and '--list-boards' arguments, so it
should not be an issue as it is extremely unlikely that a board
would be called '--help' or '--list-boards'.
- All the other scripts don't use any arguments so passing --help
should not conflict with the existing usage.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
If the script is named u-boot-stable-src-release and that users see an
u-boot-libre tarball they will not make the link between both unless
we rename the script.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Many people using FSDG compliant distributions or wanting to use one
are already familiar with linux-libre. This change renames the
resulting tarball to u-boot-libre to make it easier for people to
understand the goal of this tarball.
In addition we also rename the version from v2021.07 (which is the git
tag corresponding to the release) to 2021.07 as u-boot upstream
tarballs use that.
The revision wasn't bumped as we didn't have any releases of
u-boot-libre yet.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Once the tarball are released, it will enable distributions to use
these tarballs to produce deblobbed u-boot packages.
Note that the produced tarball is not reproducible yet. Because of
that it has to be trusted.
During a release, it's a good idea to sign the uncompressed tarball as
the various compression formats and associated tools make different
tradeoffs.
For instance with xz, xz -9e tends to compress really well with the
the most used xz[1] implementation, and most GNU/Linux users probably
already have it installed, but and the drawbacks is that the format is
very fragile[2].
The lzip format is more suited for long term archiving but its most
packaged implementation[3] is less likely to be already installed by
users than more well known formats like xz, bzip2 or gzip.
Being able to add more compression formats after the release is also
useful, for instance to accommodate different build systems or use
cases (like being able to build u-boot with less dependencies in
distributions like Guix, or building u-boot directly on devices which
don't have enough RAM for xz for instance).
[1]https://tukaani.org/xz/
[2]https://www.nongnu.org/lzip/xz_inadequate.html
[3]https://www.nongnu.org/lzip/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Alper Nebi Yasak