threadx.git/ports/cortex_r52/gnu/readme_threadx.txt, branch master

Added a ThreadX module manager port for the Cortex-R52 (#639)

2026-09-17T19:39:30Z

Added the first GNU ThreadX module port for an Arm R-profile core. The port combines the PMSAv8-R MPU model from Cortex-M33 with the AArch32 privilege and processor-mode handling from Cortex-R4. It provides the complete module path: headers, manager sources, scheduler integration, user-mode entry, SVC dispatch, data- and prefetch-abort capture, fault notification, relocatable module loading, and shared-memory regions. Module isolation uses eight MPU regions (8–15) with a 64-byte granule. The scheduler replaces those regions on each module switch and manages a separate privileged loading window in region 16. Assembly-visible structure offsets and region-layout assumptions are checked at build time. Added independent module demonstrations for the S32Z280-594EVB and Armv8-R AEM FVP. The automated FVP regressions cover: - Loading the same position-independent module at different addresses - User-mode data and instruction access violations - Fault capture and notification for both abort types - Shared-region access, alignment, exhaustion, empty-size, and overflow handling - Required module-property combinations - The GCC CLZ-based priority search The port requires user mode and memory protection together, at least 17 EL1 MPU regions, and currently validates A32 modules; Thumb module execution remains unvalidated. Validated with GNU Arm 14.3.1. The FVP suites pass 8/8 in the default configuration and 11/11 with hard-float, FIQ, and interrupt nesting enabled. The S32Z280 images build cleanly, and the module isolation and relocation paths were exercised on S32Z280 silicon during development. Matching user documentation is provided by rtos-docs-asciidoc PR #41. Assisted-by: Claude Code (Opus 5)

Refused the Cortex-R52 VFP option without a hard float ABI (#686)

2026-09-01T12:48:20Z

TX_R52_ENABLE_VFP with the default soft float ABI cannot build. The option defines TX_ENABLE_VFP_SUPPORT, which enables the VMRS, VSTMDB and VLDMIA blocks in the port assembly, and -mfloat-abi=soft leaves the assembler with no FPU to accept them. The configuration fails with eight errors of the form tx_thread_system_return.S:118: Error: selected processor does not support `vmrs r4,FPSCR' in ARM mode none of which mentions the float ABI, so a user has to reason from VMRS back to the option that enabled it. The guard that exists said otherwise. It warned that "the compiler will not emit floating-point instructions, so the VFP context path will never be exercised", which describes a build that succeeds and is merely pointless -- and then let configure finish, so the warning scrolled past well before the assembler errors appeared. It is now a FATAL_ERROR that names the fix, which is what the same file already does six lines above for TX_R52_ENABLE_FIQ_NESTING without TX_R52_ENABLE_FIQ. That combination is rejected for being "meaningless", while this one, which cannot assemble at all, was only warned about. The severities were the wrong way round. The option's definition also moves below the check, so the block reads like the FIQ nesting one. The ABI is not promoted to hard automatically. TX_R52_FLOAT_ABI is a cache variable the user may have set deliberately, and silently overriding an explicit choice is worse than refusing a combination that cannot work. readme_threadx.txt carried the same claim, and its option list marked the FIQ nesting dependency inline but not this one. Both corrected. No regression test. Nothing in the tree asserts a configure-time failure -- there is no harness for it, and the sibling FIQ nesting guard has none either -- so a test for this would have to introduce that mechanism for one case. Verified by hand in both directions instead: the soft-ABI combination now stops at configure with the message above, and the hard-ABI feature build (VFP, FIQ, IRQ nesting, FIQ nesting) builds its eight images clean and passes ctest 8/8 on the Armv8-R AEM FVP. scripts/check_gcc.sh passes unchanged; it configures the Cortex-R52 CMake stage without TX_R52_ENABLE_VFP, so the new branch is not on its path. Assisted-by: Claude Code (Opus 5)

Added Cortex-R52 port with Armv8-R AEM FVP example build (#579)

2026-08-08T12:00:01Z

Added a ThreadX port for Arm Cortex-R52 with the GNU toolchain Adds ports/cortex_r52/gnu together with a CMake build, an example build for the freely available Armv8-R AEM FVP, and an automated test suite. The port is EL2-aware by construction. Cortex-R52 always implements EL2 and resets into it, so the reset path configures EL2, installs both the EL2 and EL1 vector tables, and only then drops to EL1 to run the kernel. Keeping that structure from the start lets partitioning work reuse the boot path rather than replace it; TX_R52_BOOT_AT_EL1 skips the EL2 stage where a vendor monitor has already dropped privilege. This is also the first R-profile port in the tree with a working CMake build. cmake/cortex_a9.cmake exists but ports/cortex_a9/gnu/CMakeLists.txt is empty, so no A- or R-profile port could be built this way before. Contents: - Kernel port: 16 assembly sources plus tx_port.h, seeded from the Cortex-R5/GNU port. - Build: cmake/cortex_r52.cmake and the port CMakeLists.txt, with soft/hard float, VFP, FIQ and IRQ/FIQ nesting options. - Example BSP: EL2 to EL1 boot, GICv3, generic timer, PMSAv8-R MPU, semihosting and PL011 consoles. - Tests: six images registered with CTest, each judging itself and terminating the model. - tx_port_offset_check.c: compile-time assertions on the TX_THREAD offsets the assembly reaches by hard-coded displacement. This is the same defect class fixed for Cortex-R4/R5 in #578; nothing in the toolchain ties those literals to the C structure. Two facts were established by experiment rather than taken from documentation, and are recorded in the code and the readme because both are traps: - PRBAR.AP bit order is reversed relative to th AArch64 macro set: the low bit is read-only and the high bit grants EL0 access. Programming four disjoint regions, one per encoding, and attempting a privileged write to each gave 0b and 0b10 allowed. Using the AArch64 ordering as read-only and silently accept writes, because region coverage is still enforced: an unmapped address faults while a "read-only" region does not. - The generic timer PPI is INTID 30, recorded from ICC_IAR1 after enabling the whole PPI range 25-31, rather than assume Model behaviour that a silicon port must revisit: the FVP leaves CNTFRQ at zero with the system counter stopped, so the BSP programs both; CNTHCTL.PL1PCTEN, CNTHCTL.PL1PCEN and ICC_HSRE must be set at EL2 or EL1 accesses trap; and tx_thread_vfp_enable() sets only a per-thread software flag, so enabling the FPU hardware (CPACR, FPEXC.EN) is the board support package's responsibility, not the kernel's. The FVP reports MIDR 0x410FD0F0, an architecture envelope model rather than a Cortex-R52, so it validates architecture and not implementation. Nothing in the port is gated on MIDR. Changes outside ports/cortex_r52, three and all small: cmake/cortex_r52.cmake is a new toolchain file; CMakeLists.txt gains enable_testing() at the top level, without which add_test() in a subdirectory generat the root never references, so ctest reports no tests from the build root; and .gitignore covers build directories and __pycache__. Verification: all six images build warning-free a FVP_BaseR_AEMv8R in three configurations -- protection off, protection and caches on, and both together with hard-float VFP. Six build-option combinations build clean and pass the tick-and-preemption demo at run time. The tests assert behaviour rather than configuration, which is what caught the problems above: the cooperative demo asserts the order of execution, because counting alone cannot distinguish working context switches from one thread running to completion, and the MPU test provokes real faults, because reading SCTLR back only proves a bit was set. The 96-test regression suite is host-side and pas configurations on the Linux port. It is not cross-run here: it validates portable kernel logic, while the port-specific risk is the assembly, which the FVP images exercise. Structural coverage is therefore not claimed. Deliberate deviations: passing a string literal to tx_thread_create reports a discarded const qualifier from common/inc/tx_api. CHAR *; demo_threadx.c keeps the shipped sample's int main() so the demo body stays byte-identical to it; and the floating-point test compares exactly on purpose, since a tolerance would mask a restored wrong. Not included: modules support, split-mode SMP and support. The example targets the FVP only, and NXP S32Z280 bring-up is separate work; the readme flags what to re-verify there. Assisted-by: Claude Code (Opus 5)