Skip to content

Conversation

thenewwazoo
Copy link

@thenewwazoo thenewwazoo commented Aug 29, 2025

This change adds very, very basic support for the Raspberry Pi Pico 2's RP2350 chip and its 4 MiB onboard flash. A new demo app is added with only jefe and idle tasks. This is mostly intended as a basis for discussion of #2200.

Nonetheless, it runs and passes tests!

$ cargo xtask humility app/demo-pi-pico-2/app.toml -- tasks
    Finished `dev` profile [optimized + debuginfo] target(s) in 0.13s
     Running `target/debug/xtask humility app/demo-pi-pico-2/app.toml -- tasks`
humility: attached via CMSIS-DAP
system time = 859044
ID TASK                       GEN PRI STATE
 0 jefe                         0   0 recv, notif: fault timer(T+56)
 1 idle                         0   5 RUNNING

NOTE that this is intended to pair with an as-yet-unsubmitted update to humility, the status of which is likely uncertain.

Additional minor tweaks include:

  • some error reporting when files can't be found (emitting the sought filename)
  • emitting a firmware map in the dist directory

This change adds very, very basic support for the Raspberry Pi Pico 2's
RP2350 chip and its 4 MiB onboard flash. A new demo app is added with
only jefe and idle tasks.
The RP235x chips use external flash, which means the flash size is a
property of the board. This change renames the `memory.toml` file to
something that indicates more clearly that the setup is particular to
the Pico 2 board.
This change adds the test suite for the RPI, and tweaks the memory
config to set RAM as XN so that the execdata test passes.
Copy link
Contributor

@aapoalas aapoalas left a comment

Choose a reason for hiding this comment

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

Left a couple of comments from an outsider.

IMO this is pretty damn cool, and I'll try take this for a spin if I get the time.

Great stuff getting Hubris working on RPi <3 !

/// section 5.9.5. Minimum viable image metadata.
#[link_section = ".image_def"]
#[used]
pub static RP235X_IMAGE_DEF_ARM_MIN: [u32; 5] = [
Copy link
Contributor

Choose a reason for hiding this comment

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

suggestion: This seems like it should rather be a repr(C) struct with named fields instead of an array with commented indexes.

nitpick: I'd personally go with usize types since these seem to be addresses, though the Hubris codebase does use u32 for addresses very often. It makes sense in the APIs but (IMO) less so inside the services / tasks.

Copy link
Author

Choose a reason for hiding this comment

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

I agree, this should eventually be a repr(C) struct since it encodes fields with values and flags (in 5.9.3.1). For now I've gone with the raw bytes described in the datasheet (5.9.5.1) since it's an MVP and I'm not even sure Oxide wants this in their repo 😆 If I get any sort of encouragement from them, I expect I'll expand on this and other aspects of the PR.

As for u32 vs usize, in the ultimate structure, it'd be a mix of types, with u8/u16/u32 for values and usize for the address, as noted. For now, it's just u32 bytes straight out of the datasheet.

@thenewwazoo
Copy link
Author

Left a couple of comments from an outsider.

IMO this is pretty damn cool, and I'll try take this for a spin if I get the time.

Great stuff getting Hubris working on RPi <3 !

Thank you! Please note that I got this working alongside an update to humility that is required for it to work, and which is its own ball of wax.

Your suggestion for exhubris is well-heard, and I'm sorry for not responding earlier. I was... focused... on getting hubris booting. I like the idea and goals of exhubris, but it is quite a different product with a different learning curve, and its future and relationship with hubris itself isn't entirely clear (authorship notwithstanding). I decided to just EAFP and see how it went.

@aapoalas
Copy link
Contributor

Your suggestion for exhubris is well-heard, and I'm sorry for not responding earlier. I was... focused... on getting hubris booting. I like the idea and goals of exhubris, but it is quite a different product with a different learning curve, and its future and relationship with hubris itself isn't entirely clear (authorship notwithstanding). I decided to just EAFP and see how it went.

Sorry for being vocal about it as well. I removed the section about it in the above comment (as you of course noticed) because after posting it I realised it's not really my place to try tell you what to do. Let's hope this gets some bandwidth from the Oxide folks! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants