RTEMS | score/cpu: Validate the SPARC and RISC-V CPU ports (!1535)

Sebastian Huber (@sebhub) gitlab at rtems.org
Mon Oct 12 04:12:32 UTC 2026



Sebastian Huber created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1535

Project:Branches: sebhub/rtems:up/sparc-riscv-cpu-validation to rtems/rtos/rtems:main
Author: Sebastian Huber

## Summary

Issue #5808: The context switch loses the FSR

Issue #5809: A synchronous exception overwrites the stack of the trapped context

The first two commits extend the validation support. The register check runs
a scenario once per register with the pattern of that register inverted,
then once unchanged. Its report requires that each changed run flags exactly
the checks of its register. A test therefore proves that each of its checks
can fail. The task life support functions restart a task and request life
changes within an interrupt.

The SPARC part fixes the FSR in the context switch and the Y register in the
SMP exception frame, and adds `_CPU_Exception_resume()`. Two erc32 commits
make its tm27 support self-contained and provide its interrupt vector. The
last SPARC commit adds the generated tests of the context switch, the
interrupt processing, the register windows, the default exception handler
and the exception resume. The floating-point unit of the ERC32 implements
no NS bit, so the tests compare the NS bit only where the floating-point
unit implements it.

The RISC-V part moves the interrupt frame to the end of the exception frame,
so a synchronous exception no longer writes above the stack pointer of the
trapped context. It adds `_CPU_Exception_resume()` and the generated tests
of the context switch, the interrupt processing, the exception resume and
the initial `fcsr`.

## Test

The base is `main` at acb78c0c8c7. Each commit builds on its own for
`sparc/gr740`, `sparc/erc32`, `riscv/rv64imafdc` and `riscv/rv32i` with no
warning. The tip builds 11 variants with no warning.

| Target | Variants | CPU test cases |
| --- | --- | --- |
| SIS | `sparc/gr740`, `sparc/gr712rc` SMP, `sparc/leon3`, `sparc/erc32` | 7 of 7 pass, `ts-validation-no-clock-0` passes |
| Qemu `virt` | `riscv/rv32i`, `riscv/rv32imafdc`, `riscv/rv64imac`, `riscv/rv64imafdc` | 3 of 3 pass, `ts-validation-no-clock-0` passes |
| Qemu `virt` | `riscv/rv64imafdc` SMP, `riscv/rv64imafdc` S-mode SMP under OpenSBI | 3 of 3 pass |

All 24 validation test suites of `sparc/erc32` pass, as on `main`. In the
tests of the CPU ports, a planted check which compares a value with itself
makes the report name that register alone. Without the restore of `a5` in
the RISC-V interrupt wrapper, the RISC-V interrupt test fails on `a5`.

These failures occur on `main` as well. `ts-validation-no-clock-0` ends with
an illegal instruction in `ScoreThreadValThread` on `riscv/griscv` without
SMP. It stops in `RtemsSemReqTimeout` on `riscv/rv64imafdc` SMP.
`RtemsSchedulerReqRemoveProcessor` fails three times in S-mode SMP.

## AI Details
<!-- Make sure you have read our statement at https://www.rtems.org/generative-ai/ -->

### Prompt used

None as a single prompt. The work was done in an interactive Claude Code
session on the RTEMS tree. The task was to specify and validate the
exception, interrupt and context switch processing of the SPARC and RISC-V
CPU ports, and to fix the defects which the tests found. Each change was
directed and reviewed.

### AI model used

Claude Opus 5.5 (claude-opus-5-5), through Claude Code.

### How AI was used for the contribution

- ( ) Formatting
- (x) Test creation.
- (x) Code comments.
- ( ) The entire contribution was generated using AI
- ( ) AI code completion such as Copilot in VSCode.

The implementation, the specification of the tests and the verification
were produced in that session under my direction, and the commit messages
were drafted there.

### Access

I have not used a product which claims copyright in its output, and I have
legitimate access to the one I used.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1535
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/6-92wd070lbbjsekn1b9lxuh55a-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20261012/16a5f411/attachment-0001.htm>


More information about the bugs mailing list