4 ms·

Rust on the RP2350 (2024)

148 points by fanf2 2y ago

sph 2y ago
Can anyone explain how the dual ARM/RISC-V system works, architecturally? Are there two actual CPUs on the same die? Is it one shared architecture with two different instruction decode stages, one for ARM and the other for RISC-V that can be toggled at boot time? I like the idea conceptually but I'm not sure how much of that is a hack and/or inefficient compared to a pure ARM or RISC-V core.
- dcan 2y ago
  To be more precise, four CPUs - two ARM and two RISC. There is just a mux for the instruction and data buses - see chapter 3 of the [datasheet](https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p...). It’s space-inefficient as half of the CPUs are shutdown, but architecturally it’s all on the same bus.
  - Narishma 2y ago
    It may be technically space inefficient but they only added the RISC-V cores because they had area to spare. It didn't cost them much.
    - petertodd 2y ago
      I wonder if they're using the same die for one or more microprocessor products that are RISC-V-only or ARM-only? They could be binning dies that fail testing on one or the other cores that way. Such a product might be getting sold under an entirely different brand name too.
      - baby_souffle 2y ago
        That may be the plan for the future. Right now, this is a hedge / leverage against negotiations with ARM. For developers looking to test their code against a new architecture and compare it to known good code/behavior, it doesn’t get any easier than rebooting into the other core!
      - jsheard 2y ago
        They're not currently doing that but there is a documented way to permanently disable the ARM cores, so they could sell a cheaper RISC-V-only version of the same silicon if there's enough demand to justify another SKU.
    - enragedcacti 2y ago
      Source for the RISC-V cores being essentially free (Luke Wren is the creator of the RISC-V core design used): > The final die size would likely have been exactly the same with the Hazard3 removed, as std cell logic is compressible, and there is some rounding on the die dimensions due to constraints on the pad ring design. https://nitter.space/wren6991/status/1821582405188350417 https://nitter.space/wren6991/status/1821582405188350417
    - Graziano_M 2y ago
      Funny thing is that it cost them more than you might think. It was the ability to switch to the riscv which made it (much) easier to glitch. See the "Hazardous threes" exploit [1] [1] https://www.raspberrypi.com/news/security-through-transparency-rp2350-hacking-challenge-results-are-in/ https://www.raspberrypi.com/news/security-through-transparen...
  - myrmidon 2y ago
    I find this whole concept remarkable, and somewhat puzzling. Have seen the same (ARM + RISC-V cores) even at larger scales before (Milk-V Duo @1GHz-ish). But how is this economical? Is die space that cheap? Could you not market the same thing as quadcore with just minor design changes, or would that be too hard because of power budget/bus bandwidth reasons?
    - bananapub 2y ago
      two things: 1) it needs a certain perimeter to allow all the pins to go from the silicon to the package, which mandates a certain sized square-ish die 2) only the cores are duplicated (and some switching thing is added) so yes, there is enough space to just add another two cores without any worries, since they don't need more IO or pins or memory or anything.
    - imtringued 2y ago
      SRAM is very area intensive. What you're asking for is very greedy. The RISC-V core they are using is absolutely tiny.
      - myrmidon 2y ago
        Thats also a good point. For the big Milk-V systems I mentioned they use external DRAM-- but cache might still be a die-space issue (I'd assume that it's always shared completely between ARM/RISC-V cores, and would need to be scaled up for true multicore operation). But I'm still amazed that this is a thing, and you can apparently just throw a full core for a different architecture on a microcontroller at basically no cost :O
  - Aurornis 2y ago
    > It’s space-inefficient as half of the CPUs are shutdown In practice is doesn't matter very much for a design like this. The size is already limited to a certain minimum to provide enough perimeter area to provide wire bonding area for all of the pins, so they can fill up the middle with whatever they want.
    - DrNosferatu 2y ago
      They should have filled it with more SRAM instead - 520KB is far too little.
      - Tharre 2y ago
        What difference would the extra 16KiB or whatever instead of the 2 RISC-V cores make? If 520KB is far too little for you, you're likely better off adding a 8 MiB PSRAM chip.
        DrNosferatu 2y ago
        Just 16KB? Couldn’t a lot more be fitted? PSRAM has huge latency.
        timschmidt 2y ago
        SRAM takes up a tremendous amount of space compared to logic. Usually at least six transistors per bit, plus passives, plus management logic.
        Lerc 2y ago
        SRAM is big in gate count. typically 6 transistors per bit. The i386, a 32 bit chip already dragging around a couple of generations of legacy architecture came in at 275,000. I would imagine the Hazard3 would be quite a bit more efficient in transistor usage due to architecture. 16K is 16384(bytes) *8(bits per byte) *6(transistors per bit) = 786, 432
        2y ago
