Skip to content

Conversation

AnnsAnns
Copy link
Member

Contribution description

This is the very first draft proposal to support the rp2350 using the Hazard3 RISCV Mode.

This is actually the third or fourth attempt at this. I initially wanted to combine both the ARM and RISCV code and that is still the long term vision for this, however, as my deadlines are closing in on me and the shared codefolder caused massive Makefile weirdness (twice even), this PR aims to at least make the code public(ly known).

This PR also adds support for the XH3IRQ Interrupt Controller used by the Hazard3. While fairly similar to CLIC/PLIC, the Hazard3 on the RP2350 actually has a custom interrupt controller to "mimick" the way interrupts work on the Cortex ARM side, even having support for direct vector table jumps (Not enabled here since I wanted to still use the trap_entry/trap_handler of riscv_common.

Testing procedure

Issues/PRs references

@github-actions github-actions bot added Area: doc Area: Documentation Area: build system Area: Build system Area: boards Area: Board ports Platform: RISC-V Platform: This PR/issue effects RISC-V-based platforms Area: cpu Area: CPU/MCU ports Area: Kconfig Area: Kconfig integration labels Sep 26, 2025
@AnnsAnns AnnsAnns changed the title RP2350: Add RISCV support RP2350 (RISCV): Add initial support & XH3IRQ Interrupt Controller support Sep 26, 2025
@crasbe crasbe added the Type: new feature The issue requests / The PR implemements a new feature for RIOT label Sep 26, 2025
#include "sched.h"
#include "plic.h"
#include "clic.h"
#include "xh3irq.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be conditional, otherwise the compiler might do weird stuff for other RISC V CPUs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The part that confuses me is that plic and clic aren't, thats why I also didnt do it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well it depends. If it's just definitions, it might not cause any issues. However some CPUs also have shared definitions (as in: they implement the API), and when you have an ifndef-define-endif structure, you might get the wrong values because something else was included first.

Hypothetical at this point, but prone to weird errors in the future.

@AnnsAnns
Copy link
Member Author

Superseeded by #21753, I did apply all the reviews mentioned here though. dont worry, thank you for the reviews so far :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: boards Area: Board ports Area: build system Area: Build system Area: cpu Area: CPU/MCU ports Area: doc Area: Documentation Area: Kconfig Area: Kconfig integration Platform: RISC-V Platform: This PR/issue effects RISC-V-based platforms Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants