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>
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>
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>
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