- MisterTea 2y ago
  > Can anyone explain how the dual ARM/RISC-V system works, architecturally? What I really want to know is why would anyone need or want dual architectures on one chip?
  - pjc50 2y ago
    This is hedging their bets. Tapeouts are expensive. It seems that they had spare area, so they decided to add RISC-V as a sort of feature test and market test; that lets them determine what the market preference is between the two and acquire geek coolness points (plus an additional point for using Rust) at relatively low cost, certainly lower cost than doing two tapeouts for two different SKUs. Here at $MEDIUM_SIZED_CHIP_CO, we also have some products which have a custom DSP for realtime audio processing and an ARM for "other stuff". It's more common than you think. Even the very first Pi was effectively a video-oriented vector processor with a small ARM glued on the side.
    - snvzz 2y ago
      If anything, they must have learned by now that they can simply drop the ARM cores and go full RISC-V. As long as they make their core at least feature-equivalent by implementing FPU and the secure boot chain.
      - MisterTea 2y ago
        They certainly can but the end users likely can't. I am sure there are a lot of projects that make Arm assumptions and porting isn't as simple as changing compilers. And is Risc-V tooling as mature as Arm? Doubtful. So releasing a pure Risc-V micro is Risc-Y at this time. However, giving end users both in the same chip eliminates any risk because it allows the Risc-V tooling to develop at the same time. And if that development fails, oh well, the Arm cores will keep working and the next tapout might exclude the Risc-v cores. Life moves on.
        snvzz 2y ago
        >is Risc-V tooling as mature as Arm? RISC-V is rapidly growing the strongest ecosystem.
password4321 2y ago
Which of the four RP2350 variants is used in the Raspberry Pi Pico 2 W? I see RP2350A0A2⁰ and (pardon my ignorance) guess that means SKU RP2350A package QFN60, the one with the least features. ⁰ https://datasheets.raspberrypi.com/picow/pico-2-w-schematic.pdf https://datasheets.raspberrypi.com/picow/pico-2-w-schematic....
- maeln 2y ago
  Most picture I find seem to show the RP2350A variant for the W and non-W version.
- moefh 2y ago
  As far as I know, any Pico 2 currently sold carry the RP2350A: 30 GPIOs, no internal flash since the board carries an external flash chip. (BTW two of the variants are called RP2354 and not RP2350, the last digit means the amount of internal flash)
teleforce 2y ago
Previous post on HN: Raspberry Pi Showcases Rust on the RP2350 Microcontroller (9 comments): https://news.ycombinator.com/item?id=41476505 https://news.ycombinator.com/item?id=41476505
mastax 2y ago
thejpster, where do I know that username from... Ah, he wrote most of embedded-sdmmc-rs which I used quite a bit. Jonathan, if you see this, thanks!
drrotmos 2y ago
Note that this was written 2024-08-08. While I haven't kept up to date with exactly what's been happening in rp-rs, I do know that probe-rs has since been updated with support for the RP2350. Other things may be outdated as well.
- jayyhu 2y ago
  The author points out that his changes have already been upstreamed to https://github.com/rp-rs/rp-hal https://github.com/rp-rs/rp-hal
