Can we please have a Pi without a crappy storage interface. It's either a microSD card or something dangling off USB. An M2 SATA or NVMe would make this credible but 99% of the problems I've had with the Pi platform is storage related, either being knackered microSD cards, terrible performance or USB power problems.
Sounds like you're not the target audience for a RPi. They are meant to be cheap computers for "the promotion of teaching basic computer science in schools and in developing countries"[0]. Adding NVMe support would increase the price.
There are alternatives to RPi that do what you want, odroid-h2plus for example.
Except these problems don't occur for most people, as evidenced by the fact that the current system works fine. Complaints like yours are relatively rare.
Do you mean the microSD cards tend to wear out, or that they’re DOA?
If the former — I’m pretty sure there’s an option to load RaspberryOS into a RAM-resident mode (like a live CD) where regular OS usage won’t hit the disk at all, and only a “Local Documents” partition is mounted writable, with nothing configured to implicitly write to it by default.
If the latter — trust me, the same is true of eMMC, or any other Flash media ordered in bulk quantities. You just have to QA them on arrival. Set up an RMAed-parts box with a shipping label in advance; you’ll need it.
> broken connectors
The microSD connector? In an educational context, that shouldn’t be end-user exposed. It’s essentially a maintenance port. Stick some tape over it.
In the computer labs of the 90s, kids would break the CD-ROM drive trays, too. MDM software was developed that would, among other things, lock out the CD-tray eject mechanism unless/until a teacher enabled it (presumably for working through some whole-class “multimedia” product that never materialized, because who’d trust kids to insert the CDs?)
> If the latter — trust me, the same is true of eMMC, or any other Flash media ordered in bulk quantities. You just have to QA them on arrival. Set up an RMAed-parts box with a shipping label in advance; you’ll need it.
SD cards and USB flash drives are manufactured with lower-grade flash memory than SATA and NVMe SSDs. The stuff that wears out in RPi usage is the stuff that was rejected for desktop usage. So having a large failure rate is not the only option, if you can expose a SATA or PCIe port. It's a little disappointing that they cannot even offer end users that upgrade path.
I'm sure your experiences are legitimate, just like mine for similar usage profiles are. My only conclusion can be that it's not the hardware itself that's the problem, unless we allow for the possibility that it's different batching. Unlikely, but not unthinkable.
But we've already established that these are meant for "the promotion of teaching basic computer science in schools and in developing countries". In these situations with young, untrained hands, durability and robustness are absolutely key criteria. It's not good value if it ends up discarded/broken due to additional complexity or a fault.
Or maybe you're using Pis in ways that aren't so hard on SD cards, etc? It seems very likely that this is the case given that these users experience these issues on Pis but not other systems.
No all GCSE so 14+ students. The issue is usually that they freeze or crash under "desktop use" all the time and people pull the power out and back in again to reset them. This flexes the HDMI and USB connectors which eventually break or the cables give out. During the reboot cycle is when the SD card gets borked, or randomly suddenly.
It's really a terrible computing experience compared to using a simple off the shelf windows box running python with full single-sign-on to GCPW. They don't crash and the cables are never yanked around because they are AIO boxes and the storage never goes wonky. Teachers prefer them because the first 30 minutes of a 80 minute slot isn't getting 30 raspberry pi's limping again.
So that raises the question: Why do they keep making Pis with USB power? One could argue that it's because USB power supplies are cheap and ubiquitous, but that's not really true if only 1% of power supplies are actually capable of properly powering a Pi.
They could use a different power connector that doesn't cause this confusion, or they could design Pis to use less power and therefore work properly with more USB power supplies.
MacBooks Pros are “USB powered”, too, but you need a 65W USB-C charger to get them past “Not Charging”.
A USB connector, at this point, is a PHY (like a serial DB-9 connector), not an inter-ecosystem compatibility promise (like a FireWire or SCSI port.) Lots of things use USB for lots of different incompatible use-cases. They just happen to share a connector.
But on the other hand, you can also think of it like a regular PSU: all motherboards connect to all PSUs, and there’s no way for a PSU and motherboard to communicate to “lock out” a mismatch. And a PSU will seem to work for a given configuration of motherboard+CPU+peripherals, until you drive that configuration hard enough to overdrive the PSU, and it shuts off.
The solution in both cases is the same: you overbuy on PSUs. A good high-wattage-rated power supply (whether a USB one or a desktop molex one) will power anything below that wattage requirement just fine. USB PSUs do negotiate power draw with the client device, so you can run a Pi off a big-brick laptop-class USB charger without damaging it.
And that’s mostly why Raspberry uses USB power, I think: if you already have a big beefy USB PSU from something else (as most early-market adopters do), you can use it to power your Pi for playing around, without having to buy the Pi its own PSU, if you’re not sure you want/need to set it up for its own standalone use-case.
(Also, the Pi will run just fine on a wimpy 5V1A iPhone charger if you don’t tax it very hard. Just like a cheap desktop PSU will power a gaming rig with a beefy GPU, if you never open a game. And most embedded use cases, e.g. PiHole, don’t tax the Pi very hard. So there’s a lot of cases where people get along just fine with the cheapest possible configuration, where forcing them to buy an actual power adapter would make things a lot more expensive for no gain.)
> or they could design Pis to use less power
You know that they stop selling old-model Pi’s, right? It’s not because they want to. It’s because those chips stop being manufactured upstream; and Raspberry doesn’t do enough volume to drive production of SoCs all on their own.
Raspberry is constrained by what parts they can put in a Pi that are both available and sufficient for the use-cases their customers have (e.g. driving monitors at native resolution.) Those chips have minimum power requirements. The power requirements never go down, because there’s no high-volume customer with exactly Raspberry’s use-case (where that use-case is “using process-shrinks to build a graphical desktop SoC of the same performance at ever-lower current draw, rather than achieving ever-higher performance at the same current draw.” An SoC process-shrink that is taken as-is with no commensurate re-layout for increased perf, is extremely rare in the industry. Not rare in microcontrollers, but an MCU can’t drive a desktop computer.)
You might suggest they undervolt the newer chips — and they do! — but there’s only so far you can undervolt a chip before it just stops functioning at all. (Especially an SoC, that contains DRAM that must get refreshed, IO controllers that must drive peripheral lines with to-spec line voltage, etc.)
> specially an SoC, that contains DRAM that must get refreshed, IO controllers that must drive peripheral lines with to-spec line voltage, etc.
I'm just nitpicking your otherwise great post here but wouldn't the IO voltages be entirely separate from the core voltage? Or do they all need to be kept within a certain range of each other?
Maybe you should do what our CCNA instructor did - if you brick one of the routers you have to fix it yourself.
Is it such a terrible "learning" Experience that yanking the power cable out is a bad idea as others have said the pi's should have better power supplies.
sounds like people simply weren't taking any care of them, that's why they broke. If they had cases and decent sd cards that probably wouldn't have happened.
I’m responsible for a fleet of a few hundred Raspberry Pis being used as home monitoring hubs - they use high grade SD cards, and are configured to write as little as possible while still fulfilling their function, yet we still see one or two a month fall of the internet because of SD card corruption. This is absolutely a problem.
I believe the compute module is somewhat better in that it uses eMMC rather than SD cards.
Same interface as an SD card, but better firmware and probably higher quality flash. SD cards are really aggressively cost-cut, often coming in than less than the price of raw flash of the same capacity.
As someone who has also worked with fleets of devices (R.Pi-based and others) working off SD-cards, I can confirm what jon-wood is saying. For some reason SD cards fail at a much higher rate than eMMC flash chips in traditional SMT packages.
I was under the impression most non-awful SD cards had some sort of wear-leveling these days but there's no standard for it so they don't advertise it on the front like SSDs. I couldn't really find any proof either-way about this, just a few instances of people looking into it:
I think every microSD and USB sticks by now has WL across the board, especially at awful grade. WL and ECC are must at current [price, BER, capacity, bit-per-cell] or something.
It does look like there are many of cards that don't claim any sort of wear leveling (doesn't mean they don't do it at all but they don't call it out). This is surprising to me, but if you want to make sure you get a card with wear leveling, look for it in the specs. These SanDisk industrial cards[1] are ones I've used in the past that specifically claim they do wear leveling in the spec sheet:
Advanced memory management FW features power immunity, auto/manual read refresh, ECC, wear leveling.
They're also only a few bucks more than a "normal" microSD card.
I think you’re confusing your lack of knowledge of the commonality of this with the assumption that it is rare. I don’t know anyone who expects a Pi with SD to last more than a year. And the “solution” is always to buy the more expensive SD cards that last longer. And that’s not a solution. It’s time for Raspberry to give up the SD card for a real form factor. I can get a 120gb nvme that’ll likely never fail in my lifetime of Pi usage, or carry two mirrored SD cards for the inevitable failure that’ll happen when I can’t re-image a machine (like in flight - https://stratux.me)
I've had all RPi versions except RPi4, running at least 1 of them 24/7 since the first one was released, and by the first year I had a cron that dd'd the card every night, and I found myself dding the backup image at least 2-3 times per year.
RPi3+ has had no problem so far, and I'm not upgrading to RPi4 out of fear of it becoming an unstable mess again.
I did run Boinc on over 20 different SBCs for 2 or 3 years. So they run 24/7 with 100% and I just had 2 broken SD cards from all those SBCs. I guess thats fine.
Schools may have a lab with 30, used 2h per day, makes it more than double my failure rate. Add kids popping the cards in and out all the time and you have a recipe for disaster.
I think that's because "most people" who buy a Raspberry PI use it once or twice then it lies in a drawer somewhere. In my experience, if you actively use it for something, you'll get into annoying problems like that, it's just a matter of time and how much you are hitting that SD card, or how many times you unplug it without shutting down the Pi properly.
I've had my Pi 3 running constantly for the last three years as a Plex server. The only thing that has gone wrong is the Western Digital hard disk drive that failed. The Pi itself and even the microSD card have been fine.
This spring, I deployed 20 PI's at work for a project and they are used every day, many many times a day. I've had 2 corrupt SD card failures so far. It's hard to know for certain what the cause is. We have spare SD cards to swap in for this application. For my application, having a spare SD image isn't a problem and I don't need five 9's of uptime, but the SD cards seem to be a point of fragility. Ultimately we're very happy with the system, but the SD cards are a point of failure that just need to be mitigated.
Many are remote and rural. Internet and network is frequently iffy. Has to work completely offline for hours at a time as needed, including after a power cycle.
As far as I am concerned, I consider SD cards the equivalent of a floppy disk. The equivalent of a hard drive would then be a CF card (unfortunately much less common than SD cards these days). Or of course any USB drive if we give up on the card format/connection style.
Yeah but RPi SoC is apparently lacking in PCIe lanes. I think they need a different SoC so they can finally have ethernet/storage/usb controller on the PCIe bus.
you're right, they want to not debug anything at all, they want to have a drawer full of microSD cards with the OS pre-installed. When a kid says "I have a problem" you say "ok here's a fresh install" and swap the SD card.
The RPi4 SoC already has PCIe support; it's used for the USB controller, but it wouldn't be impossible to have a version that has an M.2 PCIe slot. It could be used for NVMe, WWAN or faster Ethernet.
USB could remain available through USB OTG and it would sit in the middle between the RPi4 and the Compute Module 4. Using the USB power socket for OTG is doable already on the Pi4, but to do it in a fully supported way would need some extra components to properly handle USB-C configuration. Still cheaper than an H2plus
If would make sense to be able to attach a $25 32GB SSD to the bottom of a RPI. Then add some kind of a U-shaped connector to connect the RPI to the SSD and a place for the screws, so that they are fixed back to back.
If only there were some kind of bus that were universally available so we wouldn't need such an awful, hacky solution. Something capable of transferring all that data serially.
I was going to say the same thing. The RPi was introduced at a time when cheap SATA SSDs weren't a thing, nor were beefy ARM CPUs. It's starting to feel like an Edward Scissorhands situation.
This is misleading. You have removed the first part of that sentence "Early on, the Raspberry Pi project leaned towards..."
Whilst education is still important, particularly on the charity side, these days the RPi Trading division explicitly targets multiple markets, for instance, the compute boards specifically targeted at industrial usage.
This product is described in their own press release as targeting the christmas toy market amongst others.
The alternatives to RPi don't have nearly as rich selection of polished software, vibrant community and ecosystem as Raspberry Pi has. The best parts (besides hacker-orientedness) of RPi are its uniformness and popularity.
eMMC storage are comparatively very fast, and I believe they have a comparatively little or negligible impact on the end price (competitors like Hardkernel put it in the directly competing products).
FWIW: Now you can get raw PCI-E access with the Compute Module [0] + IO Board [1], allowing you to put a SSD on there over a robust interface.
But yeah, I would also love this to be built in on something like the RPI. Closest option according to my research is probably the Rock Pi, but then it's not really straight forward to boot from it etc...
I know relatively little about the Compute Modules... Are there any decent "racks" for these that would allow you to assemble many of them into a single unit?
The RPi 4 has USB 3 + UAS which is actually quite decent. I use it for Aarch64 development[1]. It boots and runs entirely off the SSD, and the performance is not spectacular but perfectly usable, and being it's a regular SSD it should be at least as reliable as a laptop.
It also has a firmware bug where it cannot boot unless there is an (empty, unused) SD card in the slot, which is annoying!
I've never had the problem either - I started using the RPi4 seriously when it became possible to boot from USB, and it's great. USB boot is working properly in the newest Ubuntu Server and Ubuntu MATE Desktop images as well as the official Raspberry Pi OS.
The Samsung T5 and T7 are frighteningly fast USB-attached portable SSDs - some simple tests of mine had them at around 335MB/s. On paper the T7 should be twice as fast, so it's interesting that they tested so close (the T5 was even a little faster, as high as 350MB/s), but they are both totally good enough.
I boot a RPi 4 via PXE (or rather, the RPi version of PXE, which is decidedly non-standard, meh). No SD card in the slot. No problem. Are you on the latest firmware?
I agree 100% with this. I have a fairly large tinker shop with 20-30 different machines and initially bet on the Pi platform to do CNC/Octoprint/robotics/etc controls, thinking I should standardize. Most of the Pis failed with storage issues eventually; be it eMMC, microSD or USB flash drives. Since then I've moved on to x86 based industrial motherboards which ended up costing about the same when you include everything. Zero problems since then. And boot times are now measured in seconds, not minutes.
Jeff Geerling (HN:geerlingguy, who is participating in this comments section) has demonstrated using a NVMe drive with the RPi 4 Compute Module and its IO board, which has a PCIe slot.
Pi 4 compute module breaks out the pcie port which is use for usb 3.0 on the pi 4. This means someone could make a motherboard with an m.2 M-key socket. The pcie port could also be routed to a switch to be split among multiple pcie devices such as usb 3.0, ethernet and so on.
FWIW I’ve used a rpi1 then 2 then 3 as my Kodi/openelec/libreelec box for years each and it’s been running very smoothly. Maybe not the most demanding in terms of storage writes but still, I’m very satisfied with it.
> An M2 SATA or NVMe would make this credible but 99% of the problems I've had with the Pi platform is storage related, either being knackered microSD cards, terrible performance or USB power problems.
It sounds like literally all your problems would be addressed by using the official power supply and a USB-connected SSD - although your problems might very well be solved just by using the official power supply and a decent SD card.
SATA and NVMe interfaces are something some nerds who aren't the target audience for this hardware would like but they don't address the real-world problems you mentioned at all.
I used to have the low-power indicator show up all the time in the past, but it seems the usb-c power supply has resolved that.
Additionally usb boot + usb3 speed has made running completely off of usb instead of sd a good solution. There are also pretty fast yet small form factor drives like the samsung fit to choose from as far as physical size.
Android phones are useles... no ethernet, no gpio, shitty cooling, hard to get an OS installed, hard to debug, and compared to RPI4, too expensive.
RPi4 is great... small cheap, basically a full pc in a small box, with low power usage, low heat production, no noise, and yes... with a shitty storage solution.
Some Android phones use (or used to use?) flash-friendly file system formats like F2FS, JFFS2, YAFFS2. I'm not sure if that's still a thing but it would be interesting to know the pros and cons of using one of those instead. Interesting I did find they are/were considering F2FS for the RPi: https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=2734...
Even with the cost of a $5 ethernet adapter, you can get Android phones significantly cheaper than a Raspberry Pi.
GPIO is a bit trickier, since most devices don't break it out, but for some purposes the audio jack is usable. There's also USB-GPIO adapters but they can be a bit pricey (although if you're interfacing with something like an ESP32 BLE works really well)
