Cortex-R52 has no CI that executes its regression suite #668

The Cortex-R52 port has an automated FVP regression suite, but nothing executes it. Since this issue was filed, #675 added scripts/check_gcc.sh and ran it in CI, which closes the build half of the gap. The execution half is untouched, and that is what this issue now tracks.

What is now covered, by scripts/check_gcc.sh

• Assembly. Every .S of every Arm gnu port is assembled, and the enumeration includes ports_module/*/gnu/module_manager/src — so the Cortex-R52 module port's assembly is covered along with the base port's.
• Common C sources, compiled for cortex_r52 among one core per architecture profile.
• CMake example builds, cortex_r52: the image list is read out of the ninja graph rather than hardcoded, so EXCLUDE_FROM_ALL cannot hide a target and adding one cannot silently escape the check.
• Configure-time option guards, since Asserted that the Cortex-R52 port refuses the options it documents as refused #687: the two combinations the port refuses (TX_R52_ENABLE_VFP without a hard float ABI, TX_R52_ENABLE_FIQ_NESTING without TX_R52_ENABLE_FIQ) are asserted to be refused, on the error text and not just the exit status, alongside a positive case so a guard cannot pass by rejecting everything.

That is a real cross-build lane and it removes the "the suite can stop compiling with every check green" half of the original report.

What is still not covered

1. The module example images. The CMake stage configures -DTX_R52_BUILD_FVP_EXAMPLE=ON -DTX_R52_ENABLE_MPU=ON and does not pass TX_R52_BUILD_FVP_MODULE_EXAMPLE, so fvp_module.elf, fvp_module_properties.elf and fvp_demo_module.elf are built by no check. Their assembly is assembled, but nothing links them. Adding the option to that stage is a one-line change and is the cheapest remaining win.

2. The feature configuration. Only the default configuration is configured. The VFP, FIQ, IRQ-nesting and FIQ-nesting paths are built by no lane. Note that TX_R52_ENABLE_VFP requires TX_R52_FLOAT_ABI=hard, which since #686 the port's CMake enforces with a FATAL_ERROR — a VFP lane configured with the soft ABI will now fail at configure rather than build something that does not exercise the VFP path.

3. The S32Z280 example. -DTX_R52_BUILD_S32Z280_EXAMPLE=ON (five targets) is built by no lane.

4. Execution — the substantive gap. check_gcc.sh compiles and links; it executes nothing, and its own header says so. No workflow runs the FVP CTest suite, so the module isolation test can start failing with every required check still green. This remains a new capability for the repository: FVP_Base_AEMv8R_11.32_19 is a licensed Arm download rather than a package a hosted runner can install, so it most likely needs a self-hosted runner.

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.

Suggested sequencing

Items 1 to 3 are small extensions to the lane that now exists and should go first. Item 4 is the one that needs a decision about runners, and should be planned alongside the wider CMake CI integration work.