[HN Gopher] Rust on the RP2350 (2024)
___________________________________________________________________
Rust on the RP2350 (2024)
Author : fanf2
Score : 120 points
Date : 2025-03-16 12:42 UTC (2 days ago)
(HTM) web link (thejpster.org.uk)
(TXT) w3m dump (thejpster.org.uk)
| sph wrote:
| 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 wrote:
| 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/rp
| 2350-datasheet.p...).
|
| It's space-inefficient as half of the CPUs are shutdown, but
| architecturally it's all on the same bus.
| Narishma wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| Graziano_M wrote:
| 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-
| transparen...
| myrmidon wrote:
| 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 wrote:
| 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 wrote:
| SRAM is very area intensive. What you're asking for is very
| greedy. The RISC-V core they are using is absolutely tiny.
| myrmidon wrote:
| 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 wrote:
| > 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 wrote:
| They should have filled it with more SRAM instead - 520KB
| is far too little.
| Tharre wrote:
| 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 wrote:
| Just 16KB? Couldn't a lot more be fitted?
| MisterTea wrote:
| > 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 wrote:
| 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.
| cmrdporcupine wrote:
| Isn't half the mission of the Pi project that it is an
| educational project, and also taretting hobbyists?
|
| In that respect it makes perfect sense to me.
| password4321 wrote:
| Which of the four RP2350 variants is used in the Raspberry Pi
| Pico 2 W? I see RP2350A0A20 and (pardon my ignorance) guess that
| means SKU RP2350A package QFN60, the one with the least features.
|
| 0 https://datasheets.raspberrypi.com/picow/pico-2-w-schematic....
| moefh wrote:
| 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)
| maeln wrote:
| Most picture I find seem to show the RP2350A variant for the W
| and non-W version.
| teleforce wrote:
| Previous post on HN:
|
| Raspberry Pi Showcases Rust on the RP2350 Microcontroller (9
| comments):
|
| https://news.ycombinator.com/item?id=41476505
| mastax wrote:
| 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 wrote:
| 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 wrote:
| The author points out that his changes have already been
| upstreamed to https://github.com/rp-rs/rp-hal
| moffkalast wrote:
| See, this is why we use conformal coating ;)
| GolDDranks wrote:
| 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 wrote:
| > I became convinced that Rust is the next C for the embedded.
|
| Ada works, too, though, or Forth. :P
| ricudis wrote:
| 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
| overfeed wrote:
| 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.
| Graziano_M wrote:
| Easily making static executables is a huge boon too.
___________________________________________________________________
(page generated 2025-03-18 23:00 UTC)