[Buildroot] [PATCH v2 2/2] configs/qemu_arm_vexpress_tz_falcon_defconfig: new

[Thomas Petazzoni]

Hello,

On Tue, Sep 16, 2025 at 07:45:41PM -0700, Jakob Kastelic wrote:
> This commit adds a new configuration, in which TF-A loads Linux directly
> (as BL33) under Qemu. This defconfig can be used to test the new TF-A
> flag, BR2_TARGET_ARM_TRUSTED_FIRMWARE_LINUX_AS_BL33.
> 
> Signed-off-by: Jakob Kastelic <kastelic.jakob at gmail.com>

Thanks for your patch! However, rather than having it as a defconfig,
we would prefer to have it as a runtime test, which builds this
configuration and boots it under Qemu.

There's already a TF-A test in
support/testing/tests/boot/test_atf.py. However, this existing test
only performs build testing of TF-A. In your case, we would also want
to boot the system into Qemu as part of the test.

You can for example have a look at
support/testing/tests/boot/test_edk2.py which also does run-time
testing in Qemu.

> diff --git a/DEVELOPERS b/DEVELOPERS
> index 16d9ee892b..227b239bea 100644
> --- a/DEVELOPERS
> +++ b/DEVELOPERS
> @@ -3537,3 +3537,6 @@ F:	package/quazip/
>  F:	package/shapelib/
>  F:	package/simple-mail/
>  F:	package/tinc/
> +
> +N:	Jakob Kastelic <kastelic.jakob at gmail.com>
> +F:	configs/qemu_arm_vexpress_tz_falcon_defconfig

Make sure to add this entry not at the end of the file, but at the
right place based on the alphabetic ordering of developer names.

> diff --git a/board/qemu/arm-vexpress-tz-falcon/patch-dts.sh b/board/qemu/arm-vexpress-tz-falcon/patch-dts.sh
> new file mode 100755
> index 0000000000..896ae317b5
> --- /dev/null
> +++ b/board/qemu/arm-vexpress-tz-falcon/patch-dts.sh
> @@ -0,0 +1,21 @@
> +#!/bin/sh
> +
> +set -u
> +set -e
> +
> +QEMU_BOARD_DIR="$(dirname "$0")"
> +INITRD_ADDR=$(sed -n 's/.*addr=\(0x[0-9a-fA-F]*\).*/\1/p' "${QEMU_BOARD_DIR}/readme.txt" | head -n1)
> +ROOTFS_SIZE=$(stat -c %s "${BINARIES_DIR}/rootfs.cpio.gz")
> +INITRD_END=$(printf '0x%x' $((0x${INITRD_ADDR#0x} + ROOTFS_SIZE)))
> +TMP_DTB="${BINARIES_DIR}/falcon.tmp.dtb"
> +FINAL_DTB="${BINARIES_DIR}/falcon.dtb"
> +
> +# Extract the DTB from Qemu
> +qemu-system-arm -smp 1 -s -m 1024 -d unimp \
> +	-machine virt,dumpdtb="${TMP_DTB}",secure=on -cpu cortex-a15
> +
> +# Insert intramfs address into /chosen
> +fdtput -t x "${TMP_DTB}" /chosen linux,initrd-start "${INITRD_ADDR}"
> +fdtput -t x "${TMP_DTB}" /chosen linux,initrd-end "${INITRD_END}"
> +
> +mv "${TMP_DTB}" "${FINAL_DTB}"

Wouldn't the test be simpler if you were to mount a real rootfs from
storage, instead of using an initrd?

> diff --git a/configs/qemu_arm_vexpress_tz_falcon_defconfig b/configs/qemu_arm_vexpress_tz_falcon_defconfig
> new file mode 100644
> index 0000000000..5ca6e74668
> --- /dev/null
> +++ b/configs/qemu_arm_vexpress_tz_falcon_defconfig
> @@ -0,0 +1,36 @@
> +BR2_arm=y
> +BR2_cortex_a15=y
> +BR2_ARM_FPU_VFPV3D16=y

In the runtime test infrastructure, you will want to use an external
toolchain (there are based toolchain configurations available that
might work).

> +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_12=y
> +BR2_TOOLCHAIN_BUILDROOT_CXX=y
> +BR2_GLOBAL_PATCH_DIR="board/qemu/patches"
> +BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
> +BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
> +BR2_ROOTFS_POST_BUILD_SCRIPT="board/qemu/arm-vexpress-tz/post-build.sh"
> +BR2_ROOTFS_POST_IMAGE_SCRIPT="board/qemu/post-image.sh board/qemu/arm-vexpress-tz-falcon/patch-dts.sh"
> +BR2_ROOTFS_POST_SCRIPT_ARGS="$(BR2_DEFCONFIG)"
> +BR2_LINUX_KERNEL=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.12.27"
> +BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
> +BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/arm-vexpress-tz/linux.fragment"
> +BR2_PACKAGE_OPENSSL=y
> +BR2_PACKAGE_OPTEE_EXAMPLES=y
> +BR2_PACKAGE_OPTEE_TEST=y

If you have these on the target, then the runtime test should ideally
run the OP-TEE tests?

Could you rework, and send a new iteration?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com