This looks delectable for the eMMC storage alone. I wish there were a Raspberry Pi model that came with it... I'm tired of SD cards causing problems and eating my data or (more frequently) causing the Pi not to boot.
I also wish Raspbian had an option to mount all the write-heavy directories (logs, etc) on tmpfs, so they wouldn't wear the card out so quickly.
Well it's just Linux so you definitely can and that's what I do. As a result I've been running my pi 2 on the same card for nearly 4 years now with no issues. But if your point is that it should do it out of the box for you, I agree it shouldn't require manual setup.
That's great! I'll need to rebuild my Raspberry Pi if that's the case, maybe make everything run in some repeatable way so I can reprovision quickly if I need to, thank you.
When done properly, SD cards are reliable enough. For my digital signage product the custom OS is highly optimized around avoiding IO as much as possible. There are thousands of devices, some running more than 4 years now, without any SD related problems.
I also really like the fact that the Pi is pretty much stateless. So switch SD cards and you can be mostly sure everything still works. If storage is bundled, that's a lot more difficult.
For most use cases, SD cards on Raspberry Pi's are not reliable enough.
I realize you may be successful in running signage devices, but most people want to simply be able to run common class 10 card (e.g. from Verbatim, Kingston, Sandisk), using a standard OS setup and leave the Pi running without having it corrupting your files. This simply isn't possible, in my experience. Also look at the OpenHAB forums as a reference.
The more regular disk activity, the worse it gets.
We went this route in our office and every 3-6 months we had corruption on each of many dozen Pi's. Once we switched to using USB drives (spinning or SSD) the issues were sorted out.
> but most people want to simply be able to run common class 10 card (e.g. from Verbatim, Kingston, Sandisk), using a standard OS setup and leave the Pi running without having it corrupting your file
To be fair: try the same with cellphones. I have a shitload of micro-SD cards gone bad on me, and yes genuine SanDisk not cheap fakes off of Amazon.
microSD cards are the cheapest crappy flash chips you can get with a microcontroller strapped in front for error correction.
I don't even put SD cards in my phones anymore due to corruption. I always got the best SanDisk's I could find. Luckily my Pi that runs probably 8 hours/week hasn't failed, but I have the drive imaged just in case.
Cheap SD cards are going to return less than desirable results. Higher quality cards such as SanDisk Ultra Mobile or Samsung Pro series should last quite a while when used as a normal "disk" on a system like this. As an added benefit, using a card like a Samsung Pro will also get you MUCH better file system speed for both reads and writes on common Linux file systems like ext4. The controller inside a Samsung Pro series card is much more advanced than run of the mill cheap Kingston cards.
If you really need durability, there's also a handful of SLC (single level cell) SD cards on the market which will last an order of magnitude longer in terms of writes as compared to consumer level MLC/TLC cards. SLC cards aren't cheap but you get what you pay for.
> Higher quality cards such as SanDisk Ultra Mobile or Samsung Pro series should last quite a while when used as a normal "disk" on a system like this.
Nope, it's mainly marketing. Cards from those brands are fundamentally not great for sub million unit purchases. We tried to use some for the root fs for a fairly high availability appliance. If you don't want one in twenty going out in a month (and we figured out a way to make them go out after 8kb/s for 8 hours with a specific access pattern without power drops), then you need 'industrial SD cards'. They'll treat you like adults when it comes to support, will have lot codes that actually map to internal changes, etc. Trying to sell a product with consumer SD cards (yes, even the ones that call themselves 'Pro') is basically a futile exercise.
Sure, but I don't have the time to highly optimize a custom OS just to put up an MQTT server in my parents' house. I want to do the work once and have it Just Work after that.
Out of interest, how did you approach disk encryption? That would be my concern with removable storage. The other thing I'm keeping an eye on is Arm's LittleFS for storage longevity.
It's possible to write 256 bit of user data to the Pis internal OTP memory. You can store a non-changeable key there. Of course that's then easily readable if you can run execute commands on the Pi.
LittleFS (recently posted here) is indeed interesting, although from the documentation I couldn't figure out
1) if it works for larger devices as it seems it seems mostly intended for sizes of a few MB. I might be totally wrong with that.
2) if/how it handles corruption of complete blocks(?) of SD memory. As far as I understand, an SD card doesn't necessarily use 4K block sizes and corruption might hit multiple blocks at once. If LittleFS stores both previous and next version next to each other, I don't think that'll help in that case.
Oh, there's an OTP in the MPU? I didn't know that.
Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity.
With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable.
I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design.
Oh yeah, I recommended these in the past and just mentioned them again in another comment on this thread :)
4GB is enough for most Pi projects, and <$20 premium is worth never needing to worry about SD reliability to me. My understanding is they use multi-level cells, which are far less expensive than true industrial grade single level cells, but they only write a single value to each cell, increasing the reliability significantly.
Industrial grade AMLC, for example from this reseller and brand, haven't let me down yet. Other HN users have a similar experience. The downside is the price. Delivery was one day from Springfield to The Netherlands but had to pay duties. Which is like a total opposite of China: bad quality, cheap, slow delivery, but no duties
Explanations: The script creates a /var/log mount point in RAM. So any writing of the log to the /var/log folder will not actually be written to disk (in this case to the sd card for a raspberry card) but directly to RAM. By default, every hour, the CRON will launch a synchronization of the RAM to the folder located on the physical disk. The script will also make this copy of RAM to disk in case of machine shutdown (but cannot do it in case of power failure). This way you avoid excessive writing on the SD card.
I had problems with Samsung and SanDisk cards, which worked fine in a GoPro, and troubleshooting the weird Pi symptoms was aggravating. So I tried aMLC cards from ATP and have had zero issues. They cost significantly more (~$20/ea for 4GB @ qty 10 from Digikey w/shipping) but it’s worth avoiding the hassle to me.
Obviously 4GB is not a lot, so I use tmpfs and USB storage as appropriate.
Interesting, I definitely have not tried those yet. The Sandisk cards performed consistently worse in my experience, but I figured that could be anecdotal, and I had plenty of issues with Samsung as well.
Maybe once upon a time, but with blobless mainline Linux kernel support for almost all features on almost all SOCs[1], including video codecs on many parts[2], anyone claiming Allwinner to be "the devil" or variants on a theme is unambiguously incorrect. Broadcomm and the raspi foundation are evil. [3][4]
"CM3+ will be available until at least January 2026" - That's an impressive commitment. I'm pleasantly surprised to see them stick their necks out that long into the tech future.
It's not horrible but it's not remarkable either. 8 years is a decent but it's nothing compared to other SoM (system on module) vendors like Toradex. Toradex generally offer 12+ year commitment on their SoMs.
Consider that if you start a design now using a SoM that you probably won't get to market for at least 1 year. Then in the industrial/commercial space it'll take at least another year for your sales to ramp up. If you started today designing with a CM3+ then you'd get 6 more years of sales out of the product after sales ramp, but since the above timeline is going to hold for your replacement of the current product, you're going to have to start engineering on the replacement 6 years from now. For some industries this will sound amazing, for others it'll sound like a deal breaker.
If you look at SoC (system on chip, the processor) vendors, generally they're offering 20+ years of sales from release for SoC which target the industrial/commercial embedded markets. Vendors like TI or NXP don't generally end of life their silicon for a very very long time.
If you need 15/20 years, you get a separate contract. 7 years as a baseline is not too bad, for that kind of device, but likely not sufficient on its own. Automotive test-beds etc. would require longer timeframes.
The other thing that impresses me is that the modules have remained electrically compatible, so (at least in theory) you could slot out a CM1 for a CM3+ and still expect it to work.
I remain surprised that there don't seem to be any of the shelf "blade centers" for raspberry pi compute modules. It seems like they're the ideal hobbyist and small business expandable computing resource.
I use the sopine cluster modules and a clusterboard for my docker swarm. The sopine modules have a quad core and 2GB of ram and a sd card slot. It is a cheaper way of having a docker swarm (you could run kubernetes, but that is overkill).
As for the Raspberry pi module, it is the same price as the sopine module and half the RAM. One could argue the pi is better supported, but the sopine modules support armbian (and are actually in stock).
So is it worth it, well not right now. If you buy the module and the base board it is just cheaper and better to by a pi 3+. I saw a pi compute module backplace to hold 5 (i think it was 5) modules for like $250 (a pine64 clusterboard for 7 modules and a built in Gb switch is $100).
There are probably uses for it, maybe custom embedded devices, but i am not 100% convinced. I was a lot more excited about the Raspberry Pi 3+ Model A. That is nice for the price, but even then nano pi's have comperable devices for simliar cost (and are actually in stock).
I still love Raspberry Pi's though and can't wait until the 4 comes out. But as my Rock54 screams with a quad core and 4GB of emmory and usb3 for $45, i am questioning what a raspberry Pi 4 could bring to the table for the same price (M.2, 8GB of ram, etc...).
Slightly off-topic but does anyone known any good similar modules with support for LVDS and/or eDP displays (15"+ ideally)?
I've been wanting to assemble a sort of tablet device but I am having a really hard time finding a display/compute combo that will work with any confidence. I would ideally like to avoid having to get a separate A/D board.
If you go this route, be forewarned: not all SSD enclosures work. Do a bit of research on Raspberry forums before making any purchases. Also, Pi 2/3/B+ sadly don't support USB 3.0 devices, so much for backwards compatibility. I bought a handful of cheap SSDs and USB 3.0 enclosures for this exact purpose, but still haven't got any of them to boot, even though I did research and supposedly bought several from Sabrent that should work. In retrospect I should have looked closer, Sabrent makes a bunch of very similarly named drives with slightly different specs, some of which apparently aren't compatible. I found a forum comment suggesting to try the enclosure with USB 2.0 cables, but that avenue has been fruitless thus far. I will probably have to order some USB 2.0 enclosures.
Requires a SD card containing an updated bootrom on Pi 2.
Pi 3 has the update bootrom but needs a bit flipped in OTP to enable the feature.
Pi 3B+ has network and USB booting enabled out of the box.
Thanks to other commenters for the Balena and miniNodes links. I would be interested in something neatly packaged so it would look nice on my desk that had about a dozen computer boards with local networking set up.
The other option for that use case is the Pi Zero W, which is probably a bit friendlier for most use-cases. It has the older BCM2835 from the Pi 1 (but at 1GHz) – it's quite a bit cheaper, though does require the additional SD card.
I also wish Raspbian had an option to mount all the write-heavy directories (logs, etc) on tmpfs, so they wouldn't wear the card out so quickly.