moffkalast 2y ago
See, this is why we use conformal coating ;)
deleted 2y ago
[deleted]
GolDDranks 2y ago
I own a home router (TP-Link Archer C7) and I have been running OpenWRT for many years on it, having full control over it via SSH. A few years back, I had an idea for an daemon process/service to improve a certain thing in its functionality. I was delighted to find out that the MIPS chip that powers the thing was supported by Rust, and I coded a "script", cross-compiled it to a binary and SCP't that to the router. It ran beautifully. After that (and running Rust on a few other embedded systems, including an ARM Cortex-R chip) I became convinced that Rust is the next C for the embedded.
- johnisgood 2y ago
  > I became convinced that Rust is the next C for the embedded. Ada works, too, though, or Forth. :P
  - johnisgood 2y ago
    See more at https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Developer/index.html https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev....
- ricudis 2y ago
  The OpenWRT SDK is quite polished and convenient to use, so I usually use that for custom OpenWRT binaries. But a few days ago I needed to run something custom on my old QNAP NAS (Marvell ARMv5TE based), and I decided to try cross-rs[1] for the first time. It turned the usual multi-hour expedition of locating and configuring SDKs, toolchains, etc into 3 commands and 5 minutes of downloads and compilation. The resulting executable ran successfully at the first try. I was amazed. [1] https://github.com/cross-rs/cross https://github.com/cross-rs/cross
  - overfeed 2y ago
    I default to Go for code I want to run on old MIPS and ARMv5/v6 appliances because despite the "huge" binary sizes, cross-compiling is done by setting 2 environmental variables.
boguscoder 2y ago
Embassy got _some_ support for rp2350 for quite some time now https://github.com/embassy-rs/embassy https://github.com/embassy-rs/embassy
- drrotmos 2y ago
  I'm very much looking forward to giving Embassy on the RP2350 a go. I've been using it for a while with the RP2040, and it's a joy to use.
vkaku 2y ago
Uhm, I was looking to try it and I found this advisory: https://forums.pimoroni.com/t/rp2350-gpio-internal-pull-problem-and-simplistic-workaround/25443 https://forums.pimoroni.com/t/rp2350-gpio-internal-pull-prob... Would suggest people understand this before buying.
deleted 2y ago
[deleted]

148 points by fanf2 2y ago

sph 2y ago

Can anyone explain how the dual ARM/RISC-V system works, architecturally? Are there two actual CPUs on the same die? Is it one shared architecture with two different instruction decode stages, one for ARM and the other for RISC-V that can be toggled at boot time? I like the idea conceptually but I'm not sure how much of that is a hack and/or inefficient compared to a pure ARM or RISC-V core.

dcan 2y ago
To be more precise, four CPUs - two ARM and two RISC. There is just a mux for the instruction and data buses - see chapter 3 of the [datasheet](https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p...). It’s space-inefficient as half of the CPUs are shutdown, but architecturally it’s all on the same bus.
- Narishma 2y ago
  It may be technically space inefficient but they only added the RISC-V cores because they had area to spare. It didn't cost them much.
  - petertodd 2y ago
    I wonder if they're using the same die for one or more microprocessor products that are RISC-V-only or ARM-only? They could be binning dies that fail testing on one or the other cores that way. Such a product might be getting sold under an entirely different brand name too.
    - baby_souffle 2y ago
      That may be the plan for the future. Right now, this is a hedge / leverage against negotiations with ARM. For developers looking to test their code against a new architecture and compare it to known good code/behavior, it doesn’t get any easier than rebooting into the other core!
    - jsheard 2y ago
      They're not currently doing that but there is a documented way to permanently disable the ARM cores, so they could sell a cheaper RISC-V-only version of the same silicon if there's enough demand to justify another SKU.
  - enragedcacti 2y ago
    Source for the RISC-V cores being essentially free (Luke Wren is the creator of the RISC-V core design used): > The final die size would likely have been exactly the same with the Hazard3 removed, as std cell logic is compressible, and there is some rounding on the die dimensions due to constraints on the pad ring design. https://nitter.space/wren6991/status/1821582405188350417 https://nitter.space/wren6991/status/1821582405188350417
  - Graziano_M 2y ago
    Funny thing is that it cost them more than you might think. It was the ability to switch to the riscv which made it (much) easier to glitch. See the "Hazardous threes" exploit [1] [1] https://www.raspberrypi.com/news/security-through-transparency-rp2350-hacking-challenge-results-are-in/ https://www.raspberrypi.com/news/security-through-transparen...
