Support for Raspberry Pi Pico 2 aka RP235x

[thenewwazoo]

I'm fairly far along porting Hubris to a Raspberry Pico 2 board (specifically a W, but that's "just" a Pico 2 with an SPI-attached radio), and want to check in to see if contributing such a port would be welcome. I understand that Hubris is not intended to be all things to all people, but the Pico 2 seems potentially relevant because:

• the RP235x chips are veeeerrrry popular by dint of being supported by the RPi foundation
• the Cortex-M33 has an MMU, which the RP2040 lacks
• a (now-outdated, draft) RP2040 port exists
• there are interesting secure boot features that may be appealing to Hubris users
• it's possibly a good jumping-off point for RISC-V and multi-core support to already have a cheap board supported

There are a few questions/concerns that have arisen as I've worked:

• I've got most of a porting guide doc in my head - do you want one?
• It's basically necessary to build apps/tasks in a fork anyway; should ports stay in forks as a rule? (e.g. here's hubris-flipper). Being able to build apps and tasks out-of-tree would be cool.
• Peripheral abstractions can range from vry smol to exceptionally exhaustive. The e.g. LPC55 abstractions appear to be fairly extensive; how much of the RP235x datasheet should be encoded in this repository given that y'all don't use it?

[aapoalas]

I expect this would be more welcome in https://github.com/cbiffle/exhubris/

I would personally be pretty interested in that as I have an unused Pico 2W (IIRC) gathering dust in my closet :)

[thenewwazoo]

I've submitted PR #2210 as a starting point.

Updating humility to use a modern version of probe-rs was not very hard, but I wasn't able to definitively determine whether the changes in Oxide's fork have been obviated in the intervening years. The Raspberry Pi Debug Probe is neat, and works with no effort once humility is up-to-date. I'm cleaning up that PR now.

ETA: I intend to start working on tests next. I haven't tried yet.

[thenewwazoo]

Tests pass!

[thenewwazoo]

My plans are starting to solidify now that the chip boots, so I think I'll write them down.

There are a set of "headline" features of the RP2350 (the chip) separate from the "headline" features of the Pico 2 and Pico 2 W (the boards). The RP2350's headline features are, in no particular order and off the top of my head, the PIO cores, its dual ARM Cortex/RISC-V nature, and its secure boot features. These features have interesting implications when applied to Hubris that may be valuable but none are useful to my own goals. The Pico 2 is little more than a breakout for the RP2350 with a flash chip attached. In contrast, the headline feature of the Pi Pico 2 W is the SPI-attached Infineon CYW43439.

I have a pair of Pico 2 Ws that I intend to use to build a widget because it's fun but also as a sort of "portfolio project" as I look for work (preferably in the embedded space).

Exercising the CYW43439 to either run a simple network service or run a simple BLE server seems a reasonable goal to include in a demo application and as a framework for developers to start from. In order to accomplish that goal, I'd need:

• GPIO configuration
• SPI configuration
• A BLE and/or network stack, API, and service
• A "business logic" task

Since Hubris already has a dependency on smoltcp, a simple network application feels like the more obvious choice. The net-related tasks appear to be reasonably tightly coupled to the stm32h7's ethernet peripheral, so I predict I won't be able to reuse very much of them without significant refactoring to write some new abstractions to split out the PHY from the IPC.

It's at this point that I'll pause and note that I'm talking about a possibly-significant amount of code. I fully intend to continue writing it; the question becomes one of submitting it upstream.

[Karthik-d-k]

Wow, this is really nice work 🙂

I’m also working on adding support for the pico 2 w board, but I started from exhubris since it felt easier to experiment with changes there compared to hubris. My main goal is to bring up support for the RISC-V hazard3 core on the RP2350 chip.

So far, I’ve managed to get quite far — both the jefe and idle tasks run fine without issues on the RISC-V core. My code is here: exhubris-riscv-hazard3

I couldn’t get humility working for me, but now that you’ve done that part, I’ll try to reuse your setup and also check whether the Cortex-M33 core works correctly. I’ve already added quite a bit of support for both ARM and RISC-V, though so far I’ve been using openocd + gdb for flashing, running, and debugging.

Right now I’m trying to blink an external LED on GPIO22. That works fine as a standalone application, but under Hubris — once the kernel schedules my blinky task — I hit a trap (mcause=7) on a simple store instruction (sw a3,180(a2) # 400280b4). Still digging into what’s going on 😢

UPDATE: I have just added blinky task on top of your repo to verify that the issue is not w.r.t. my task but something to do w/ my riscv port !!