I wish I could buy RP2350 with the ARM cores being hard-fused disabled, "cheaper" since no ARM royalties would have to be paid.

That said, I wonder how much they did improve their hazard3 design, because we all know the future is no PI locked ARM cores. I wonder if they are sharing part of the design of other open source RISC-V cores.

If those efforts are kept significant, the future is looking good and better there. Hopefully, all that will be a success (=latest silicon process, ultra-performant RISC-V implementation in mobile/embedded/desktop/server).

▲

danhor 2 days ago | parent | next [-]

The Hazard 3 is basically a hobby project of Luke Wren, a Raspberry Pi Employee. He's contiuing to evolve it further, but I don't think it's ready for a full replacement of the Cortex-M yet, especially in regards to the Security Features.

The source code is all from Luke Wren and I don't think other cores use the source code directly, but improvements to test harnesses or general implementation patterns as well as better software support help other cores: https://github.com/Wren6991/Hazard3

For the SoCs I would expect to see an off-the-shelf Risc-V core (certainly no Hazard3 as the main CPU), but we'll see.

▲

Findecanor 2 days ago | parent | next [-]

The Hazard3 in the Pico 2 are bigger, more capable cores than the Cortex-M0 in the first Pico, and therefore in general faster at the same clock for compiled code.

You're supposed to be able to just recompile most Pico projects to use them as long as there is no ARM assembly in it.

They are only inferior to the ARM Cortex-M33 cores in the Pico 2.

	▲	PunchyHamster 2 days ago \| parent [-]
		So they come inferior in the only place it matters, gotcha

▲

ipdashc a day ago | parent | prev | next [-]

I know the "basically" is probably doing a bunch of heavy lifting, but dang, that's still awesome to think about. I didn't know hardware development was at the point where a hobby project CPU, apparently mostly developed by one guy, can realistically end up in a mass produced product like that.

Quick edit: sounds like "basically" wasn't doing that much heavy lifting after all, wow https://www.raspberrypi.com/news/risc-v-on-raspberry-pi-pico...

▲

sylware 2 days ago | parent | prev [-]

linux started as a hobby project...

I am curious to know which RISC-V design they'll go for in this SOC.

M. Wren getting real hard experience on RISC-V is going only to help RP to select and audit more seriously any RISC-V design which would make its way in their SOCs.

I just don't want to contribute to arm IP racketering (and we have mpeg and hdmi to take into account too with avX and eDP/DP).

▲

Tharre 2 days ago | parent | prev | next [-]

You can probably already get that if you order a somewhat significant amount of chips directly from Raspberry Pi. They seem to already have everything required for it, it's literally just setting a bit differently during factory programming.

But I'm assuming you're talking about for consumer use, in which case my question is why? There is absolutely no way you're ever benefiting from them spinning up an extra SKU with significantly less volume (most people want the ARM cores).

Even if they decide to eat the costs for the benefit of consumers, at most the chip would be what, 15 cents cheaper? I really struggle to see how that's a meaningful difference for hobbyist use.

	▲	duskwuff 21 hours ago \| parent [-]
		> You can probably already get that if you order a somewhat significant amount of chips directly from Raspberry Pi. It's not currently possible. As of the A3 stepping, the ARM_DISABLE OTP bit is ignored as a security mitigation - changing that would require a new mask revision.

▲

phkahler 2 days ago | parent | prev [-]

>> I wish I could buy RP2350 with the ARM cores being hard-fused disabled, "cheaper" since no ARM royalties would have to be paid.

Better yet, put 4 RISC-V cores on there!

	▲	duskwuff 21 hours ago \| parent [-]
		Not possible without substantial changes. The system bus and SIO are only configured for two active cores; they'd have to be rearchitected to support more. In particular, inter-processor communication would need major changes to support more than two cores - right now, it consists of a single pair of FIFOs between the two active cores.