The Cortex-R52 port has an automated FVP regression suite, but no GitHub workflow builds or runs it. The checks that report on a Cortex-R52 pull request are the generic atfe, Cortex-M, Cortex-A, host regression, SMP, FreeRTOS and ECA jobs, none of which configures an R52 toolchain, names the EXCLUDE_FROM_ALL example images, or executes their CTest entries. The suite can therefore stop compiling, or its module isolation test can start failing, with every required check still green.
Suggested sequencing
1. Hosted cross-build lane, first. ci_cortex_m.yml is build-only and is the existing precedent: install a pinned GNU Arm toolchain, configure with cmake/cortex_r52.cmake, build the explicit image list. Two configurations are worth having, because the default seven-image build leaves several paths uncovered:
- default:
-DTX_R52_BUILD_FVP_EXAMPLE=ON -DTX_R52_BUILD_FVP_MODULE_EXAMPLE=ON
- feature: the same plus
-DTX_R52_ENABLE_VFP=ON -DTX_R52_ENABLE_FIQ=ON -DTX_R52_ENABLE_IRQ_NESTING=ON -DTX_R52_ENABLE_FIQ_NESTING=ON, which covers VFP context save/restore, the FIQ path and both nesting paths
A compile-only S32Z280 lane (-DTX_R52_BUILD_S32Z280_EXAMPLE=ON, five targets) belongs here too.
2. FVP execution, second and separately. This is a new capability for the repository — nothing currently executes a cross-target image in CI. FVP_BaseR_AEMv8R is a licensed Arm download rather than a package that can simply be installed in a hosted runner, so execution most likely needs a self-hosted runner. Keep the cross-build lanes hosted and required regardless of how execution is resolved.
The CTest entries already exist: the runner judges each image by its self-reported result line and treats a missing line as a failure, so a hang cannot pass.
This overlaps the wider CMake CI integration work and should be planned alongside it.
The Cortex-R52 port has an automated FVP regression suite, but no GitHub workflow builds or runs it. The checks that report on a Cortex-R52 pull request are the generic
atfe, Cortex-M, Cortex-A, host regression, SMP, FreeRTOS and ECA jobs, none of which configures an R52 toolchain, names theEXCLUDE_FROM_ALLexample images, or executes their CTest entries. The suite can therefore stop compiling, or its module isolation test can start failing, with every required check still green.Suggested sequencing
1. Hosted cross-build lane, first.
ci_cortex_m.ymlis build-only and is the existing precedent: install a pinned GNU Arm toolchain, configure withcmake/cortex_r52.cmake, build the explicit image list. Two configurations are worth having, because the default seven-image build leaves several paths uncovered:-DTX_R52_BUILD_FVP_EXAMPLE=ON -DTX_R52_BUILD_FVP_MODULE_EXAMPLE=ON-DTX_R52_ENABLE_VFP=ON -DTX_R52_ENABLE_FIQ=ON -DTX_R52_ENABLE_IRQ_NESTING=ON -DTX_R52_ENABLE_FIQ_NESTING=ON, which covers VFP context save/restore, the FIQ path and both nesting pathsA compile-only S32Z280 lane (
-DTX_R52_BUILD_S32Z280_EXAMPLE=ON, five targets) belongs here too.2. FVP execution, second and separately. This is a new capability for the repository — nothing currently executes a cross-target image in CI.
FVP_BaseR_AEMv8Ris a licensed Arm download rather than a package that can simply be installed in a hosted runner, so execution most likely needs a self-hosted runner. Keep the cross-build lanes hosted and required regardless of how execution is resolved.The CTest entries already exist: the runner judges each image by its self-reported result line and treats a missing line as a failure, so a hang cannot pass.
This overlaps the wider CMake CI integration work and should be planned alongside it.