[PATCH 2/5] ci: add post-buildman script to build TF-A
Tom Rini
trini at konsulko.com
Mon Sep 22 15:59:01 CEST 2025
On Sat, Sep 20, 2025 at 10:13:34AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 19 Sept 2025 at 09:26, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Sep 19, 2025 at 09:09:26AM -0600, Simon Glass wrote:
> > > Hi Raymond,
> > >
> > > On Wed, 17 Sept 2025 at 09:49, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Wed, Sep 17, 2025 at 11:44:07AM -0400, Raymond Mao wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 16 Sept 2025 at 14:27, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Sep 16, 2025 at 09:14:18AM -0700, Raymond Mao wrote:
> > > > > > > Add a script which is running after buildman to fetch TF-A (v2.13.0)
> > > > > > > with MbedTLS (v3.6) and build 'flash.bin', linking built U-Boot as
> > > > > > > BL33 and OP-TEE as BL32, with both Firmware Handoff and Measured Boot
> > > > > > > enabled.
> > > > > > >
> > > > > > > Signed-off-by: Raymond Mao <raymond.mao at linaro.org>
> > > > > > > ---
> > > > > > > .azure-pipelines.yml | 1 +
> > > > > > > .gitlab-ci.yml | 1 +
> > > > > > > tools/post_build_tfa_fw_handoff.sh | 87 ++++++++++++++++++++++++++++++
> > > > > > > 3 files changed, 89 insertions(+)
> > > > > > > create mode 100755 tools/post_build_tfa_fw_handoff.sh
> > > > > > >
> > > > > > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > > > > > index 8209d2b329c..eb547606ddd 100644
> > > > > > > --- a/.azure-pipelines.yml
> > > > > > > +++ b/.azure-pipelines.yml
> > > > > > > @@ -290,6 +290,7 @@ stages:
> > > > > > > cp /opt/grub/grubriscv64.efi \${UBOOT_TRAVIS_BUILD_DIR}/grub_riscv64.efi
> > > > > > > cp /opt/grub/grubaa64.efi \${UBOOT_TRAVIS_BUILD_DIR}/grub_arm64.efi
> > > > > > > cp /opt/grub/grubarm.efi \${UBOOT_TRAVIS_BUILD_DIR}/grub_arm.efi
> > > > > > > + ./tools/post_build_tfa_fw_handoff.sh \${UBOOT_TRAVIS_BUILD_DIR} \${TEST_PY_BD} \${TEST_PY_ID}
> > > > > > > # create sdcard / spi-nor images for sifive unleashed using genimage
> > > > > > > if [[ "\${TEST_PY_BD}" == "sifive_unleashed" ]]; then
> > > > > > > mkdir -p root;
> > > > > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > > > > > index 85401d3e09b..61e4af96c9a 100644
> > > > > > > --- a/.gitlab-ci.yml
> > > > > > > +++ b/.gitlab-ci.yml
> > > > > > > @@ -79,6 +79,7 @@ stages:
> > > > > > > - cp /opt/grub/grubriscv64.efi $UBOOT_TRAVIS_BUILD_DIR/grub_riscv64.efi
> > > > > > > - cp /opt/grub/grubaa64.efi $UBOOT_TRAVIS_BUILD_DIR/grub_arm64.efi
> > > > > > > - cp /opt/grub/grubarm.efi $UBOOT_TRAVIS_BUILD_DIR/grub_arm.efi
> > > > > > > + - ./tools/post_build_tfa_fw_handoff.sh ${UBOOT_TRAVIS_BUILD_DIR} ${TEST_PY_BD} ${TEST_PY_ID}
> > > > > > > # create sdcard / spi-nor images for sifive unleashed using genimage
> > > > > > > - if [[ "${TEST_PY_BD}" == "sifive_unleashed" ]]; then
> > > > > > > mkdir -p root;
> > > > > > > diff --git a/tools/post_build_tfa_fw_handoff.sh b/tools/post_build_tfa_fw_handoff.sh
> > > > > > > new file mode 100755
> > > > > > > index 00000000000..f876db593ba
> > > > > > > --- /dev/null
> > > > > > > +++ b/tools/post_build_tfa_fw_handoff.sh
> > > > > >
> > > > > > The "is this a valid board" check should be in the pipeline file (like
> > > > > > where we do all the other board-specific things) instead of the helper
> > > > > > script.
> > > > > >
> > > > > > > @@ -0,0 +1,87 @@
> > > > > > > +#!/bin/bash
> > > > > > > +# SPDX-License-Identifier: GPL-2.0+
> > > > > > > +#
> > > > > > > +# Copyright (c) 2025 Linaro Limited
> > > > > > > +# Author: Raymond Mao <raymond.mao at linaro.org>
> > > > > > > +#
> > > > > > > +# CI Post-buildman script for building TF-A 'flash.bin' with Measured
> > > > > > > +# Boot and Firmware Handoff enabled.
> > > > > > > +#
> > > > > > > +# Usage: from the top level U-Boot source tree, run:
> > > > > > > +# $ ./tools/post_build_tfa_fw_handoff.sh ${UBOOT_TRAVIS_BUILD_DIR} \
> > > > > > > +# ${TEST_PY_BD} ${TEST_PY_ID}
> > > > > > > +#
> > > > > > > +# 'bl1.bin', 'fip.bin' and 'flash.bin' will be generated and copied
> > > > > > > +# to /tmp.
> > > > > > > +
> > > > > > > +set -e
> > > > > > > +
> > > > > > > +BUILDMAN_OUT_DIR=$(realpath "$1")
> > > > > > > +BOARD=$2
> > > > > > > +ID=$4
> > > > > > > +echo "Buildman Outdir: $BUILDMAN_OUT_DIR, Board: $BOARD, ID: $ID"
> > > > > >
> > > > > > Can we not use fiptool to update the contents of a file here? And build
> > > > > > as much as possible in the Dockerfile, like we do for vexpress?
> > > > > >
> > > > > Sorry I am not quite clear about how it was done for fvp, maybe I
> > > > > missed some context, do you mean to build TF-A with OP-TEE at
> > > > > Dokerfile and generate a fip.bin without BL33? But then who will
> > > > > assemble BL1+fip+u-boot? by test hooks?
> > > >
> > > > So for FVP, in the Dockerfile we say BL33=/dev/null and this gets
> > > > packaged correctly. Then in u-boot-test-hooks we have bin/flash.fiptool
> > > > which will update "fip" with the just-built u-boot.bin. The logic:
> > > > # If we have TF-A binaries, we need to use them.
> > > > - if [[ -d /opt/tf-a/"${TEST_PY_BD}" ]]; then
> > > > cp /opt/tf-a/"${TEST_PY_BD}"/fip.bin /opt/tf-a/"${TEST_PY_BD}"/bl1.bin /tmp/;
> > > > export fip=/tmp/fip.bin;
> > > > export bl1=/tmp/bl1.bin;
> > > > export PATH=/opt/Base_RevC_AEMvA_pkg/models/Linux64_GCC-9.3:${PATH};
> > > > fi
> > > >
> > > > Is how we know what bl1.bin and fip.bin to use as the base.
> > > >
> > > > --
> > > > Tom
> > >
> > > This should actually use binman. We don't want any shell scripts for
> > > building :-) We finally got rid of the FIT generator script after some
> > > years.
> > >
> > > Build mbedtls and TFA should be in dockerfile, like we have for
> > > coreboot, for example. I suspect they will be useful in other tests
> > > too.
> >
> > There's nothing to do here for binman, it already supports fiptool. It
> > just doesn't make much sense to add the complexity in this case however.
>
> Write a binman description so it creates an image as part of the build
> for this board.
>
> It could be a good example if other people want to use TF-A, etc. with U-Boot.
No, I don't think that makes sense in this case, you're missing
sufficient context.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250922/986b6e7a/attachment.sig>
More information about the U-Boot
mailing list