Raspberry Pi receives strategic investment from Arm(newsroom.arm.com)
newsroom.arm.com
Raspberry Pi receives strategic investment from Arm
https://newsroom.arm.com/news/raspberry-pi-investment
200 comments
Doesn't matter anyway. They shot themselves in the foot by removing hardware video encoding. I switched to the Orange Pi 5 so I can keep my video encoders and also benefit from the nice TPU.
This doesn't really make any sense - you can video encode 1080p H.264 on the Pi 5 in software without using more than ~25% of the CPU. And the quality, if you don't mind trading more CPU, will be far superior than the hardware encoders ever were.
I remember seeing an ad many decades ago for a PC ad-in board for encoding and decoding JPEG. You know, back when dinosaurs roamed the earth and that might have been a thing for desktop publishing or whatever. General purpose CPU has gotten fast enough to do a lot of things that used to benefit from hardware acceleration.
A little over 30 years ago when I started working on multimedia conferencing over the Internet, for some reason we had a couple of hardware JPEG decoder ISA (?) cards from Bitfield Oy, a Finish company (if I recall correctly). I can't find any documentation on them now, as this predates NCSA Mosaic and the start of the web's rapid rise. Anything before about 1994 doesn't really exist online. JPEG was brand new back then, but even so it seemed a little odd, as they were actually slower than software JPEG decoding on the Sun SparcStations we were using. It might have made sense on a PC, as PCs were significantly slower than Unix workstations at the time and we looked down on the poor folks who had to use them with pity, but I'm pretty sure the market must have been small and rapidly followed the dinosaurs into extinction.
The original PlayStation's main SoC (which is incidentally about 30 years old at this point) included a trimmed down JPEG decoder [1] meant to be used for video playback. It still relied on the CPU to handle Huffman decompression [2], but it allowed that otherwise anemic 33 MHz MIPS core to push 320x240 video at 30fps.
[1] https://psx-spx.consoledev.net/macroblockdecodermdec/
[2] https://github.com/Lameguy64/PSn00bSDK/blob/master/examples/...
[1] https://psx-spx.consoledev.net/macroblockdecodermdec/
[2] https://github.com/Lameguy64/PSn00bSDK/blob/master/examples/...
I'm using the CPU for other calculations. I don't need the extra overhead from removed hardware acceleration support.
Sounds like you need more than a $50 computer. Might be time to adjust these expectations.
If you know what hardware video encoding is you are not the target audience for raspberry pi.
This. I think people often forget that RPi is made to a price and intended to provide a balanced suite of capabilities at that price to their target markets. The delta sales due to a lack of something like hardware video encoding will be near zero.
Yeah, completely ignoring the fact that they included both encoding and decoding before, yup! Totally not the target audience!
The rPi foundation doesn't care about the individual end users anymore. They make most of their money supporting commercial vendors. They're keeping up the appearance of being good to the little guy so they can keep their support ecosystem alive and well.
The rPi foundation doesn't care about the individual end users anymore. They make most of their money supporting commercial vendors. They're keeping up the appearance of being good to the little guy so they can keep their support ecosystem alive and well.
I’ve yet to find a Pi-based commercial product that sold more than 10k units, ever.
Do you have evidence to the contrary?
Do you have evidence to the contrary?
Spin scooters, while not for sale, number approximately 50k units and are powered by a full-size Raspberry Pi 4.
Korg uses the Pi Compute Module 3 [0] in at least three of their products (wavestate, modwave, opsix), with Korg being one of the major synth manufacturers and overall annual keyboard synthesizer sales in the US alone being over 100K units. Don't have hard evidence but am assuming that Korg has sold more than 10K units of those three products.
[0] - https://www.raspberrypi.com/success-stories/korg-synthesizer...
[0] - https://www.raspberrypi.com/success-stories/korg-synthesizer...
"As of late 2022, Yodeck had shipped almost 50,000 Raspberry Pi-based units"
https://www.raspberrypi.com/app/uploads/2023/04/230329-Yodec...
Yoto Player is another example but I don't know how many Pi-based ones they shipped, I'd guess more than 10k but I don't know.
https://www.raspberrypi.com/app/uploads/2023/04/230329-Yodec...
Yoto Player is another example but I don't know how many Pi-based ones they shipped, I'd guess more than 10k but I don't know.
Is it really a big deal? How many people are doing encoding on the device and can't spare a core for it? I'm sure they exist, but the move from 4->5 will leave them with plenty of headroom, so it's not clear this changes anything, even if it makes 5 potentially slightly less attractive for some.
(I say this using a cm4 for image acquisition commercially. Because of the way our pipeline works, I skip the hardware encoder anyway - first, it's a complete pain in the ass to use, and second, it can't handle full-resolution images from a pi camera. We're slower than video because of the resolution, but still capture between 1fps and 1/10fps depending on configuration, with enough headroom to do some on-device image classification using tflite, rotation and JPEG compression, etc.)
(I say this using a cm4 for image acquisition commercially. Because of the way our pipeline works, I skip the hardware encoder anyway - first, it's a complete pain in the ass to use, and second, it can't handle full-resolution images from a pi camera. We're slower than video because of the resolution, but still capture between 1fps and 1/10fps depending on configuration, with enough headroom to do some on-device image classification using tflite, rotation and JPEG compression, etc.)
People transcode video in Plex or jellyfin
Sure, but it kind of sounds like the 5 will still be a superior solution, even without hardware support: https://www.raspberrypi.com/news/introducing-raspberry-pi-5/...
Obviously, it would need benchmarks, but taking that post at its word, the 5 can transcode twice as fast in software as the 4b could do in hardware.
That doesn't mean some other hardware platform wouldn't be drastically better, I just don't get the extreme reaction about the 5 when compared to the 4.
Obviously, it would need benchmarks, but taking that post at its word, the 5 can transcode twice as fast in software as the 4b could do in hardware.
That doesn't mean some other hardware platform wouldn't be drastically better, I just don't get the extreme reaction about the 5 when compared to the 4.
I think this overstates it a bit. I know what hardware video encoding is, but I still think I'm part of the target audience for the Pi.
I have several Pi's around the house that I use for various projects, and none of them have ever involved video encoding. The one thing I can think of where it might be beneficial is my plex server, but that's an x86 machine right now, and it'll probably stay that way.
I have several Pi's around the house that I use for various projects, and none of them have ever involved video encoding. The one thing I can think of where it might be beneficial is my plex server, but that's an x86 machine right now, and it'll probably stay that way.
It's quite all right for you to be unhappy about the lack of one feature on the newest version of the RPi but I think you're overstating it by claiming that they are shooting themselves in the foot.
Also are you saying that you've already switched to the Orange Pi 5? That's amazingly fast considering the RPi5 was launched less than 2 weeks ago.
Also are you saying that you've already switched to the Orange Pi 5? That's amazingly fast considering the RPi5 was launched less than 2 weeks ago.
RK3588S is the name of the game
>Also are you saying that you've already switched to the Orange Pi 5? That's amazingly fast considering the RPi5 was launched less than 2 weeks ago.
Doesn't strike me as odd. Orange Pi 5 has been available for a relative long time.
After seeing the Raspberry Pi 5 they were holding on for is not worth it, they finally pulled the plug with Orange Pi 5.
Doesn't strike me as odd. Orange Pi 5 has been available for a relative long time.
After seeing the Raspberry Pi 5 they were holding on for is not worth it, they finally pulled the plug with Orange Pi 5.
Strikes me as odd to make an emotional decision over lack of hardware support for something. I'm going to wait and see if I notice a difference, I am told that I won't. And I already know from bitter experience that those other boards are great until you find the thing that doesn't work and is *NEVER* fixed.
There's a lot of boards out there. They are not actually divided into groups like "Raspberry Pi" and "the others, which are broken."
Way to talk about emotional decisions while being bitter about some bad experience with another SBC.
I have personally had great experiences with other SBCs, and I'm not just talking VisionFive2, but ARM ones, over the years.
There's a lot of them, and it takes some care in choice. Insist on the few ones that have SoCs with good upstream support. There's also a tendency for good ones to come in series; the already named Orange Pi 5 has many predecessors, and established reputation.
And a friendly reminder below that Raspberry Pi does have its own dark history.
Be it Codec licenses to use the hardware acceleration, camera DRM, or hardware bugs.
Such as the USB protection dropping too much voltage on the first Pi, or the 2nd generation rebooting when exposed to light, or the third "+" models erratic ethernet behavior.
Or the main serial port suddenly not working, because now it's bluetooth's, and you have to use an alternative, unreliable one which baudrate scales with cpu clock. And that broken serial port staying broken despite RPi4 added more hardware serial ports.
Or RPi4 shipping w/o a heatsink, and throttling constantly until one is added.
And RPi5 still not supporting voltages above 5v via usb-pd, despite demanding more peak current than ever before.
Then there's people issues, like forgetting its good-for-society not-for-profit and focusing on making money. The "Pi 400", as well as prioritizing industry customers; it was really hard to get a Pi4 for a period of time spawning years.
I'm saying this despite I own all models, keep most of them in use still, and will likely get a rpi5 down the line, just to mess around, despite trying to move most of my computing to the standard RISC-V ISA.
Way to talk about emotional decisions while being bitter about some bad experience with another SBC.
I have personally had great experiences with other SBCs, and I'm not just talking VisionFive2, but ARM ones, over the years.
There's a lot of them, and it takes some care in choice. Insist on the few ones that have SoCs with good upstream support. There's also a tendency for good ones to come in series; the already named Orange Pi 5 has many predecessors, and established reputation.
And a friendly reminder below that Raspberry Pi does have its own dark history.
Be it Codec licenses to use the hardware acceleration, camera DRM, or hardware bugs.
Such as the USB protection dropping too much voltage on the first Pi, or the 2nd generation rebooting when exposed to light, or the third "+" models erratic ethernet behavior.
Or the main serial port suddenly not working, because now it's bluetooth's, and you have to use an alternative, unreliable one which baudrate scales with cpu clock. And that broken serial port staying broken despite RPi4 added more hardware serial ports.
Or RPi4 shipping w/o a heatsink, and throttling constantly until one is added.
And RPi5 still not supporting voltages above 5v via usb-pd, despite demanding more peak current than ever before.
Then there's people issues, like forgetting its good-for-society not-for-profit and focusing on making money. The "Pi 400", as well as prioritizing industry customers; it was really hard to get a Pi4 for a period of time spawning years.
I'm saying this despite I own all models, keep most of them in use still, and will likely get a rpi5 down the line, just to mess around, despite trying to move most of my computing to the standard RISC-V ISA.
> Way to talk about emotional decisions while being bitter
That's fair.
> about some bad experience with another SBC.
I didn't say one bad experience. I've tried a load of those "pi-killer" SBCs that have universally crap software support. Normally requiring some old version of Debian/Ubuntu and even then with some of their "killer" features broken. It is good to see Orange Pi actually doing some work there, maybe it is time to try again with an alternate board.
I am bitter because it's frustrating that unlike hardware bugs that are actually hard to fix once you've started shipping, software can be updated. But none of the other companies invest in that. It feels like they are just on to the next version, desperate to keep ahead on features. Compared to Raspberry Pi, where for example, things like the Pi 4 throttling issue are fixed/improved down the line.
> RPi5 still not supporting voltages above 5v via usb-pd
I didn't see this one. Do you have details?
That's fair.
> about some bad experience with another SBC.
I didn't say one bad experience. I've tried a load of those "pi-killer" SBCs that have universally crap software support. Normally requiring some old version of Debian/Ubuntu and even then with some of their "killer" features broken. It is good to see Orange Pi actually doing some work there, maybe it is time to try again with an alternate board.
I am bitter because it's frustrating that unlike hardware bugs that are actually hard to fix once you've started shipping, software can be updated. But none of the other companies invest in that. It feels like they are just on to the next version, desperate to keep ahead on features. Compared to Raspberry Pi, where for example, things like the Pi 4 throttling issue are fixed/improved down the line.
> RPi5 still not supporting voltages above 5v via usb-pd
I didn't see this one. Do you have details?
>I didn't see this one. Do you have details?
Like the previous boards, it doesn't support usb power beyond 5v. This time it's usb-pd proper, but still has that limit.
So It's the same as usual. Most usb supplies out there (majorly phone chargers) won't output much current at 5v, only at higher voltages, thus you need to buy a known-good supply especially just so that the rpi is happy.
And, as happened the last time, the old one is probably not good enough, as current requirements went up.
Like the previous boards, it doesn't support usb power beyond 5v. This time it's usb-pd proper, but still has that limit.
So It's the same as usual. Most usb supplies out there (majorly phone chargers) won't output much current at 5v, only at higher voltages, thus you need to buy a known-good supply especially just so that the rpi is happy.
And, as happened the last time, the old one is probably not good enough, as current requirements went up.
Oh right, I've never had problems there but I've a good selection of decent power supplies. I've been using my Pi 4 supply with the Pi 5, no problems so far but I am only using one USB device (not a disk...). I can see why they did it but I agree it's pretty annoying. For the record, you can disable the new USB current limitation when using a 3A PSU, supposedly it still functions fine but as always, depends what you are doing.
On other hand, I've got multiple RK3588 boards and am getting a Raspberry Pi 5 for its proper Vulkan drivers. It really does depend on your use case.
Panfrost team is doing good work for GPU drivers for the RK3588 boards, but I expect that to take longer
Panfrost team is doing good work for GPU drivers for the RK3588 boards, but I expect that to take longer
I am still shocked by Raspberry Pi's decision to put their weight behind MPEG's HEVC (and exclusively accelerate that codec, removing support for the others), instead of Aomedia's AV1.
Then again, I feel the same way for remaining ARM, when they could very well have, with a similar timeline, moved to RISC-V RVA22+V. Many do not understand this now, but will in the coming months when VisionFive3 and other RVA22+V boards launch.
Such a wasted opportunity for Raspberry Pi.
Then again, I feel the same way for remaining ARM, when they could very well have, with a similar timeline, moved to RISC-V RVA22+V. Many do not understand this now, but will in the coming months when VisionFive3 and other RVA22+V boards launch.
Such a wasted opportunity for Raspberry Pi.
> with a similar timeline, moved to RISC-V RVA22+V.
Look how long it takes them to bump their software releases. And you want to throw an entirely new architecture in the mix? Why? I don't understand how you can be shocked by the decision to stick with what works and sells (very well). Which of their goals would be furthered by taking this significant risk?
Look how long it takes them to bump their software releases. And you want to throw an entirely new architecture in the mix? Why? I don't understand how you can be shocked by the decision to stick with what works and sells (very well). Which of their goals would be furthered by taking this significant risk?
deelowe(3)
"We'll pay you to not switch to those cheap RISC-V cores coming down the pipeline".
How much cheaper are RISC-V chips in reality?
I get there might be a saving for not having to pay ARM a royalty of some kind, but are RISC-V chips cheaper in practice as a result?
I was under the impression (rightly or wrongly) that the arm royalties per chip were really small.
I get there might be a saving for not having to pay ARM a royalty of some kind, but are RISC-V chips cheaper in practice as a result?
I was under the impression (rightly or wrongly) that the arm royalties per chip were really small.
SiFive would practically give away their latest P870 cores (close to A78 performance levels) to get them shipping by the millions in the Pi because of the free advertising, free exposure, and massive boost it would give to the development of the RISC-V ecosystem.
Once such a switch was made, Pi could even consider using free and open source cores for their low-end devices where margins are slim (an area where RISC-V has already been gaining ground rapidly).
Once such a switch was made, Pi could even consider using free and open source cores for their low-end devices where margins are slim (an area where RISC-V has already been gaining ground rapidly).
Where can I buy one of these p870 cores and how much do they typically cost? (Or boards containing them?)
These are the newest OoO cores with full 1.0 vector extensions, right?
These are the newest OoO cores with full 1.0 vector extensions, right?
As a normal consumer you can't.
But the predecessor P670 should be available in the SG2380 board in 2024Q3 [0].
It will have 16 P670 and 8 X280 cores, and will cost $120 to $200 (without included RAM).
[0] https://forum.sophgo.com/t/about-the-sg2380-oasis-category/3...
[0] https://forum.sophgo.com/t/about-the-sg2380-oasis-category/3...
>P870
These cores have just been announced, and are available for licensing. You can contact SiFive if you're interested.
If what you want is hardware somebody's already made, that's going to take 2-3 years as per tradition.
>These are the newest OoO cores with full 1.0 vector extensions, right?
Yes, but so are multiple generations of predecessors. It seems that hardware based on P670[0] and X280[1] (both match that description) will be available for purchase in less than 10 months from now[2].
0. https://sifive.cdn.prismic.io/sifive/7be0420e-dac1-4558-85bc...
1. https://sifive.cdn.prismic.io/sifive/9405d3d0-35a1-4680-a259...
2. https://forum.sophgo.com/t/about-the-sg2380-oasis-category/3...
These cores have just been announced, and are available for licensing. You can contact SiFive if you're interested.
If what you want is hardware somebody's already made, that's going to take 2-3 years as per tradition.
>These are the newest OoO cores with full 1.0 vector extensions, right?
Yes, but so are multiple generations of predecessors. It seems that hardware based on P670[0] and X280[1] (both match that description) will be available for purchase in less than 10 months from now[2].
0. https://sifive.cdn.prismic.io/sifive/7be0420e-dac1-4558-85bc...
1. https://sifive.cdn.prismic.io/sifive/9405d3d0-35a1-4680-a259...
2. https://forum.sophgo.com/t/about-the-sg2380-oasis-category/3...
Not sure, but really small royalties on $4 computers can still be accumulate. They may also prevent $4 computers turning into $1 computers even if huge volumes would call for this otherwise.
Moreover, those royalties put fences on what might otherwise be more open and collaborative. It would be sad, if the tinkering goals set out originally by Raspberry Pi were curtailed by ISA license restrictions. RISC-V inherently has an edge over ARM in that dimension.
Moreover, those royalties put fences on what might otherwise be more open and collaborative. It would be sad, if the tinkering goals set out originally by Raspberry Pi were curtailed by ISA license restrictions. RISC-V inherently has an edge over ARM in that dimension.
I think a lot of the motivation here is to avoid RPI leading to further interest and development on the RISC-V side. SIFIVE may be willing to make something perfect for the RPI, but the real risk is if RPI goes RISC-V, then software gets ported and tested on RISC-V. People start liking it and hacking it. And then RISC-V suddenly gets a lot more interest from ARM licensees and their competitors. Which, at the very least, will lead to higher licensee leverage in negotiations with ARM on renewal.
Bingo. This is what they mean by "strategic investment." It's not because they are just lovers of the education and maker market. They'd be negligent to their shareholders to not make this investment.
>but the real risk is if RPI goes RISC-V, then software gets ported and tested on RISC-V.
It's already happening. RISC-V doesn't need the Raspberry Pi.
Yet it would indeed be an accelerator, but I'm not sure how big. ARM are certainly very afraid.
It's already happening. RISC-V doesn't need the Raspberry Pi.
Yet it would indeed be an accelerator, but I'm not sure how big. ARM are certainly very afraid.
For "coming down the pipeline" they're essentially free.
Today, the c910 is an Apache 2, hardware proven out of order core on GitHub here https://github.com/T-head-Semi/openc910 a little slower than an RPi3's core.
Today, the c910 is an Apache 2, hardware proven out of order core on GitHub here https://github.com/T-head-Semi/openc910 a little slower than an RPi3's core.
What’s the price per unit?
There are no license fees if that's what you're asking.
Additionally it's very competitive in PPA metrics for it's gate count, so cheaper than similar cores in terms of wafer area as well.
Additionally it's very competitive in PPA metrics for it's gate count, so cheaper than similar cores in terms of wafer area as well.
I think the point is, very few people are looking to buy some RTL, they want the silicon. So the question is what's the price of the silicon? My understanding is anything comparable to the SoC in the RPi boards is still quite a lot pricier.
Pretty damn cheap.
https://www.aliexpress.us/item/3256805346421328.html?gateway...
https://www.aliexpress.us/item/3256805346421328.html?gateway...
Every other place seems to claim that the RRP is $119. So this must be a mistake/scam? Or did the price go down this much?
Regardless of cost, working with almost anyone other than broadcom would probably be seen as a huge plus as well.
I think one of the biggest fears from ARM would be the popularity of the Raspberry Pi and their community.
There are better boards than the Raspberry Pi (strictly speaking specifications here). I took that path of playing with a lot of alternative boards, my biggest issue is lack of support, some boards had kernels never updated, etc...(YMMV).
If Raspberry Pi released a RISC-V board I have no reason to believe the community would not be just as strong. Sure in the beginning they would support both, but eventually the ARM support would wither.
There are better boards than the Raspberry Pi (strictly speaking specifications here). I took that path of playing with a lot of alternative boards, my biggest issue is lack of support, some boards had kernels never updated, etc...(YMMV).
If Raspberry Pi released a RISC-V board I have no reason to believe the community would not be just as strong. Sure in the beginning they would support both, but eventually the ARM support would wither.
Is Raspberry Pi really that big for ARM?
for hobbyists yes. Usually people stick to the technology they first started experimenting with, and RPi is that platform for many future experts.
If you are going to learn computer architecture, you will learn something cheap you have on hand
If you are going to learn computer architecture, you will learn something cheap you have on hand
The technology is linux, gpios etc. not which instruction set the CPU has. That is completely irrelevant and raspberry switching to USB-C is a much bigger change from a user standpoint than switching to RISC-V would be.
Assuming performance and software support is comparable. Which obviously won't be the case for a long long time.
But there are few things as irrelevant as the CPU instruction set. (Part from specific extensions, like AES support enabling quick crypto etc.)
Assuming performance and software support is comparable. Which obviously won't be the case for a long long time.
But there are few things as irrelevant as the CPU instruction set. (Part from specific extensions, like AES support enabling quick crypto etc.)
Very much disagree. Of course linux and GPIO is important, but the widest use case for them among myself and people I know is as a build box and/or something to test ARM software on. One person uses it to learn ASM. From my small and surely non-representative sample, the architecture is maybe the most important thing. So I don't think we can confidently say that CPU arch isn't relevant.
> The technology is ...
The technology is what people know. Using a different SoC board, camera, ... requires adds more time to gain the same level of knowledge.
Doctors will latch onto a single product solution so they don't have to spend the time learning how to operate an alternative. Hospitals need to stock consumables based not on the best products but on what doctors know.
Airlines retain the same air crafts to reduce time spent learning to operate an alternative. Boeing marketed this as a sales feature with 737 MAX, no extra flight training required!
Software developers will often stick with the same language, even though others better fit the domain problem. Few seem willing to take the time to try and play with new concepts, languages, and operating systems.
Trying new and different things drives innovation not the world.
The technology is what people know. Using a different SoC board, camera, ... requires adds more time to gain the same level of knowledge.
Doctors will latch onto a single product solution so they don't have to spend the time learning how to operate an alternative. Hospitals need to stock consumables based not on the best products but on what doctors know.
Airlines retain the same air crafts to reduce time spent learning to operate an alternative. Boeing marketed this as a sales feature with 737 MAX, no extra flight training required!
Software developers will often stick with the same language, even though others better fit the domain problem. Few seem willing to take the time to try and play with new concepts, languages, and operating systems.
Trying new and different things drives innovation not the world.
Exactly my point. Changing the instruction set on the CPU won't change the API for the camera etc.
Some things will surely change because the hardware backed features work in a different way, but mostly it will be similar enough.
Going from a raspberry pi to an orange pi could be a much bigger leap than switching to an raspberry with RISC-V that has mature software support.
Some things will surely change because the hardware backed features work in a different way, but mostly it will be similar enough.
Going from a raspberry pi to an orange pi could be a much bigger leap than switching to an raspberry with RISC-V that has mature software support.
> But there are few things as irrelevant as the CPU instruction set.
I’m going to have to disagree with that statement…
… but only because I’m in the middle of goofing around with ARM assembly on an RPi as we speak.
I’m going to have to disagree with that statement…
… but only because I’m in the middle of goofing around with ARM assembly on an RPi as we speak.
But instruction set, in practice and in this case, is tightly coupled with form factor and MIPS per watt. I work in mobile robotics: my low end choice is RPi, high end an NVIDIA board. While I can see Risc-V challenging ARM here, they don’t yet. (Excepting an ultra low power/low compute edge-case.) I just don’t see any CISC architecture that’s available today competing.
I wouldn’t be surprised if the existence of many ARM docker images for hobbyist projects were indirectly due to the popularity of the Raspberry PI (in anrditi to Apple switching to ARM, more recently).
There aren't many other options if you want or need a system with physical access near your desk that is also designed to run GNU/Linux. I think the only other options are less-known SBC-based systems, or systems where GNU/Linux is an afterthought at best. With the Raspberry Pi 4, it's quite likely that one of your colleagues already got the locally preferred distribution to boot on it. Lots of people use them to reproduce and fix generic AArch64 issues, even if they have remote root access (including the ability to install another OS) to much faster lab machines.
In the past, one of often cited reasons for the lack of success of ARM server offerings was that every developer machine is x64, no software is ever tested on ARM and no dev has a machine to do so. As the Raspberry Pi got more performant it brought a lot of people running software on ARM, leading to lots of software publishing ARM builds, toolchains getting exercised, bugs ironed out, etc.
With Apple having moved to Arm there are definitely ecosystem benefits brewing too. I can run a Debian VM out of the box with UTM, compile an Arm64 package using standard Linux toolchain and have it run directly on a RPi. It's like having a supercharged RPi development environment with me all the time.
> some boards had kernels never updated
As much as I love tinkering, this is why I stick with RPi boards and not others. RPis do everything I need, and have amazing support in software.
As much as I love tinkering, this is why I stick with RPi boards and not others. RPis do everything I need, and have amazing support in software.
Same. I would prefer to use some of the alternatives, but at the end the support level is important.
That said, I'll tolerate some regression in support to switch to a RISC-V based competitor.
That said, I'll tolerate some regression in support to switch to a RISC-V based competitor.
Beaglebone?
Is it truly amazing? I was under impression that Raspberry requires some blobs to run properly. Is there detailed specifications for Broadcom chip they're using? I was under impression that it was NDA and not possible to obtain for ordinary mortal. So may be it's good because of sheer number of people tinkering with it and smoothing rough edges, but it could be better. Please correct me if I'm wrong.
I would better phrase it as every other board has amazingly bad support.
Sometimes it is a matter of choosing the one that sucks the least.
You're right. Pretty much all the low level stuff below the kernel in a pi is closed source.
Want your own custom boot rom so you can start up in half a second rather than the default 3 seconds before linux gets loaded? - sorry, we can't share the code for that with you, nor the specs for you to write it yourself!
Want your own custom boot rom so you can start up in half a second rather than the default 3 seconds before linux gets loaded? - sorry, we can't share the code for that with you, nor the specs for you to write it yourself!
There’s a few popular bare metal projects. Pi 1541 springs to mind. So it is possible, tho perhaps only with earlier generations
That's not what they meant. Yes, anybody can write bare metal alternative to Linux ( at the very least by looking at the Linux codebase). But still that Pi 1541 depends on the bootcode.bin, fixup.dat and start.elf binary blobs, which the OP was complaining about.
It wasn’t clear to me what they meant. I’m not familiar with the details of boot.bin but my read of what GP was implying was you had to use the rapsbian kernel and drivers. Thanks for the information.
> Please correct me if I'm wrong.
My memory told me it was the GPU that needed the blobs. So I asked at DDG
https://duckduckgo.com/?t=ftsa&q=binary+blobs+and+the+Raspbe...
Turned up this: https://wiki.debian.org/RaspberryPi and it says...
> All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W, 2, 3, Zero 2 W) boot from their GPU (not from the CPU!), so they require a non-free binary blob to boot
So the 4 (and I suppose the 5, if it ever actually comes...)
Goes on to say:
> Since then, Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016. See more at https://news.ycombinator.com/item?id=11703842 . Unfortunately development of rpi-open-firmware is currently (2021-06) stalled.
So there you are. Not wrong, are you, but not strictly correct, depending on "...to run properly" definition
https://github.com/librerpi/rpi-open-firmware has updates 3-months ago
My memory told me it was the GPU that needed the blobs. So I asked at DDG
https://duckduckgo.com/?t=ftsa&q=binary+blobs+and+the+Raspbe...
Turned up this: https://wiki.debian.org/RaspberryPi and it says...
> All Raspberry Pi models before the 4 (1A, 1B, 1A+, 1B+, Zero, Zero W, 2, 3, Zero 2 W) boot from their GPU (not from the CPU!), so they require a non-free binary blob to boot
So the 4 (and I suppose the 5, if it ever actually comes...)
Goes on to say:
> Since then, Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016. See more at https://news.ycombinator.com/item?id=11703842 . Unfortunately development of rpi-open-firmware is currently (2021-06) stalled.
So there you are. Not wrong, are you, but not strictly correct, depending on "...to run properly" definition
https://github.com/librerpi/rpi-open-firmware has updates 3-months ago
And also lots of the alternative boards target RPI users ("like raspberry pi but better, cheaper etc"). If RPI switched then it would probably make sense for many of the other boards to switch to in order to stay comparable to RPI.
If they want to compete they have to agree on something like ACPI so the OS vendors can target their boards without a separate distribution for each board.
Most ARM boards already use Device Tree with Linux, there isn't any new agreement needed. What is missing is getting the drivers for each board into the same source tree.
NetBSD provides a filesystem image containing one kernel that will boot on all supported ARMv8 boards, you may need to write a board-specific build of u-boot to the start of that image. A Linux distribution could do the same as this.
NetBSD provides a filesystem image containing one kernel that will boot on all supported ARMv8 boards, you may need to write a board-specific build of u-boot to the start of that image. A Linux distribution could do the same as this.
Good question. I looked it up and apparently the royalties are around 2% of the price of the chip, so it probably won't make a huge difference. They do also charge an up front "membership fee" which seems to vary from $200k to $10m depending on the chip.
RISC-V is very very popular already, but most RISC-V cores are not user accessible. They're controllers in hard drives, embedded management cores in SoCs, etc. Definitely nice to not have to pay for licensing that, and verification doesn't matter so much since you are more likely to be able to work around bugs in software.
I suspect it won't make a huge difference to visible CPUs. Probably the biggest impact will be flexibility.
RISC-V is very very popular already, but most RISC-V cores are not user accessible. They're controllers in hard drives, embedded management cores in SoCs, etc. Definitely nice to not have to pay for licensing that, and verification doesn't matter so much since you are more likely to be able to work around bugs in software.
I suspect it won't make a huge difference to visible CPUs. Probably the biggest impact will be flexibility.
A tougher question as so many factors that I hope Asianometry on YouTube cover one day.
Over time, but that will be when you get open-source RISC-V chips that compete with the designs of the market offerings other companies make and sell. Which as a mindset may cause the evolution of RISC-V issues as people could get burned due to expectations exceeding the reality and finding the get what you pay for those to still hold stronger than envisioned. Yes, eventually open-source CPU cores will get there, but production costs and scale will still become a factor, as to many aspects that all add up to the final cost. This is even on a level of software stack tried and fully robust of equality, which is still behind ARM.
ARM may well kill off x86 as a mainstream before RISC-V fully bites it.
Look at how long ARM took to get where it is, and started with microcontrollers, used in many things. That is where RISC-V will and is starting to get traction, but scaling beyond that, whilst could be faster than ARM's history, it's not as clear-cut as many foresee.
Whilst the RISC-V instruction set is free from licence/patent fees, the design of those chips will be made by a company that will need to recover costs, so there will be a cost. Compared to ARM who already offer up free core designs for use for free like the cortex-m0 and others. I know the Raspberry PICO uses a cortex-m0x.
Over time, but that will be when you get open-source RISC-V chips that compete with the designs of the market offerings other companies make and sell. Which as a mindset may cause the evolution of RISC-V issues as people could get burned due to expectations exceeding the reality and finding the get what you pay for those to still hold stronger than envisioned. Yes, eventually open-source CPU cores will get there, but production costs and scale will still become a factor, as to many aspects that all add up to the final cost. This is even on a level of software stack tried and fully robust of equality, which is still behind ARM.
ARM may well kill off x86 as a mainstream before RISC-V fully bites it.
Look at how long ARM took to get where it is, and started with microcontrollers, used in many things. That is where RISC-V will and is starting to get traction, but scaling beyond that, whilst could be faster than ARM's history, it's not as clear-cut as many foresee.
ARM did not start with microcontrollers - it started with desktop CPUs. In fact, it was a very long time before it got to microcontrollers!
Cheaper is not even the primary reason to use RISC-V over Arm.
The ability to modify the design for your application and be able to apply a plethora of cores where they are needed at only the cost of silicon area.
Apple has been moving their management cores on their M-series parts from Arm to RV and they have an architectural license.
Everyone has an architectural license for RISC-V, you can add your own instructions, change the mix of available instructions. A whole parametric RV32 or RV64 will be available on every node at every fab.
This move by Arm is absolutely to block RPI from moving to RISC-V. They have mindshare and distribution.
The ability to modify the design for your application and be able to apply a plethora of cores where they are needed at only the cost of silicon area.
Apple has been moving their management cores on their M-series parts from Arm to RV and they have an architectural license.
Everyone has an architectural license for RISC-V, you can add your own instructions, change the mix of available instructions. A whole parametric RV32 or RV64 will be available on every node at every fab.
This move by Arm is absolutely to block RPI from moving to RISC-V. They have mindshare and distribution.
Other than geopolitical and totalitarianism concerns, is that a good and bad thing that let you freely change your instruction … implementing no charge I understand, but everyone has their own architecture …
Art is not just about no limit, but what you do with the limitation including illuminating there is a limit. Not just about beyond it but of course you could.
Art is not just about no limit, but what you do with the limitation including illuminating there is a limit. Not just about beyond it but of course you could.
That is the first thing that came to my mind lol.
So, perhaps a good time to start a new business selling inexpensive RISC-V based micro computers?
About that community and dedicated resources, though. And branding.
Luckily the first users of the Raspberry Pi weren't discouraged by the lack of all of the above.
They weren't discouraged because it was an almost entirely unique product in the market at the time. It was Raspberry Pi or nothing. Demand for such a product was obviously huge (even bigger than RPi anticipated), so with no other options in the market, all the weight was put behind RPi by default. Something new today would need to siphon away a bunch of the RPi community to get the same momentum, and that seems unlikely because for the most part RPi treats the community pretty well. Aside from the shortages and allocation strategies, they do a great job of having polished solutions with software that works well and keeps getting updated.
Maybe I'm remember incorrectly but I was in middleschool when the RPI 1 came out and my dad got me one.
There was tons of guides, tutorials, etc. when I got it, which I think was close to launch? The os image was already made, tutorials on how to set it up, use ssh, setup a basic webserver, etc were all there at or very near launch.
---
Software support is almost never an issue for sbc's, and because they run linux, there's a significant amount of resources of how to use them.
Usually they fall apart because they don't have on-going software/firmware support the way RPI has always had a very well supported, and up-to-date linux image ready to flash.
---
Although I will admit I think far more packages were compiled for arm back then compared to riscv packages today.
There was tons of guides, tutorials, etc. when I got it, which I think was close to launch? The os image was already made, tutorials on how to set it up, use ssh, setup a basic webserver, etc were all there at or very near launch.
---
Software support is almost never an issue for sbc's, and because they run linux, there's a significant amount of resources of how to use them.
Usually they fall apart because they don't have on-going software/firmware support the way RPI has always had a very well supported, and up-to-date linux image ready to flash.
---
Although I will admit I think far more packages were compiled for arm back then compared to riscv packages today.
> Although I will admit I think far more packages were compiled for arm back then compared to riscv packages today.
You can track the debian build progress here:
past two weeks: https://buildd.debian.org/stats/graph-week-big.png
past quarter: https://buildd.debian.org/stats/graph-quarter-big.png
You can track the debian build progress here:
past two weeks: https://buildd.debian.org/stats/graph-week-big.png
past quarter: https://buildd.debian.org/stats/graph-quarter-big.png
Woah that's massive progress this year, dang.
The community has become a lot less important, as arm devices become more and more generic and supported. Nowadays you don't need any special distro or kernel to boot on most boards, so I can't see the brand name pulling them through if they don't maintain a price/capability edge.
This has not been my experience. Straying from RPi has each time left me dependent on community forums and stuff just to get stuff working, and a couple of times has left me with a completely dead device and no ideas how to proceed
You and me both :(
You mean like Milk-V or sipeed?
You'd already be late[0][1][2], but starting today is still better than starting tomorrow.
0. https://www.kickstarter.com/projects/starfive/visionfive-2
1. https://wiki.pine64.org/wiki/STAR64
2. https://milkv.io/
0. https://www.kickstarter.com/projects/starfive/visionfive-2
1. https://wiki.pine64.org/wiki/STAR64
2. https://milkv.io/
Unpopular opinion, backed by the current status quo (https://www.jeffgeerling.com/blog/2023/getting-risc-v-again-...)
It will take 3-5 years for RISC-V to catch up with ARM in any way that is meaningful for the Raspberry Pi's target segments. Maybe some industrial applications, but I really doubt we'll see RISC-V silicon with enough clout and power efficiency for a long while.
It will take 3-5 years for RISC-V to catch up with ARM in any way that is meaningful for the Raspberry Pi's target segments. Maybe some industrial applications, but I really doubt we'll see RISC-V silicon with enough clout and power efficiency for a long while.
I thought we were getting close to Pi4 speeds with the latest stuff from SiFive and there's some GPU support.
> 3-5 years
> The Raspberry Pi 4 Model B was released in June 2019
The math checks out.
> The Raspberry Pi 4 Model B was released in June 2019
The math checks out.
You should be looking at Rockchip's stuff if you're thinking about both hobbyist grade and industrial use. The RK3588 is still slightly ahead of the Pi 5, and several orders of magnitude above what RISC-V SBCs can deliver.
Software-wise, RISC-V is way behind as well.
Software-wise, RISC-V is way behind as well.
Well, for industrial use I love the documentation and support of Raspberry Pi, unless you specifically need performance not available on raspberry pi.
>The RK3588 is still slightly ahead of the Pi 5, and several orders of magnitude above what RISC-V SBCs can deliver.
Not that many orders of magnitude. There's RISC-V hardware (actual boards for sale) that's faster than RK3588 (thus RPi as well) coming in 2024.
This includes the SG2380 Oasis board[0] in 10 months, and a possibly earlier JH8100-based visionfive 3 board.
And we aren't even talking about large implementations like Tenstorrent Ascalon (expected to be competitive with Zen5, M4).
0. https://forum.sophgo.com/t/about-the-sg2380-oasis-category/3...
Not that many orders of magnitude. There's RISC-V hardware (actual boards for sale) that's faster than RK3588 (thus RPi as well) coming in 2024.
This includes the SG2380 Oasis board[0] in 10 months, and a possibly earlier JH8100-based visionfive 3 board.
And we aren't even talking about large implementations like Tenstorrent Ascalon (expected to be competitive with Zen5, M4).
0. https://forum.sophgo.com/t/about-the-sg2380-oasis-category/3...
Wow, has it been that long already. I'm getting old!
The acceleration is unlike anything ARM has ever had.
x86 was 20 years to OoO, ARM was 22 years, and RISC-V was just 4 years.
x86 was 31 years to dual-core, ARM was 25 years, and RISC-V was just 1 year.
x86 was 29 years to 64-bit systems, ARM was 28 years, and RISC-V was at most 6 years.
ARM took 35 years to catch up to x86. RISC-V seems set to do that in 13-14 years (if you only start counting when RISC-V had privilege systems, that's like 5-6 years and if you only count since vectors were added, it's just 3-4 years.
Put everything on a graph and RISC-V is blowing the doors off with how fast it has gone from unknown to next-gen tech.
x86 ARM RISC-V
Introduction 8008 (1974) ARM1 (1985) Raven-1 (2011)
first OoO NexGen NX586 (1994) ARM A9 (2007) BOOM (2015)
first multicore AMD Athlon X2 (2005) Nvidia Tegra 2 (2010) EOS16? (2012)
first 64-bit AMD Athlon64 (2003) Samsung Exanos 5 (2013) Western Digital SweRV? (2017?)
Bleeding Edge -- Apple M1 (2020) TBD (Tenstorrent Ascalon 2024?)
x86 was 20 years to OoO, ARM was 22 years, and RISC-V was just 4 years.
x86 was 31 years to dual-core, ARM was 25 years, and RISC-V was just 1 year.
x86 was 29 years to 64-bit systems, ARM was 28 years, and RISC-V was at most 6 years.
ARM took 35 years to catch up to x86. RISC-V seems set to do that in 13-14 years (if you only start counting when RISC-V had privilege systems, that's like 5-6 years and if you only count since vectors were added, it's just 3-4 years.
Put everything on a graph and RISC-V is blowing the doors off with how fast it has gone from unknown to next-gen tech.
While I don't think your assessment is inherently wrong, part of that I think is that fabbing custom silicon is easier than ever before.
Don't get me wrong, being open is doing wonders as well but just in general, nowadays fabbing ASICs (and the experience that goes with it) is so much more accessible to smaller, less risk averse players than when ARM (or x86) really started getting big.
Don't get me wrong, being open is doing wonders as well but just in general, nowadays fabbing ASICs (and the experience that goes with it) is so much more accessible to smaller, less risk averse players than when ARM (or x86) really started getting big.
Simply put: technology advanced to superscalar, OoO cores & 64 bit multi-core cpus. These advancements took decades to pan out.
Both x86 and ARM had to 'ride the wave' when that tech came along.
RISC-V otoh can pick up the result of those advancements, piece it together for a new ISA, and go. No waiting-until-tech-advances other than the wait for design work & prepping those designs for mass-production. Both of which can take considerable time. But not decades.
Both x86 and ARM had to 'ride the wave' when that tech came along.
RISC-V otoh can pick up the result of those advancements, piece it together for a new ISA, and go. No waiting-until-tech-advances other than the wait for design work & prepping those designs for mass-production. Both of which can take considerable time. But not decades.
It'll take at least 5 years and 100s of megabucks to get to where rpi5 is today.
It's possible that some of those 5 years and some hundreds of $100M have been already spent under wraps by Quallcom or whoever else, though. SiFive fiasco recently may prove it isn't easy even if the dollars are there.
It's possible that some of those 5 years and some hundreds of $100M have been already spent under wraps by Quallcom or whoever else, though. SiFive fiasco recently may prove it isn't easy even if the dollars are there.
Billions of bucks have already been spent.
The first large hardware showcasing this is arriving in 2024, including Tenstorrent Ascalon, expected to be competitive with Zen5.
The first large hardware showcasing this is arriving in 2024, including Tenstorrent Ascalon, expected to be competitive with Zen5.
It's MUCH more "We'll pay you to familiarize new embedded engineers with ARM processors so they're more likely to pick ARM SoCs for their (eventual) commercial projects."
It's smart marketing. And yes, RPis going to RISC-V would eventually be damaging to ARM all out of proportion to the number of RPis sold.
It's smart marketing. And yes, RPis going to RISC-V would eventually be damaging to ARM all out of proportion to the number of RPis sold.
Upton has spoken about the way that going public is in the foreseeable future. I wonder how this plays into that (or, conversely, avoids it).
No details on the size of the investment. Apparently just making sure Eben Upton 's chip designs don't wander of to the RISC-V dark side?
Indeed, this is very important for ARM. IoT and small devices are still a huge market for ARM and one that is damn near monopolized by market dominance. Protecting that is one of most important "strategic" things they need worry about.
From what I've heard, there are a lot of incompatible ISA implementations of RISC-V. Raspberry Pi adopting a specific ISA might be a tipping point in RISC-V adoption.
>there are a lot of incompatible ISA implementations of RISC-V
That is a form of FUD that unfortunately shows up very often.
In reality, all known application processors (e.g. made to run a software stack based on Linux), follow the RVA profile[0] spec.
So do all Linux binary distributions known to support RISC-V. As well as the BSDs.
Specifically, they currently target RVA20, and thus also support RVA22.
0. https://github.com/riscv/riscv-profiles/releases
That is a form of FUD that unfortunately shows up very often.
In reality, all known application processors (e.g. made to run a software stack based on Linux), follow the RVA profile[0] spec.
So do all Linux binary distributions known to support RISC-V. As well as the BSDs.
Specifically, they currently target RVA20, and thus also support RVA22.
0. https://github.com/riscv/riscv-profiles/releases
I'm not disagreeing with you that it's a bit of FUD, however what you're saying isn't entirely true either.
> In reality, all known application processors (e.g. made to run a software stack based on Linux), follow the RVA profile[0] spec.
What profile does Greenwave's GAP8 conform to?
> Specifically, they currently target RVA20, and thus also support RVA22.
Anything targeting RVA20 wouldn't be forward compatible. RVA22 added vector and floating-point extensions that a processor conforming to RVA20 wouldn't necessarily have or that wouldn't necessarily be compatible with RVA22.
> In reality, all known application processors (e.g. made to run a software stack based on Linux), follow the RVA profile[0] spec.
What profile does Greenwave's GAP8 conform to?
> Specifically, they currently target RVA20, and thus also support RVA22.
Anything targeting RVA20 wouldn't be forward compatible. RVA22 added vector and floating-point extensions that a processor conforming to RVA20 wouldn't necessarily have or that wouldn't necessarily be compatible with RVA22.
>What profile does Greenwave's GAP8 conform to?
That's a microcontroller, and designed to run your custom code. Regardless, it does conform to RVI20 profile, and supports the optional M and C extensions. It will thus run RVI20 code w/o issue.
>or that wouldn't necessarily be compatible with RVA22.
If not clear enough, all RVA20 code runs unmodified on RVA22.
That's a microcontroller, and designed to run your custom code. Regardless, it does conform to RVI20 profile, and supports the optional M and C extensions. It will thus run RVI20 code w/o issue.
>or that wouldn't necessarily be compatible with RVA22.
If not clear enough, all RVA20 code runs unmodified on RVA22.
> That's a microcontroller, and designed to run your custom code.
It is specifically marketed as an application processor.
> If not clear enough, all RVA20 code runs unmodified on RVA22.
Sorry I misunderstood what you were saying. I thought you meant software targeting RVA22 would run on a RVA20 processor.
It is specifically marketed as an application processor.
> If not clear enough, all RVA20 code runs unmodified on RVA22.
Sorry I misunderstood what you were saying. I thought you meant software targeting RVA22 would run on a RVA20 processor.
[deleted]
Wasn't Raspberry Pi a charitable foundation or did I completely imagine that?
There seems to be multiple entities:
Raspberry Pi Ltd - No.08207441 (the one who received this "investment")
Raspberry Pi Foundation - No.06758215 (registered charity)
Raspberry Pi Foundation North America - (registered 501(c)(3))
https://www.raspberrypi.org/about/
Raspberry Pi Ltd - No.08207441 (the one who received this "investment")
Raspberry Pi Foundation - No.06758215 (registered charity)
Raspberry Pi Foundation North America - (registered 501(c)(3))
https://www.raspberrypi.org/about/
[deleted]
Going by the 2022 accounts linked in another comment, the Raspberry Pi Foundation is the charitable part, and owns 91% of Raspberry Pi Ltd (the commercial entity that makes and sells SBCs, and the subject of the ARM press release) via another company ("Raspberry Pi MidCo Ltd").
[Edit: The link wasn't in another comment, was searched for: https://static.raspberrypi.org/files/about/RaspberryPiFounda... ]
[Edit: The link wasn't in another comment, was searched for: https://static.raspberrypi.org/files/about/RaspberryPiFounda... ]
RISC-V shadow is large...
I thought Raspberry Pi was a foundation? Do they have a for profit company too, like Mozilla Inc. vs Mozilla Foundation? Are they then selling off (part of)the for profit corp?
It's perfectly possible to invest in a project like this (the Limited, not the foundation) because of the side effects: more developers on ARM -> eventually more ARM licenses sold.
They are mostly a for profit company. The foundation is a cherry on the cake these days.
It still amazes me sometimes, that the most popular SBC line remains to be entirely Broadcom, of all vendors.
However there might be a bit of personal bias there, from the long time exposure to the Broadcom binary wireless driver (wl).
Hi Jeff.
However there might be a bit of personal bias there, from the long time exposure to the Broadcom binary wireless driver (wl).
Hi Jeff.
I'm sure they don't want to end up like the Arduino ecosystem and be in a position where they have to spend all the money on the software development and other vendors undercut their hardware.
So they need to have hardware their competitors can't replicate, which means Broadcom or custom silicon. My guess is the latter is where it will eventually go, since they already dipped their toe in the water with the Pico.
So they need to have hardware their competitors can't replicate, which means Broadcom or custom silicon. My guess is the latter is where it will eventually go, since they already dipped their toe in the water with the Pico.
Also the IO controller on the RPi5 is custom silicon
"RP1 is our I/O controller for Raspberry Pi 5, designed by the same team at Raspberry Pi that delivered the RP2040 microcontroller, and implemented, like RP2040, on TSMC’s mature 40LP process. It provides two USB 3.0 and two USB 2.0 interfaces; a Gigabit Ethernet controller; two four-lane MIPI transceivers for camera and display; analogue video output; 3.3V general-purpose I/O (GPIO); and the usual collection of GPIO-multiplexed low-speed interfaces (UART, SPI, I2C, I2S, and PWM). A four-lane PCI Express 2.0 interface provides a 16Gb/s link back to BCM2712.
Under development since 2016, RP1 is by a good margin the longest-running, most complex, and (at $15 million) most expensive program we’ve ever undertaken here at Raspberry Pi. It has undergone substantial evolution over the years, as our projected requirements have changed: the C0 step used on Raspberry Pi 5 is the third major revision of the silicon. And while its interfaces differ in fine detail from those of BCM2711, they have been designed to be very similar from a functional perspective, ensuring a high degree of compatibility with earlier Raspberry Pi devices."
https://www.raspberrypi.com/news/introducing-raspberry-pi-5/
"RP1 is our I/O controller for Raspberry Pi 5, designed by the same team at Raspberry Pi that delivered the RP2040 microcontroller, and implemented, like RP2040, on TSMC’s mature 40LP process. It provides two USB 3.0 and two USB 2.0 interfaces; a Gigabit Ethernet controller; two four-lane MIPI transceivers for camera and display; analogue video output; 3.3V general-purpose I/O (GPIO); and the usual collection of GPIO-multiplexed low-speed interfaces (UART, SPI, I2C, I2S, and PWM). A four-lane PCI Express 2.0 interface provides a 16Gb/s link back to BCM2712.
Under development since 2016, RP1 is by a good margin the longest-running, most complex, and (at $15 million) most expensive program we’ve ever undertaken here at Raspberry Pi. It has undergone substantial evolution over the years, as our projected requirements have changed: the C0 step used on Raspberry Pi 5 is the third major revision of the silicon. And while its interfaces differ in fine detail from those of BCM2711, they have been designed to be very similar from a functional perspective, ensuring a high degree of compatibility with earlier Raspberry Pi devices."
https://www.raspberrypi.com/news/introducing-raspberry-pi-5/
Aren't all the popular pine64 SBCs rockchip? And the big OrangePi SBCs?
Those are niche compared to Raspberry Pi.
RPi is a member of the RISC-V foundation but I don't think that that is anything about saving money, it's about the extra flexibility that it would have given RPi, as they are doing quite a lot of their own silicon these days.
Complete speculation, but perhaps with an investment from Arm both sides would be more comfortable with closer collaboration and more tailored Arm cores. Plus, RPi probably need the capital.
Complete speculation, but perhaps with an investment from Arm both sides would be more comfortable with closer collaboration and more tailored Arm cores. Plus, RPi probably need the capital.
It's a strategic investment to steer them away from risc-v, if needed.
My point was that it's not about price (which the current top comment says).
Yes and my reply wasn't about price. No need to be snarky.
Edit: And I did reply to the substance of your comment: I think it's above all about keeping them away from ris-v, not flexibility and collaboration (though of course closer collaboration means keeping them away from risc-v). Jeez...
Edit: And I did reply to the substance of your comment: I think it's above all about keeping them away from ris-v, not flexibility and collaboration (though of course closer collaboration means keeping them away from risc-v). Jeez...
Why did you reply then?
I've removed the snark but perhaps it's better to engage with the substance of a comment.
Edit : You didn’t engage with the substance of the comment which was about RPi’s perspective but instead made an unrelated comment about why Arm would do the investment.
I've removed the snark but perhaps it's better to engage with the substance of a comment.
Edit : You didn’t engage with the substance of the comment which was about RPi’s perspective but instead made an unrelated comment about why Arm would do the investment.
I don't know if you edited it out, but at least currently it is unclear to me that you're commenting on the perspective of RPi rather than ARM (which is TFA). Without that, it's unreasonable to be annoyed by the reply comment IMHO. Particularly with snark (which removal I applaud) is quite counterproductive.
That's quite strategic indeed.
Could be fatal to have RPi create a low-entry barrier for a cheap standardized RISC-V architecture, accumulate alot of (student) developers and applications, and then have the same architecture offered in high-performance (datacenter) hardware as well...
Could be fatal to have RPi create a low-entry barrier for a cheap standardized RISC-V architecture, accumulate alot of (student) developers and applications, and then have the same architecture offered in high-performance (datacenter) hardware as well...
We arrive to the point that anything RPi touch see a massive foundation solidification.
Even if RPi release an electronic RISC-V hardware, this foundation solidification would harm ARM on the long run.
Even if RPi release an electronic RISC-V hardware, this foundation solidification would harm ARM on the long run.
As I remember it the Raspberry Pi was originally conceived as a latter day BBC Micro[1] for people to learn on.
The Pi’s A and B naming scheme for instance harks back to the Beeb B.
The A in Arm originally stood for “Acorn”, the company behind both the BBC Micro and Arm processors.
The Beeb was also the host computer used to develop the first Arm processors.
So there’s something rather nice about this investment. It feels like a natural fit.
1. https://en.m.wikipedia.org/wiki/BBC_Micro
The Pi’s A and B naming scheme for instance harks back to the Beeb B.
The A in Arm originally stood for “Acorn”, the company behind both the BBC Micro and Arm processors.
The Beeb was also the host computer used to develop the first Arm processors.
So there’s something rather nice about this investment. It feels like a natural fit.
1. https://en.m.wikipedia.org/wiki/BBC_Micro
> The Pi’s A and B naming scheme for instance harks back to the Beeb B.
And, in fact, the BBC Model A.
As with the Pi models, the biggest difference between the BBC computer models A & B was RAM: the A having 16KiB and the B 32KiB. There were other differences too, but these were not as significant to many: a particular chip that provided IO, and the external ports that cam with it, were only available on the B or an user-upgraded A, and this also provided a couple of timers that one or two bits of software used (so there was some software that was model-B only despite fitting in the smaller RAM of tjhe model-A).
And, in fact, the BBC Model A.
As with the Pi models, the biggest difference between the BBC computer models A & B was RAM: the A having 16KiB and the B 32KiB. There were other differences too, but these were not as significant to many: a particular chip that provided IO, and the external ports that cam with it, were only available on the B or an user-upgraded A, and this also provided a couple of timers that one or two bits of software used (so there was some software that was model-B only despite fitting in the smaller RAM of tjhe model-A).
I part think the Raspberry Pi Pico is much more significant than most people have appreciated. Programming with the C SDK on it is quite ridiculously entertaining, but it is clear the hardware of the RP2040 is close to inspired.
Were I ARM I'd be far more concerned about a RISC-V spin off of the pico than the mainline pi devices.
Were I ARM I'd be far more concerned about a RISC-V spin off of the pico than the mainline pi devices.
I see the pico as a microcontroller, which is a different animal in comparison to the general-purpose cpu+gpu+peripherals of the arm pi that runs a full OS.
The Pico is a failure of Raspberry branding. As mentioned it's basically a microcontroller, doesn't run Linux, and doesn't hook up to a monitor or keyboard/mouse in same fashion. Which is fine, it's quite powerful! But imo should have used different branding to indicate thus as it's quite a different adventure.
On the flip side, there are now Arduino boards that run Linux. I think from a branding perspective, you'd be mad not to capitalise on the branding you've already got.
RP2040 is so two years ago.
Milk-V Duo[0] is where it's at, now.
0. https://milkv.io/duo
Milk-V Duo[0] is where it's at, now.
0. https://milkv.io/duo
That's more expensive, doesn't come with WiFi, and doesn't have the PIO cores that are the RP2040's true strength
You can dedicate one of the cores to realtime PIO tasks.
Alternatively, the BeagleV-Fire[0] FPGA got you covered, but that's not as cheap.
0. https://www.beagleboard.org/blog/2023-11-02-beaglev-fire-ann...
Alternatively, the BeagleV-Fire[0] FPGA got you covered, but that's not as cheap.
0. https://www.beagleboard.org/blog/2023-11-02-beaglev-fire-ann...
Good for them!
I know lots of folks are suggesting that this is aimed at preventing Raspberry Pi from going RISK-V and they're probably not wrong.
But, on the other hand, every single Raspberry Pi to date has been Arm-based, and they seem to be fairly conservative in terms of backwards compatibility. Even today, the recommended Raspberry Pi OS on https://www.raspberrypi.com/software/operating-systems/ is 32-bit in order to ensure compatibility with every model they've ever made. (The Pi Zero is the only model they still sell that is 32-bit only.)
The only places where I think RISC-V might have been likely were future iterations of the Pi Pico, or ancillary chips like the RP1. And that is probably less likely with this investment.
I know lots of folks are suggesting that this is aimed at preventing Raspberry Pi from going RISK-V and they're probably not wrong.
But, on the other hand, every single Raspberry Pi to date has been Arm-based, and they seem to be fairly conservative in terms of backwards compatibility. Even today, the recommended Raspberry Pi OS on https://www.raspberrypi.com/software/operating-systems/ is 32-bit in order to ensure compatibility with every model they've ever made. (The Pi Zero is the only model they still sell that is 32-bit only.)
The only places where I think RISC-V might have been likely were future iterations of the Pi Pico, or ancillary chips like the RP1. And that is probably less likely with this investment.
> The Pi Zero is the only model they still sell that is 32-bit only.
Not true. They're still selling all their previous models.
Not true. They're still selling all their previous models.
Oh, you're probably right; I don't know what deals they have with business customers.
I should have added "to the public" - I don't believe any B2C vendors still stock the Pi 1 or original 32-bit version of the Pi 2.
I should have added "to the public" - I don't believe any B2C vendors still stock the Pi 1 or original 32-bit version of the Pi 2.
They still sell them to the public, though stock availability will vary greatly between resellers and regions.
The Raspberry Pi Foundation's offices are in Cambridge where ARM is and there are ex Broadcom engineers (I think?) working there so just culturally I can see why ARM is a natural connection. I think this "lets make everything RISCV" meme (like "lets rewrite everything in rust") is going to get a cold evaluation as it doesn't originate there and the cold evalution will be that ARM is a big stable player that isn't going to disappear suddenly or radically change focus, that the cost of its licenses isn't material to RPi and that RPi's success is not endangered by sticking with ARM ... as things stand today.
RP1 and software support are their strengths and I think they won't take risks with instruction set changes or even the vendor of their particular ARM chip.
So I think this strategic investment is probably equivalent to a marketing cost - it won't stop RPi doing RISCV because they wouldn't do it anyhow. It will just help Rpi reach more people.
RP1 and software support are their strengths and I think they won't take risks with instruction set changes or even the vendor of their particular ARM chip.
So I think this strategic investment is probably equivalent to a marketing cost - it won't stop RPi doing RISCV because they wouldn't do it anyhow. It will just help Rpi reach more people.
Raspberry Pi did join the Risc-V foundation a while back.
Interesting, I didn't realize the connections were so deep. It does make sense.
Do you think RPi might be hurt by not adopting RISC-V if it takes off? If some of their competitors offer it, could one of them dethrone RPi?
Do you think RPi might be hurt by not adopting RISC-V if it takes off? If some of their competitors offer it, could one of them dethrone RPi?
Not the person you asked, but I have opinions:
It'd depend entirely on the level of support a competitor offers, right? I mean that's why RPi is still so popular despite there having been a number of ARM competitors offering more power per dollar for like a decade now. The strong software support led to a strong community/overall ecosystem, which has led to a strong install base, which further improved the community and ecosystem.
It's a combination of first mover advantage with continued strong software support that keeps them so prominent as-is. I don't see why a different ISA would fundamentally change that formula.
It'd depend entirely on the level of support a competitor offers, right? I mean that's why RPi is still so popular despite there having been a number of ARM competitors offering more power per dollar for like a decade now. The strong software support led to a strong community/overall ecosystem, which has led to a strong install base, which further improved the community and ecosystem.
It's a combination of first mover advantage with continued strong software support that keeps them so prominent as-is. I don't see why a different ISA would fundamentally change that formula.
Out of curiosity, who are the competitors who are competitive in power per dollar?
I don’t follow the space closely but the times I’ve checked out other offerings, they’re not competitive in price/$ or it won’t have wifi or other features to be comparable.
I actually started looking at older used desktops- which are fine for some uses and not so much for others.
I don’t follow the space closely but the times I’ve checked out other offerings, they’re not competitive in price/$ or it won’t have wifi or other features to be comparable.
I actually started looking at older used desktops- which are fine for some uses and not so much for others.
Check out some of the RK3588-based SBCs. The Orange Pi 5 Plus is a fantastic alternative to the Raspberry Pi 5 if you're okay with a bit of fiddling as mainline kernel support is still a work in progress.
I just got a Pi Zero 2 W and it seems like I won't be able to connect it to a WPA3 WiFi network (standard's only been out, oh, five years or so!) without recompiling the kernel, so YMMV over in Pi-land too.
Using a Pi as an access point with Hostapd has also been buggy and crashy for years now. There have been multiple driver updates that just seem to make it worse.
I’ve been doing development on a Rock 5B and it’s really powerful for a ~$200 SBC. I’ve been using as my aarch64 CI machine and test system as my company starts to add ARM support to our software stack.
Also, OBS runs great on it, although it’s not taking advantage of the on-board MPP media accelerator (H.264/265 and other codecs). Apparently GStreamer has support for it though and some folks have experimental FFMPEG forks adding support.
Also, OBS runs great on it, although it’s not taking advantage of the on-board MPP media accelerator (H.264/265 and other codecs). Apparently GStreamer has support for it though and some folks have experimental FFMPEG forks adding support.
I am not usually a fan of recommending youtube videos for people seeking information, but the goto I use for keeping up with SBCs competitive to Pi is the 'explaining computers' channel. It is oriented towards the lower end of audience sophistication but gives a quick breakdown of the features along with practical uses and actual setup and configuration of boards instead of just a rundown of specs.
This is exactly it, and I find it surprising no-one else seems to realise how much good software support makes an offering incredibly attractive compared to the alternatives.
No, I think their ability to offer anything comes from the use of hardware that is already "old" and made in great numbers. Then there's no chance of them getting stuck with a chip that disappears as some small RISCV company decides to stop producing it or that at best becomes a total dead end.
Offering RISC-V isn't a benefit to anyone - who really cares? I would guess a tiny number of people. Only if the performance is amazing will it matter. If that performance isn't accessible via software then bad luck too. ARM is not likely to have much trouble keeping up. To beat RPi someone would probably have to accept very marginal returns - I doubt that RPi Ltd is raking in silly amounts of money. It started from a charitable foundation and has to be barely profitable but I think it has no competitors because its situation is unattractive.
Offering RISC-V isn't a benefit to anyone - who really cares? I would guess a tiny number of people. Only if the performance is amazing will it matter. If that performance isn't accessible via software then bad luck too. ARM is not likely to have much trouble keeping up. To beat RPi someone would probably have to accept very marginal returns - I doubt that RPi Ltd is raking in silly amounts of money. It started from a charitable foundation and has to be barely profitable but I think it has no competitors because its situation is unattractive.
I think given they’ve been so allied to Broadcom and the ARM culture in Cambridge since the start, RISCV is never going to happen.
Other companies will make RISCV Pi alternatives in the same format, but the RPi Foundation won’t go there.
Other companies will make RISCV Pi alternatives in the same format, but the RPi Foundation won’t go there.
Until one of the competitors catches up to RPi's software support and stability and community, they have nothing to be fearful of. Not yet anyway.
The RPi shortage led me (and my coworkers) to examining the field of competitors, and all of them were buggier, less stable and badly documented in comparison, sadly. Perhaps that's changed since?
The RPi shortage led me (and my coworkers) to examining the field of competitors, and all of them were buggier, less stable and badly documented in comparison, sadly. Perhaps that's changed since?
> ARM is a big stable player that isn't going to disappear suddenly or radically change focus
You've picked the wrong company to state that about. It was bought by SoftBank for way too much money, and they've been trying to make good on their bad investment ever since. The risk is low that ARM falls into a Unity-level event, but the risk is much higher than people seem to think.
You've picked the wrong company to state that about. It was bought by SoftBank for way too much money, and they've been trying to make good on their bad investment ever since. The risk is low that ARM falls into a Unity-level event, but the risk is much higher than people seem to think.
>I think this "lets make everything RISCV" meme (like "lets rewrite everything in rust") is going to get a cold evaluation
Speaking from a geopolitical standpoint as a westerner, I would very much prefer if the US (x86; Intel and AMD) and UK (ARM) continue to be the forefront of microprocessor tech. RISC-V for all its virtues is ultimately primarily beneficial to China at this point, which is an entity we really do not want leading the world in the coming decades and century.
Speaking from a geopolitical standpoint as a westerner, I would very much prefer if the US (x86; Intel and AMD) and UK (ARM) continue to be the forefront of microprocessor tech. RISC-V for all its virtues is ultimately primarily beneficial to China at this point, which is an entity we really do not want leading the world in the coming decades and century.
Let me jump on this riscv bandwagon, thanks for the testimonial
There are people who has no choice. But there are also people who choose totalitarianism. Cannot even mourn a communist leader …
We are doomed to seek changes and happiness, those who know what is life in a totalitarian regime would wish to live differently, those enslaved by a corporativist dystopia being herd day after day until the end of days, wish to live differently, mine was more a joke about people thinking that it would change something for them, regardless who's in power
Welp another one bites the dust
Hopefully it’s not another two decades before we get totally open hardware platform as good as RaspPi has been
Hopefully it’s not another two decades before we get totally open hardware platform as good as RaspPi has been
Milk-V and StarFive (of VisionFive fame) both have low-cost boards with next generation, RVA22+V compliant RISC-V CPUs (faster than the just released RPi5), planned for 2024.
Raspberry Pi already missed the RISC-V train with the RPi5. It could very well have been the first board with Vector 1.0, but they did unfortunately not make that choice years ago, so we ended up with this RPi5 instead.
Raspberry Pi already missed the RISC-V train with the RPi5. It could very well have been the first board with Vector 1.0, but they did unfortunately not make that choice years ago, so we ended up with this RPi5 instead.
I am hoping that there would be a real Desktop Raspberry Pi in the future. I know that the Raspberry Pi 400 exists, which was clearly aimed at that, but an SD Card as primary storage just ain't it. The Pi 5 supports NVMe, but needs an adapter.
I would like something that has NVMe and non-USB connected networking, with sufficient cooling, with a good keyboard. GPIO should still be exposed (like on the Pi 400). I don't expect a PCIe expansion slot, basically I just want a beefed up Pi 400 to be a true BBC Micro successor. (And for the love of all that's good and holy, proper HDMI ports. And a proper keyboard, not a laptop keyboard like on the Pi 400. Heck, steal the Amiga 600 design.)
I would like something that has NVMe and non-USB connected networking, with sufficient cooling, with a good keyboard. GPIO should still be exposed (like on the Pi 400). I don't expect a PCIe expansion slot, basically I just want a beefed up Pi 400 to be a true BBC Micro successor. (And for the love of all that's good and holy, proper HDMI ports. And a proper keyboard, not a laptop keyboard like on the Pi 400. Heck, steal the Amiga 600 design.)
I use as a daily driver the R.Pi 400 booting from external NVMe. This is not difficult to configure.
It's a delight to use.
It's a delight to use.
Yeah, it just kinda ruins the aesthetic of an all-in-one wedge if you need to connect an external drive, also I'd prefer it to not be USB (I assume you use an NVMe-to-USB chassis?). So I'd love to see that being done internally. Essentially a RPi 5 with an actual NVMe slot and full size HDMI, in a wedge chassis with a better keyboard.
I find the timing interesting.
RISC-V Summit 2023 is next week[0].
Like every year, many announcements are expected. And they have, so far, never failed to be higher profile than the previous years' Summit.
0. https://riscv.org/event/risc-v-summit-2023/
RISC-V Summit 2023 is next week[0].
Like every year, many announcements are expected. And they have, so far, never failed to be higher profile than the previous years' Summit.
0. https://riscv.org/event/risc-v-summit-2023/