- myrmidon 2y ago
  I find this whole concept remarkable, and somewhat puzzling. Have seen the same (ARM + RISC-V cores) even at larger scales before (Milk-V Duo @1GHz-ish). But how is this economical? Is die space that cheap? Could you not market the same thing as quadcore with just minor design changes, or would that be too hard because of power budget/bus bandwidth reasons?
  - bananapub 2y ago
    two things: 1) it needs a certain perimeter to allow all the pins to go from the silicon to the package, which mandates a certain sized square-ish die 2) only the cores are duplicated (and some switching thing is added) so yes, there is enough space to just add another two cores without any worries, since they don't need more IO or pins or memory or anything.
  - imtringued 2y ago
    SRAM is very area intensive. What you're asking for is very greedy. The RISC-V core they are using is absolutely tiny.
    - myrmidon 2y ago
      Thats also a good point. For the big Milk-V systems I mentioned they use external DRAM-- but cache might still be a die-space issue (I'd assume that it's always shared completely between ARM/RISC-V cores, and would need to be scaled up for true multicore operation). But I'm still amazed that this is a thing, and you can apparently just throw a full core for a different architecture on a microcontroller at basically no cost :O
- Aurornis 2y ago
  > It’s space-inefficient as half of the CPUs are shutdown In practice is doesn't matter very much for a design like this. The size is already limited to a certain minimum to provide enough perimeter area to provide wire bonding area for all of the pins, so they can fill up the middle with whatever they want.
  - DrNosferatu 2y ago
    They should have filled it with more SRAM instead - 520KB is far too little.
    - Tharre 2y ago
      What difference would the extra 16KiB or whatever instead of the 2 RISC-V cores make? If 520KB is far too little for you, you're likely better off adding a 8 MiB PSRAM chip.
      - DrNosferatu 2y ago
        Just 16KB? Couldn’t a lot more be fitted? PSRAM has huge latency.
        timschmidt 2y ago
        SRAM takes up a tremendous amount of space compared to logic. Usually at least six transistors per bit, plus passives, plus management logic.
        Lerc 2y ago
        SRAM is big in gate count. typically 6 transistors per bit. The i386, a 32 bit chip already dragging around a couple of generations of legacy architecture came in at 275,000. I would imagine the Hazard3 would be quite a bit more efficient in transistor usage due to architecture. 16K is 16384(bytes) *8(bits per byte) *6(transistors per bit) = 786, 432
        2y ago
MisterTea 2y ago
> Can anyone explain how the dual ARM/RISC-V system works, architecturally? What I really want to know is why would anyone need or want dual architectures on one chip?
- pjc50 2y ago
  This is hedging their bets. Tapeouts are expensive. It seems that they had spare area, so they decided to add RISC-V as a sort of feature test and market test; that lets them determine what the market preference is between the two and acquire geek coolness points (plus an additional point for using Rust) at relatively low cost, certainly lower cost than doing two tapeouts for two different SKUs. Here at $MEDIUM_SIZED_CHIP_CO, we also have some products which have a custom DSP for realtime audio processing and an ARM for "other stuff". It's more common than you think. Even the very first Pi was effectively a video-oriented vector processor with a small ARM glued on the side.
  - snvzz 2y ago
    If anything, they must have learned by now that they can simply drop the ARM cores and go full RISC-V. As long as they make their core at least feature-equivalent by implementing FPU and the secure boot chain.
    - MisterTea 2y ago
      They certainly can but the end users likely can't. I am sure there are a lot of projects that make Arm assumptions and porting isn't as simple as changing compilers. And is Risc-V tooling as mature as Arm? Doubtful. So releasing a pure Risc-V micro is Risc-Y at this time. However, giving end users both in the same chip eliminates any risk because it allows the Risc-V tooling to develop at the same time. And if that development fails, oh well, the Arm cores will keep working and the next tapout might exclude the Risc-v cores. Life moves on.
      - snvzz 2y ago
        >is Risc-V tooling as mature as Arm? RISC-V is rapidly growing the strongest ecosystem.

