The Cortex-R52 port's FVP suite is never executed in CI #712

The Cortex-R52 port ships a model test suite that CI never runs

ports/cortex_r52/gnu/example_build/fvp_baser_aemv8r/ carries a test runner, test/run_fvp_test.py, and registers every image it builds with CTest as r52-fvp-<image>, plus a check-r52-fvp target for running the set without CTest. The runner launches the Armv8-R AEM Fixed Virtual Platform, captures the console, and judges each image by its self-reported result — treating a missing result line as failure, so a hang cannot pass.

None of it runs in CI. No workflow in this repository references the FVP at all.

What CI does for the R-profile today is compile. ports_arch_check.yml builds the ports, clang_check.yml builds them again with a second toolchain, and ci_cortex_m.yml compiles and links the Cortex-M ports without executing them either. The suites that execute — regression_test.yml and its template — run the kernel and SMP regressions on the host, which is the right place for them and says nothing about a Cortex-R52.

So the R52 port's behaviour is covered by builds and by runs on a contributor's own machine, recorded by hand. Nothing catches a behavioural regression between those runs.

Why this is worth an issue now

Assume #639 is merged. It changes what an execution lane would have to cover, in two ways that matter.

The base image set grows: demo_clz.elf joins R52_IMAGES alongside boot_check, demo_m2, demo_m3, demo_threadx and demo_mpu.

And it adds a module manager example whose tests are gated behind an option that defaults to OFF:

option(TX_R52_BUILD_FVP_MODULE_EXAMPLE
       "Build the Armv8-R AEM FVP ThreadX module manager example" OFF)

When that option is on, fvp_module.elf and fvp_module_properties.elf are appended to R52_TEST_IMAGES. When it is off — which is the default, and therefore what a naive CI invocation gets — the module manager example is not built and not tested at all.

That is the part worth being explicit about. #639 is a PMSAv8-R Stage-1 isolation port: it isolates User-mode modules from the kernel and from each other. Isolation is behavioural by definition, and its two automated tests are the ones an option flag hides. A CI lane that builds the default configuration would report green over a module port it never compiled.

#639's own validation, for reference: two FVP configurations under CTest, the default at 8/8 and the VFP/FIQ/nesting configuration at 11/11. Those are the numbers an execution lane should be able to reproduce.

The S32Z280 module example is gated the same way, by TX_R52_BUILD_S32Z280_MODULE_EXAMPLE, and needs the board rather than the model — out of scope for a runner, and it stays a logged silicon run.

Why CI cannot run it as things stand

Arm distributes the AEM FVP free of charge, but behind a click-through licence and with no stable unauthenticated download URL, so there is nothing a GitHub-hosted runner can reliably fetch. Publishing a redistribution of Arm's archive is a question for the Foundation rather than a technical one for this repository.

What is being pursued

A Foundation-hosted runner with the model installed. Requested: eclipsefdn/helpdesk#7864. The request covers this repository and ZoneX together, since one runner serves both. A model already present on a persistent runner needs no download URL, which removes the redistribution question from the critical path rather than answering it; a Foundation-hosted mirror to point a URL variable at would serve equally well.

The same gap exists in the ZoneX repository, whose FVP lane builds twenty-four tests and executes none for exactly this reason. One runner would serve both, and the request is being made once rather than twice.

Deliberately not pursued: a runner maintained by the project. GitHub advises against self-hosted runners on public repositories, and every pull request here comes from a fork, so the isolation duty is real and belongs with infrastructure that is somebody's job rather than with whichever contributor owns a development board.

What closing it looks like

• An execution lane runs the R52 FVP images and reports each one's self-declared verdict.
• It configures with TX_R52_BUILD_FVP_MODULE_EXAMPLE=ON, so the module port is compiled and its two tests are among the ones that run. A lane that takes the default covers the base port only, and should say so if that is the intent.
• The VFP, FIQ and interrupt-nesting configuration is exercised as well as the default, since Added a ThreadX module manager port for the Cortex-R52 #639 validates both and they build different code.
• A missing result line stays a failure, which is the property that makes a hang detectable rather than green.
• Contributors without the model keep the existing build lanes rather than a red cross they cannot act on.
• Execution is constrained to whatever trigger the isolation model requires; push to dev and main is sufficient.