Introducing raspberrypi.com(raspberrypi.org)
raspberrypi.org
Introducing raspberrypi.com
https://www.raspberrypi.org/blog/introducing-raspberrypicom/
44 comments
I'd have got a RPi4 by now but the compute modules are as difficult to find as hen's teeth unfortunately. Stuck with a RPi3 for now.
It looks like the corporate arm of the Raspberry Pi company is trying to go public, despite denying it the past. [0]
It has already been admitted.
[0] https://www.telegraph.co.uk/business/2021/03/13/raspberry-pi...
It has already been admitted.
[0] https://www.telegraph.co.uk/business/2021/03/13/raspberry-pi...
Not going public, but attracting investors and a sizeable charitable donation.
https://web.archive.org/web/20210920112614/https://www.teleg...
Completely unrelated but front of mind for me since I had a project die this morning - I really wish they'd release a Pi with eMMC storage instead of just the SD card. I know theres alternatives but none of them have the same community and support as the Pi.
The Raspberry Pi Compute Module has eMMC storage.
[ https://www.raspberrypi.com/products/compute-module-4/?varia... ]
[ https://www.raspberrypi.com/products/compute-module-4/?varia... ]
Yeah now it's just a matter of time till someone makes a dock for it that isn't 1 square mile in area: https://www.raspberrypi.com/products/compute-module-4-io-boa....
Like this?
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!
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!
There are probably close to a hundred different boards already.
Here is a somewhat complete list: https://pipci.jeffgeerling.com/boards_cm
I too would like either a "normal" Pi with onboard storage or a (readily available, small, useful) carrier board. Either of these things is not 100% there right now :)
Yeah it would just be nice to buy a single piece of hardware that had it baked in.
The wear of the sdcard can be lowered using zram and log2ram. The only distribution i know that does that by default is https://dietpi.com/
This part of my Kubernetes on Pi series of blogs describes setting up Log2RAM if people are interested in doing it manually: https://2byt.es/post/bantamcloud/02-configure/
See "Log to RAM" (I really need to start putting Anchors in my Hugo markdown).
See "Log to RAM" (I really need to start putting Anchors in my Hugo markdown).
Not sure the problem is just wear. The SD card seems unusually likely to be destroyed by power cycles or brownouts.
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.
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.
It's a bit finicky to get working/set up (make absolutely certain that your USB to SATA adapter has proper UAS support in ARM Linux), but you can boot the Pi4 off of a USB SSD now. Still might not be what you need, but it's way better than booting from an SD card.
I've gone that route before. My main thought is that it seems like the Pi itself should have more robust/longer lasting storage just be default at this point.
What's more robust and longer-lasting than SD and USB sockets? Flash storage is inherently unreliable and prone to failure, so keeping it on pluggable media is the sensible thing to do.
Well I thought eMMC, but as you indicated that's basically just a SD card soldiered to the board (which I didn't know). So NVMe?
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.
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.
I think most people with those requirements treat the SD card as a bootloader and keep the main system on a USB connected SSD (or make the system not write-heavy while still only using the SD). It'd be nice to have a rpi that supported NVMe (or just more reliable boot from USB) but I can see why that is not exactly in-scope.
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.
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.
This is how I run mine - SD for boot, USB SSD for root.
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.
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.
I’ve had enough trouble with SD cards and regular drives that I ended up replacing the storage for all my important Pis with external SSDs, and I’ve been pretty happy with them. I’ve found that it’s worth the price and portability trade-offs.
> make absolutely certain that your USB to SATA adapter has proper UAS support in ARM Linux
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#...
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#...
Basically this list of known working adapters is your best bet: https://jamesachambers.com/raspberry-pi-4-usb-boot-config-gu...
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.
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.
I don't think that list is good enough. I've had adapters work fine for months with UAS and then have errors. I went through a few rounds of that, disabled UAS, and haven't had problems with the same adapters for a couple years since. So I believe there are adapters out there that more or less work with UAS on Linux but under some infrequent condition (likely load-related) cause these sorts of errors. So a table of "Known Working Adapters" with notes like "Reported as working with UASP support by pierro78 in the comments" doesn't address my concern.
Check out the Compute Module and something like the Piunora: https://www.crowdsupply.com/diodes-delight/piunora (bonus: you can also use NVMe storage).
I hope they get you writing on this geerlingguy - really enjoy your Raspberry Pi investigations.
eMMC is literally an "embedded" version of the same storage media as SD cards. If you're worried about your SD card media dying on you then eMMC is strictly worse; SD cards are at least socketed so when one dies you can just replace it. With eMMC you'd have to desolder the chip.
In my experience, SD cards and eMMC chips on the Raspberry Pi Compute Modules are night and day in terms of reliability.
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).
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).
I've always used Sandisk cards with A1/A2 rating (high iops) since they exist and I've yet to run into a single problem with them. Cards without that rating otoh ...
I've just ssh'ed a remote rpi with sdcard and logging active (Devuan stable) and it's uptime is almost 2 years. The sdcard in it probably has a year more there.
My understanding is that SD cards have a certain write count before they fail (or require a reformat), and that eMMC doesn't. Or that the number of writes before failure is much higher. Is that not correct?
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.
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.
eMMC is flash media, typically with a very minimalist FTL. Of course it's going to have a write count.
Yes, exactly: Tesla found this out the hard way.
> I really wish they'd release a Pi with eMMC storage instead of just the SD card.
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...
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...
Perhaps something like this[0] will work for you?
[0] https://thepihut.com/products/raspikey-plug-and-play-emmc-mo...
[0] https://thepihut.com/products/raspikey-plug-and-play-emmc-mo...
The SD card effectively turns the RPi into a toy. I am going to test it as a desktop with an external self-powered USB drive soon, but as for the Pi400 has been a disappointment because did the SD card. The system is unusable.
What issues are you having related to the SD card?
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.
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.
I have many Pis lying around as well. I have DNS servers, torrent servers and I also run a k3s cluster on RPi3s. It's okay-ish for these kind of projects.
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?
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?
Ah, sorry I totally brushed through the fact that the Pi400 is meant as a desktop replacement. Yeah I don't think I would be happy using any pi speed device as my desktop, they're just too slow in my opinion.
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.
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.
I am curious if there has been any progress on the removal of all binary blobs from the Pi's?
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.
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.
.com for commercial products & services.
.org for educational/community/collaboration.
So more of a focus on commercial products & services. Got it, wish the team all the best!
.org for educational/community/collaboration.
So more of a focus on commercial products & services. Got it, wish the team all the best!
Unrelated but I wonder how far is the next major Raspberry Pi version. It's been over 2 years since the last version.
It would make a nice Christmas present, but given the current state of affairs in the chip industry, I'd say it's only going to be a reality next year--unless there are some surplus yields of Broadcom and DRAM chips squirrelled away someplace.
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).
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).
Fab Capacity, DRAM, NAND, Silicon Price Hike..... I wouldn't be surprised if the next version is sometime in 2023.
What would you want to see in a new version that isn't in the 4 or other pi variants? Personally I'd like more USB3 ports, but it works for all my other needs.