[PATCH v2 0/5] Enable Firmware Handoff CI test on qemu_arm64

[Tom Rini]

On Mon, Oct 06, 2025 at 01:42:50PM -0400, Raymond Mao wrote:
> Hi Tom,
> 
> On Fri, 3 Oct 2025 at 22:04, Raymond Mao <raymond.mao at linaro.org> wrote:
> >
> > Hi Tom,
> >
> > On Fri, 3 Oct 2025 at 16:13, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Fri, Oct 03, 2025 at 12:22:14PM -0700, Raymond Mao wrote:
> > >
> > > > This patch series enable Firmware Handoff [1] CI tests on qemu_arm64 by:
> > > > 1. fetch MbedTLS (v3.6), OP-TEE (v4.7.0) and TF-A (v2.13.0);
> > > > 2. build bl1 and fip with both Firmware Handoff and Measured Boot
> > > >    enabled;
> > > > 3. pytest to validate the Firmware Handoff feature via bloblist by
> > > >    checking the existence of expected FDT nodes and TPM events generated
> > > >    and handed over from TF-A/OP-TEE.
> > > >
> > > > Pre-requisite u-boot-test-hooks patches [2] are required.
> > > >
> > > > [1] https://github.com/FirmwareHandoff/firmware_handoff
> > > > [2] https://lore.kernel.org/u-boot/20251003191918.767698-1-raymond.mao@linaro.org/T/#t
> > >
> > > Generally, the changes look good, thanks! Specifically, did you trigger
> > > a CI run where you pointed Azure at a fork of u-boot-test-hooks with
> > > your changes? I'm a little concerned about the fiptool change and I
> > > don't see a CI run where qemu_arm64_optee.. was triggered, only:
> > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=12044&view=results
> > > where it's not. Thanks!
> > >
> >
> > That PR is missing the last commit (adding the CI jobs) and still
> > pointing to the original test hooks.
> > I have tested with my local docker container (has a test.sh that
> > simulates the one from azure.yml, and points to my test hooks working
> > branch) and all works.
> > But when I triggered it this afternoon at:
> > https://github.com/u-boot/u-boot/pull/818, I did see the failures...
> >
> > Hmmm, I will compare the log with the one I got from the local docker
> > container to find the cause.
> >
> 
> The github CI seems to not build from the dockerfile, it always runs with:
> ```
> 2025-10-03T22:30:41.8339632Z Digest:
> sha256:0d2cd4abea187f396a7e77041a6d9ce877314446a154cdcbfbbf546b09a58d09
> 2025-10-03T22:30:41.8352926Z Status: Downloaded newer image for
> trini/u-boot-gitlab-ci-runner:jammy-20250714-25Jul2025
> ```
> That is the reason of failure.
> Is there a way to hack the CI to build the container from the
> dockerfile of the PR branch?

Yes, you need to change:
  ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20250714-25Jul2025

In the .azure-pipelines.yml to point to where you've pushed your
container changes to.

-- 
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/20251006/629bdffa/attachment.sig>