password4321 2y ago

Which of the four RP2350 variants is used in the Raspberry Pi Pico 2 W? I see RP2350A0A2⁰ and (pardon my ignorance) guess that means SKU RP2350A package QFN60, the one with the least features. ⁰ https://datasheets.raspberrypi.com/picow/pico-2-w-schematic.pdf https://datasheets.raspberrypi.com/picow/pico-2-w-schematic....

maeln 2y ago
Most picture I find seem to show the RP2350A variant for the W and non-W version.
moefh 2y ago
As far as I know, any Pico 2 currently sold carry the RP2350A: 30 GPIOs, no internal flash since the board carries an external flash chip. (BTW two of the variants are called RP2354 and not RP2350, the last digit means the amount of internal flash)

teleforce 2y ago

Previous post on HN: Raspberry Pi Showcases Rust on the RP2350 Microcontroller (9 comments): https://news.ycombinator.com/item?id=41476505 https://news.ycombinator.com/item?id=41476505

mastax 2y ago

thejpster, where do I know that username from... Ah, he wrote most of embedded-sdmmc-rs which I used quite a bit. Jonathan, if you see this, thanks!

drrotmos 2y ago

Note that this was written 2024-08-08. While I haven't kept up to date with exactly what's been happening in rp-rs, I do know that probe-rs has since been updated with support for the RP2350. Other things may be outdated as well.

jayyhu 2y ago
The author points out that his changes have already been upstreamed to https://github.com/rp-rs/rp-hal https://github.com/rp-rs/rp-hal

moffkalast 2y ago

See, this is why we use conformal coating ;)

deleted 2y ago

[deleted]

GolDDranks 2y ago

I own a home router (TP-Link Archer C7) and I have been running OpenWRT for many years on it, having full control over it via SSH. A few years back, I had an idea for an daemon process/service to improve a certain thing in its functionality. I was delighted to find out that the MIPS chip that powers the thing was supported by Rust, and I coded a "script", cross-compiled it to a binary and SCP't that to the router. It ran beautifully. After that (and running Rust on a few other embedded systems, including an ARM Cortex-R chip) I became convinced that Rust is the next C for the embedded.

johnisgood 2y ago
> I became convinced that Rust is the next C for the embedded. Ada works, too, though, or Forth. :P
- johnisgood 2y ago
  See more at https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Developer/index.html https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev....
ricudis 2y ago
The OpenWRT SDK is quite polished and convenient to use, so I usually use that for custom OpenWRT binaries. But a few days ago I needed to run something custom on my old QNAP NAS (Marvell ARMv5TE based), and I decided to try cross-rs[1] for the first time. It turned the usual multi-hour expedition of locating and configuring SDKs, toolchains, etc into 3 commands and 5 minutes of downloads and compilation. The resulting executable ran successfully at the first try. I was amazed. [1] https://github.com/cross-rs/cross https://github.com/cross-rs/cross
- overfeed 2y ago
  I default to Go for code I want to run on old MIPS and ARMv5/v6 appliances because despite the "huge" binary sizes, cross-compiling is done by setting 2 environmental variables.

boguscoder 2y ago

Embassy got _some_ support for rp2350 for quite some time now https://github.com/embassy-rs/embassy https://github.com/embassy-rs/embassy

drrotmos 2y ago
I'm very much looking forward to giving Embassy on the RP2350 a go. I've been using it for a while with the RP2040, and it's a joy to use.

vkaku 2y ago

Uhm, I was looking to try it and I found this advisory: https://forums.pimoroni.com/t/rp2350-gpio-internal-pull-problem-and-simplistic-workaround/25443 https://forums.pimoroni.com/t/rp2350-gpio-internal-pull-prob... Would suggest people understand this before buying.

deleted 2y ago

[deleted]