| Age | Commit message (Collapse) | Author |
|---|
|
The FVP module manager example and the S32Z280 kernel and module examples are each
behind a CMake option that defaults to OFF, and no CI lane turned any of them on. The
module isolation tests were therefore never linked, and nothing built the S32Z280
images.
Both r52_fvp configurations now enable all four example options. The FVP module
images join the CTest suite whenever the model is available; the S32Z280 images are
built and never run, since CTest registers only FVP images. The header no longer
describes these examples as pending.
On the Armv8-R AEM FVP 11.32 with GCC 14.3, the default configuration builds 14
images and passes 8/8, and the feature configuration builds 20 and passes 11/11,
with zero warnings. CI still builds without executing until FVP_AEMV8R_URL is set.
Assisted-by: Claude Code (Opus 5.5) <[email protected]>
|
|
Fixes #805
r52_fvp only ran the FVP when a repository variable pointed it at the model, and none
was set, so every run built the images and executed nothing. The workflow also
expected an unpacked model, but Arm ships the FVP as an installer script.
The workflow now downloads the 11.32_19 archive from Arm's public permalink, checks
it against a pinned SHA-256, and runs Arm's installer with its EULA accepted. The
cache is keyed on the checksum. A missing model now fails the job instead of
skipping execution. CONTRIBUTING.md no longer describes the repository variable.
The workflow's install, locate, and build-and-run steps, run locally as written,
download and verify the archive, install 11.32+19, and pass 6/6 default and 9/9
feature on the FVP. The installed binary is identical to the one used for local
validation of the port.
Assisted-by: Claude Code (Opus 5.5) <[email protected]>
|
|
pinned toolchain default serves (#718)
* Stated the compiler and coverage requirements instead of citing a file no contributor can open
Seven comments across five files cited a maintainer-local document as the
source for two project requirements: that GCC 14 on Linux is the default
compiler, and that the coverage target is 100%. That document is not part of
this repository and is not published anywhere, so the citation gave a reader
nothing to follow -- it named a source they cannot open, in place of simply
stating the requirement.
Both requirements are real and both stay. Only the pointer goes: each comment
now states the requirement on its own terms, which is what the surrounding
prose was already doing everywhere else.
cmake/cortex_r52.cmake the pinned reference toolchain
scripts/check_gcc.sh why the script exists
.github/workflows/gcc_check.yml why the workflow exists, and the
GCC_VERSION pin
.github/workflows/r52_fvp.yml the GCC_VERSION pin
.github/workflows/regression_template.yml the coverage floor, twice
Comments only; no behaviour changes. Two paragraphs are rewrapped where the
shorter text left a ragged line. Verified that scripts/check_gcc.sh still
parses and prints its help from the header range it slices, and that
cmake/cortex_r52.cmake still configures the Cortex-R52 build.
Assisted-by: Claude Code (Opus 5) <[email protected]>
* Said who the pinned toolchain default in the CMake toolchain files serves
Both cmake/cortex_r52.cmake and cmake/cortex_m52.cmake default
ARM_TOOLCHAIN_PATH to a toolchains directory under the user's home, guarded by
an EXISTS check. Nothing said whether CI relies on that, and the natural
reading is that it does.
It does not. The three workflows that install a toolchain unpack it into the
workspace and cache it there, and r52_fvp.yml puts that directory on PATH
before configuring; scripts/check_gcc.sh passes -DARM_TOOLCHAIN_PATH at each of
its three CMake call sites. On a runner the guarded directory is absent, the
EXISTS check falls through, and the compiler comes from PATH. The default only
ever fires on a developer machine, where it is what makes a no-flag build work.
Both comments now say that, so the default is not mistaken for a CI dependency
and not removed as dead code. cortex_r52.cmake carries the explanation and
cortex_m52.cmake refers to it, matching the cross-reference already there.
The r52 comment also claimed absolute paths mean "the build does not depend on
PATH ordering", which is only true where the pinned directory exists -- in CI
the build depends on PATH and nothing else. Qualified accordingly.
Comments only; no behaviour changes. Verified that both toolchain files still
configure, and that the fall-through is real: with HOME pointed at a directory
holding no toolchains, cortex_r52.cmake configures against the arm-none-eabi-gcc
found on PATH.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
* Added a workflow that runs the Cortex-R52 images on the Armv8-R AEM FVP
Nothing in CI executed a single instruction of any ThreadX port. gcc_check
compiles and links -- its own header says it "executes nothing" -- and its
CMake stage covers one R52 configuration, the base FVP example. A change that
assembles cleanly, links cleanly and then hangs on the first context switch
passed every required check.
This workflow builds both supported configurations and runs them on the
Armv8-R AEM FVP, asserting each image's self-reported result. The feature
configuration matters as much as the default one: VFP with the hard float ABI,
FIQ, IRQ nesting and FIQ nesting gate whole assembly blocks that the default
configuration never assembles, and it builds eight images where the default
builds five.
Arm distributes the model free of charge but behind a click-through licence
with no stable unauthenticated URL -- the developer.arm.com permalink forms
all 404 for it -- so the download location is a repository variable rather
than a literal. When it is unset the build lanes still run and still gate the
pull request; only execution is skipped, and it says so in the log and in the
job summary rather than passing quietly.
The image list is read from the generated ninja graph rather than kept in the
workflow. The images are EXCLUDE_FROM_ALL, so a bare build reports "no work to
do", and reading the graph means a target added to CMakeLists.txt cannot
escape the check by nobody remembering to list it here.
The module manager port and the S32Z280 targets are not on dev yet. Their
lanes belong in this workflow when they land, not in a second one.
Assisted-by: Claude Code (Opus 5) <[email protected]>
* Kept the FVP cache honest and stopped ctest passing on an empty suite
Two corrections to the new workflow.
The FVP cache key named the URL and hashed the workflow file. hashFiles()
reads files, so it cannot hash a repository variable, and pointing it at
this workflow keyed the cache on the file's own contents instead. That is
wrong in both directions: repointing FVP_AEMV8R_URL at a different model
kept serving the old one from cache, which is exactly what the comment
claimed the key prevented, and editing anything in this file forced a
needless refetch of a large archive. A small step hashes the URL and the
key uses that, so it now tracks what it names.
ctest reported success when it found nothing to run. Its default is to
pass an empty suite, and the example registers its tests inside both
if(FVP found) and if(Python3_FOUND). Either one going unmet on a runner
would have left this stage green having executed no image at all, which
is the hole the workflow exists to close. --no-tests=error makes an empty
suite a failure.
Verified with the pinned toolchain, Arm GNU 14.3.rel1: both configurations
configure, enumerate and build, and the image lists are the ones claimed.
default: 5 images boot_check demo_m2 demo_m3 demo_mpu demo_threadx
feature: 8 images the above plus demo_fiq demo_m5 demo_nesting
Also checked that the target enumeration survives the real ninja graph:
the generated graph offers twenty .elf paths, and the filter reduces them
to those eight, dropping the cmake_object_order_depends_target aliases and
the CMakeFiles copies.
Assisted-by: Claude Code (Opus 5) <[email protected]>
---------
Co-authored-by: r <r@r>
|
