Introducing raspberrypi.com
raspberrypi.org
raspberrypi.org
[ https://www.raspberrypi.com/products/compute-module-4/?varia... ]
https://www.cnx-software.com/2021/08/10/mincab-smallest-rasp...
That's pretty small! But the point of the CM carrier boards is that they're completely dependent on what IO an individual user wants.
For some, that's dual Ethernet; others have no idea why you would want more than one Ethernet port. Still others don't know why you would want any RJ45 at all: they don't have Ethernet throughout their house except between the modem and the router (if those are separate devices!). They'll just plug a Wifi dongle into the USB hub.
As a carrier board designer, you've got to ask this question for everything from ADCs to Z-Wave wireless. The Raspberry Pi carrier board just included all the defaults provided by the connector, with minimal external components. Also, they did it with a 4-layer board and open-sourced the Kicad design files; if you want a subset of it you can make it!
Brand-name SD cards will fail in 6-12 months of running a typical mostly-idle Linux installation (yes, I've heard it all: power supply quality, improper shutdowns, counterfeit cards, etc. etc. It doesn't matter - SD cards just die all the time)
I've yet to see an eMMC chip fail on a Compute Module. I'm aware of one Computer Module that's been running for around 3 years as a CI/build machine, so it's under a pretty write-heavy load all the time. I expected it to last 3 months. It has not died (yet).
Regardless, I understand that hardware dies. But generally speaking I'd like to be able to deploy a single board system and not have to worry about having to physically maintain it unless it literally fails for some reason.
I didn't think this was a really contentious idea. I've had several Pi projects that I needed to mess with because the SD card died. So it seems like a logical evolution would be for the Pi to have more robust storage out of the box.
IIRC the most destructive thing to a rpi that is SD-storage only is excessive logging. If you use journald (part of systemd) you can configure it to only keep a small rotating in-memory log, if you use traditional textual logs you can probably do something similar by mounting a in memory fs on the log path.
If you need to keep logs for longer (or between boots/crashes) it's probably good to not use the SD-storage for that. IIRC Tesla had problems with their eMMC storage because they used it for log storage and I've worked on related parts for IoT devices that used SD-cards.
I'm not sure how user-friendly/defaulted all of this is on the recommended rpi distros.
You can run NVMe on a Pi4, sort of... if you replace the USB3 controller with a bridge PCB that routes PCIe out the USB ports properly for some other adapters. I don't recall if they got it working reliably or not. And then if you use the CM4, you can certainly have reliable NVMe.
But I'm just not sure it really matters. USB3 SSDs, UAS or not (I've run into UAS issues and while you can tell the difference in a benchmark between having it and not, I can't tell the difference in end use) are more than fast enough for daily use.
I've done a writeup of making a Pi4 desktop here: https://www.sevarg.net/2019/12/14/building-raspberry-pi-4-de...
The only real change is that the kernel now has zswap provided as a module, so you don't need to build a kernel unless you just think building a kernel on a Pi is cool (which it indeed is).
It's not fast, but it's more than adequate for light desktop use. If you want more guts behind it, the ODroid N2+ is about twice as fast, for not an awful lot more money.
How does one do that? I've been bitten with block-level and then filesystem-level errors, so I just recommend always disabling UAS. [1] But if you have a good way to make sure UAS is fully reliable, I'd love to update my recommendation.
[1] https://github.com/scottlamb/moonfire-nvr/wiki/System-setup#...
You can technically just disable UAS like you said, but you'll likely lose some drive performance. But if filesystem corruption is a concern then you're probably safer disabling it.
See "Log to RAM" (I really need to start putting Anchors in my Hugo markdown).
I don't feel on especially solid ground saying that - although I've experienced dead (micro) SD cards myself. It's a controversial topic, and no doubt some people are confused by what's just filesystem corruption. There are flamewars.
Theres an NVMe interface for sd-cards now. That'd beat the tar out of eMMC. Downside, the sd-card might use as much power as the cpu.
https://www.anandtech.com/show/16938/silicon-motion-sm2708-s...
[0] https://thepihut.com/products/raspikey-plug-and-play-emmc-mo...
I've had at least a couple pis of various models (currently a 2 and a 4) running in the house since the very first model hit the market, early on I had issues with SD card corruption too. But after a while I finally took the PSU requirements serious & put in quality cards, haven't really had any issues since.
However as a desktop it is not. The Pi400 I am testing as a desktop generally doesn't run smoothly. I've tried various distros and now I'm toying around with NetBSD. The browser (firefox/chrome) are slow and the system constantly gets "stuck". It's not smooth for daily use, e.g. writing a blog post? Even that will not be a smooth experience most of the time.
My SD cards are EVO Pro 60 MB/s read 90 MB/s write cards. What are you using?
I use my pis as servers as well, though I recently phased out a pi2b that was running homebridge, it was just too slow and devices would report as 'offline' randomly because of it. On the pi4 though I'm using 2x Octoprint instances in Docker and couldn't be happier. Going to pick up another 4 to run Home Assistant/ESPHome/any 'smart home' software because it is temporarily all dockerized on my ZFS server.
For PSUs I use the official RPI ones, they completely eliminated any weird issues I had using even plenty rated random ones I have lying around. As far as SD cards I grab whatever Walmart/Target/BestBuy have in stock at the moment with a U3 rating. Haven't had any corruption or speed issues with that combo, and I semi-frequently reboot by just yanking the power instead of walking upstairs to the computer.
.org for educational/community/collaboration.
So more of a focus on commercial products & services. Got it, wish the team all the best!
My understanding is that the GPU is used to boot ThreadX which then allows for Linux to be booted, is that right? Only the embedded-focus Pico chip does not have this.
Seriously now, I would expect mostly minor revisions until they can move to another SoC (and it's probably easier to move to a near-identical, higher-specced part right now).
It has already been admitted.
[0] https://www.telegraph.co.uk/business/2021/03/13/raspberry-pi...