In it they say "Back in March, we explained that the 3+ platform is the final iteration of the “classic” Raspberry Pi", I've tried finding the corresponding blog post but didn't have any luck. Does anyone know where I can read more about this ? I'm interested in hearing more about their need for "new core silicon, on a new process node, with new memory technology".
Basically they're reached the limits of what you can do with a 40nm process within (well, mostly) the power/thermal limits of USB microB with a basic heat spreader. While the ARM A53 cluster would almost certainly be available in smaller nodes, the uncore has sort of outlived it's welcome anyway.
This line of chips from Broadcomm can only support 1GB of Ram, a hard limit for what type of applications one can put on it. Meanwhile, other SBCs have mainline kernel support now and boast 2GB or even 4GB of Ram.
I gave up on using raspberry pi after it destroyed several expensive micro SD cards. The device is amazing, but the dependence on brittle micro SD is a deal breaker for me. I just want to boot over USB with no micro SD. Have they solved this issue?
First: Your SD cards are most probably not destroyed, but have corrupt file system due to the unsafe shutdown.
Second: You can boot from USB with no micro SD with latest firmware. RPI will look first for SD card and then try to boot from USB if no SD card is found. You can even set a one-time-programmable (OTP) bit to skip SD card lookup.
The 3B+ has ethernet (and it's gigabit - at least gig sync - ~250Mb/s max actual transfer due to USB2.) The new one (3A+) does not have ethernet but is still capable of USB booting.
I have probably 8-9 Zero W boards in projects at this point, running everything from cat cams, temperature sensors in various rooms, even my stereo amplifier is controlled by (but not passing audio through) a Pi Zero W.
All of them now have a very specific model industrial MicroSD card in them, and none have lost or corrupted data, or refused to boot, since those cards were added. They had SanDisk ultra cards before that, and they had to be reinstalled all the time.
I picked the card because it's an aMLC* model (cheap overall, $15 for 4GB, $25-28 for 8GB), which significantly improves write endurance even compared to MLC cards, and because the controller is designed to handle sudden power loss, which is where a lot of these Pi+SD problems come from; consumer MicroSD cards are generally designed for use in devices that have batteries and rarely if ever lose power suddenly, so the controller can take risks for optimization that it wouldn't otherwise want to take.
They're also rated down to 0C, which I can say is definitely true as I have some operating close to that right now.
4GB isn't huge in a world where 32/64GB cards are common for a similar price, but a full headless OS installation doesn't even take half of that, and there's no real use for more space most of the time.
* with aMLC mode, it's still MLC flash (so cheaper than SLC), but each cell only stores a single bit rather than 2 (MLC) or 3 (TLC), so there are only 2 voltage states it needs to be able to measure, rather than 4 (MLC) or 8 (TLC). That means you lose some storage capacity (half vs MLC), but the tolerances for the voltage measured in each cell is significantly relaxed, so it remains usable long past the point where a plain MLC mode card would not be able to accurately program and measure the voltages that represent the 2-bit values of 00, 01, 10, or 11 anymore.
You should use something else for most of these, as the Raspi is hugely overkill. Something like an ESP8266 is much better suited for sensors and things like that, and it comes with onboard storage that it uses to run its code from.
Plus, it costs $3 each, is stamp-sized and has Wifi.
The Pi boards actually replaced ESP32 boards running ESP-IDF firmware I wrote, I probably have 15+ of them at this point and still plan to use them for other things.
The ESP32s were routinely dropping from WiFi (some being crashes, some just disassociating and never connecting again). ESP-IDF has had quite a few WiFi fixes, but it's difficult to guarantee that your own code isn't directly causing the problem (which you get for free running in userland on Linux), and dealing with it was becoming a huge time sink.
Most of the Pi Zero W boards I have were $5 at Microcenter, the MicroSD adds to the cost a little but they're extremely reliable as a result, and my own code is no longer running in the same address space with the scheduler and WiFi driver under extremely tight memory constraints :)
I use the ESP8266 and ESP32 for projects too - but the PI is sooo much easier to work with with a full linux distro and programming languages and libs to go with.
the ESPs are most definitely better for higher volume solutions
Hmm, you think so? I hate having to always keep Linux up to date. I prefer to just load micropython onto an ESP and be done. I use the Pi for heavier workloads, but that does mean it very rarely gets used.
fwiw - as an addendum to that comment - I like using S3 to get my data off the zero w ASAP. ..then corrupt os etc doesn't cause too much down time and data loss.
If you store your data under /run (or /var/run) your district will probably put it on a RAM disk. You’ll lose it in a crash, but you won’t be writing to the SD card and provoking it to corrupt in that crash.
If you then adjust your systemd journal to not write very often you have eliminated most of your SD writes.
The remote sensor systems I run lose power from time to time during the year, sometimes once a day. I’d say each time there used to be something like a 0.1% to 1% chance of corruption. Since I’ve moved to /run and a slower journal I haven’t lost an SD card[1]. Thus far it seems I have at least an order of magnitude improvement.
[1] Well, I had a wind turbine tower collapse in an inaccessible location. The raspberry pi is in a lake now, but it can’t have gone far so I don’t call it “lost”. I’ll dive and recover it in the spring. That camera/sensor has spent a couple months underwater before. In fact, I’ve had three systems end up underwater for months and all the SD cards have been fine when recovered.
> If you store your data under /run (or /var/run) your district will probably put it on a RAM disk. You’ll lose it in a crash, but you won’t be writing to the SD card and provoking it to corrupt in that crash.
> If you then adjust your systemd journal to not write very often you have eliminated most of your SD writes.
The trouble is that the OS isn't the only one writing to flash in the card, the MicroSD card controller is erasing and writing to it at random times as well even if the filesystem is read-only, with no coordination between it and the OS.
As a result you can easily end up in situations where the card decided to run some housekeeping to manage the flash just milliseconds before a power cycle or a power loss, and seemingly all consumer MicroSD cards are not up to the task of keeping the data intact at the same time.
About 5 years ago, I was running a startup that had Raspberry Pis (we really need a better plural) deployed to numerous customers, and SD card corruption was a big problem. If I remember correctly the problem generally happened when there was a power loss during writes to the SD card.
I ended up creating a RAM disk and only writing to that. Once every 5 minutes or so I would flush anything that needed to be permanent to a partition on the SD card. And once every hour I'd save anything really important to an s3 bucket. SQLite also performed much better running in memory than it did directly from on the SD card.
That mostly solved the problem, but I still shipped every unit with an extra SD card and instructions on swapping it out just in case.
SD-card corruption is a real problem on RPi (see OpenHAB forums). Supposedly the SD-card driver is not the greatest which together with the system's design makes writes fail silently. This cost is half a day once, since we did not understand what was going on with a config not being persisted over reboots.
Mounting root read only and only writing explicitly through the "ro/re" scripts helps a lot and should be the default IMO.
The biggest issue some people have with RPis though, is their hackish software, e.g. the kernel. This has become better apparently, but it always was a shame that you couldn't just run a generic kernel/distro.
I had good experiences with the BeagleBoneBlack, they come with eMMC and quite a few smart additions (e.g. a power button). Twice as expensive though.
We're using hundreds of raspberry's as digital signage devices and before deploying them I checked a few of them and found out that sometimes the source files of the app were empty.
After a lot of headscratching and googling we boiled it down to a write delay to the SD card.
If you do echo "test" > test.txt and power off the device like 5 sec. after, and power it on again, there was a file called test.txt with 0 bytes.
I'm still baffled how something like this can be a common problem especially since raspberry pi usage is so widespread
I operate a digital signage service (https://info-beamer.com). It's using a custom built Linux OS that is highly optimized to deal with file system corruption and unexpected reboots:
* The OS is is always read-only. While this doesn't prevent all possible corruption scenarios, it's pretty close and you can be quite sure the system always boots.
* System updates are implemented as A/B. So even during updates, the OS the system booted from isn't touched.
* All content data is on a third partition and together with the OS files is constantly checked for indications of corruption.
* If the OS detects any bit error on the OS files, it is reinstalled (using the A/B mechanism above)
* If there's a bit error on any of the content files, they are deleted and downloaded again
* If the content filesystem is broken beyond repair the system reformats everything and restores everything automatically by redownloading
* Various watchdogs and checks constantly monitor system health and notify you on the dashboard.
The service has multi-million hours of service by now and the only case of filesystem corruption was due to a really crappy SD card. When done properly, the Pi can be reliable. That's also the reason why there is no way to properly shut down the system. Just unplugging power shouldn't be an unexpected circumstance but something you optimize for. Starting with a normal Raspbian and expecting that to work is a bad idea.
I have a use-case in mind where the power might disappear suddenly and often. Is there a different SBC board and OS which is optimal for this use-case?
You might want to look at some of the 'Pi UPS' systems which have been developed. Once they indicate the power has failed you can start a graceful shut down. One example can be found here:
In my opinion it seems the Pi was too good at fast and cheap prototyping and people started shipping products based on it, overlooking the fact that the hobbyist and unreliable nature of the board wouldn't necessarily scale as hoped.
It always looked to me like the Pi was supposed to be used some steps before hardware integration and shipping.
I am glad products are built on it but I was a bit worried when I had to evaluate a Pi based solution for digital signaling last year. Maintenance was a key factor in the proposals.
Yes, in fact you'll find lots of source code out there that will write test.txt.tmp and then close and rename it to test.txt, exactly because this is an issue in all filesystems. From the sounds of it the time window during which RPi is vulnerable is longer than usual. A careful choice of filesystem journaling/integrity flags would probably help.
The fact that there's a 0-byte file instead of a completely broken file system is already the result of a journal. You can reliably observe this with ext4.
It was an unsafe shutdown, meaning I just pulled the plug. But it was at least several seconds after saving it. I've never seen behaviour like this before.
Most sd cards are formatted fat32, and do not have a virtual filesystem cache and write scheduler buffering work in ram for them.
Also raspis do NOT like big fast SD cards with tight tolerances. I've had the best luck with old class 4 cards. Class 10 cards don't last nearly as long with regular power cycling.
You can force a partition to be mounted "synchronously", where writes aren't buffered in RAM and then flushed later -- every write blocks until it is written to disk.
The options are the third column in your /etc/fstab file. For example, if you had "errors=remount-ro", you'd change it to "errors=remount-ro,sync".
Did you ever run linux with ext2 (not ext3 or ext4) on a desktop computer in the early days? It used to fail spectacularly on unclean shutdowns. IIRC linux used to delay/buffer writes up to a minute or so. (Maybe it still does?)
I would never SD card boot a Pi in a production environment unless your software can handle a read only file system, the card corruption issues are so widely documented at this point. Thankfully USB boot volumes are supported now.
Except that you don't need to buy an SD card. Or a special 2.5A power supply. And you can access the it solely over USB so you don't need to hook up an external keyboard, mouse, and HDMI to get it running headless. And you can actually get the chips and their datasheets for the BBB. etc.
These are great specs indeed. I just wish it wasn't so expensive, since it does take it from "something I can use" to "something I'll put in a gilded cage and only use when that very demanding problem arrives", which is never.
Folks have associated corrupt SD cards to overclocking, all the way to stating outright that overclocking will corrupt your SD card 100% of the time, if used long enough.
So, if you're overclocking, don't do that if you're using SD cards.
With Pi firmware newer than late 2016 (if I recall) you can write a file to an SD card that sets a bit in NVRAM somewhere telling it to boot to USB from that point onwards, and then you can operate without that SD card or any other going forward. Thumb drives are usually faster and more durable than SD cards.
May not be related to your particular issue, but many instances I have seen where people report SD corruption were due to running the Pi off of USB hub/port power only (essentially underpowered) instead of from a wall plug -> USB power adapter.
Been running daily for a couple of years now as a Pi-hole with no SD corruption (3B+ model). Still using the same card as I had in the beginning as well (Samsung Evo)
This is indeed an issue, many usb 2 style chargers only provide 500ma per port, the Pi 3 is recommended for use with 2.5A power supplies. The official FAQ calls this out as well.
Even many wall chargers don’t provide this - the standard one shipped with an iPhone that many people likely have isn’t powerful enough either.
The only time I have ever witnessed a Pi actually using 2.5A is when it had an official touch screen attached, a camera running, as well as something in each USB port.
I think continuous 2.5A is not needed, but is needed for an instant or two, here and there, if you are running headless.
All most people would need is a sizeable capacitor across the input power pins, perhaps.
Power supplies (people buying cheap ones, or being supplied with cheap ones -- looking at you, Amazon raspi kit sellers) are the number one source of failures that I have encountered with the pi.
A good power supply is a lot more expensive than a cheap one, and people are reluctant to invest in a $20 supply when a $5 one has the same rating, so I can't blame anyone for that other than the sellers.
You’re absolutely right, the power draw is hugely affected by how many USB devices you attach etc. Stick with the recommended 2.5A though and you are likely to be fine. Much of the issues low power causes are often weird as well, it’s often not obvious it’s the root cause.
I have two that run all the time, and have been for over a year. I access them strictly via SSH, and they're always plugged into the wall. So, you may be on to something.
That said, I do agree with OP's dislike of SD cards. I've had more than my share go bad in other devices.
True, I would much prefer eMMC at a minimum (or a SATA connector and/or USB3 port that could boot an SSD and take advantage of its speed). I would definitely pay extra for these types of features vs. having to use SD
Where I work we have many PI 1 and PI 3 in our facility. They have been running for almost 3 years, 24/7, 365 days a year. We got a few instances of corrupted cards so, about 6 months ago, in order to reduce writes on the cards, we decided to reduce logging done by our software running on them, and they have been working perfectly since then.
Urgh we have a fleet of Pi units and this is a common issue for us, particularly in buildings with dodgy power supplies. I've got a Beaglebone Black to test out as a gradual replacement, as that has enough built-in storage for us to use.
I had many problems with my RPi2 not booting after reboot. I had to unplug it, get SD card out, fsck and clean dirty bit and hope that it would boot. Got to making backup image every week.
I had some unstable power (not affecting any other home electronics) and was looking in some UPS hat but opted to go security DVR way. Bought 7Ah battery and 70W buffer PSU[1] and DC-DC 12V to 5V supply[2].
Could not be more happy. Random problems with SD cards are gone. Only thing to add is some battery voltage sensing to gracefully shutdown RPi in case of longer power outage.
Thus, I can tell that many problems with RPi may come from inadequate PSU.
If you need UPS you can put a simple USB battery between the charger and your Pi. Works like a charm. My Pi has been making hourly backups of 3 machines in my home network without a single reboot/intervention for 347 days.
You still need an SD card in there but all it needs is a bootloader and a config file that allows booting from USB. You can make the /boot partition read only so there's no chance of it being screwed up. SD cards do suck but at least they are cheap enough now that you can keep some low capacity ones with bootloaders installed on hand.
Pi 2 requires a permanent SD card as its built-in bootloader does not support network booting. It does not support USB booting.
Pi 3 B has support for both USB and network booting in its bootloader, but they are disabled by default. They are turned on by modifying some OTP configuration bits, which is a permanent change. Once set the SD card is no longer required.
Pi 3 B+ has network and USB booting enabled by default.
Presumably Pi 3 A+ will support USB booting out of the box, who knows it it'll also support USB ethernet adapters for PXE.
I believe the Alpine Linux install for the RPi runs in memory with ability to call `lbu_commit` to update the SD card. I haven't tried it yet but hopefully will have it going by tomorrow.
I built a pi into an arcade cabinet and switch it off via a power switch only bevause I felt it would be easier to just replace cards now and then than to make some soft-shutdown signal from the switch or similar. After thousands of cycles I still have no issues with it. Could it be that when only running emulators the system just doesn’t write much and without writing the there isn’t much corruption?
Somehow I've been super lucky. I've got a Pi B+ that has been running nonstop in my garage for years as a security camera. It doesn't have any kind of battery backup, though power outages here are pretty rare. I've also got a rev 1 model B set up with an RTLSDR dongle to log readings from my gas meter. Same situation.
The Raspberry Pi Compute Module 3 is just that, the SoC of the RPi3 with 1 GByte memory and 4 GByte eMMC on a SO-DIMM module. You need a baseboard though to plug it in. Either the Eval Board offered by the Foundation, or a Revolution Pi if you aim for industrial use, or some other baseboard.
Raw NAND is highly preferable to SD or USB drives. You can at least have wear leveling in the OS/FS. SD/USB are bad because most have dumb controllers and just rewrite a page when it changes. Raw NAND is also consistent and meets datasheet specs, whereas SD you never know what you are getting.
Quick glance at Microchip shows, all in quantities of 5k units, $1.02-$2.28 per unit for 1Mb ROM, $0.36 for 1Mb flash, (if aiming for $1) $0.96-$1.10 per unit for 16Mb flash, and highest is 64Mbit at $1.95-$2.18 per unit. Memory is cheap if your product is popular or can share a big order with someone(s) else.
Since not a hardware guy, I don't know if PCB design or packaging cost goes up significantly for adding a 1Mb ROM or flash. I doubt it, though, given these kind of memory chips get used in dirt-cheap boards. Albeit with lower amounts of storage usually given those board try to minimize costs.
What do you do with 8MB when the OS is 512MB+? Adding NOR Flash is normally pretty simple -- No bad blocks and a standard SPI interfaces most embedded devices have controllers for. The high end controllers can typically map NOR flash directly into the system address space.
I was thinking it might be good for RTOS alternatives, a tiny Linux, or (relevant here) something to deal with SDcard problem. Tell users about it with suggested action.
And you said 8MB. I just named off a range at different price points to help answer parent's question. I dont know embedded enough to assess what's needed here. Thanks for tip about NOR flash.
Nowadays one can buy 128GB SSDs for 20€ + 10€ external case with USB 3.0. Having 8 or 16GB of internal storage shouldn't add more than 10€ to the overall price.
This board has been extremely versatile and super affordable for a long time now. I'm really happy they made this new version. I think it's sleek nature will absolutely come in handy in some of the projects that I am going to be working on in the future. Great job!
> Plus, like its sibling, the whole board is certified as a radio module under FCC rules, which will significantly reduce the cost of conformance testing Raspberry Pi–based products.
The problem I encountered was not FCC testing of the device, but that I could not mass-manufacture my pi-based prototype because the chips required huge bulk quantity purchasing to be feasible. We had to develop a brand new device based off beaglebone that was more available for a run of 10-50k. (I'll never do that again, either..)
I occasionally have a fantasy about Apple putting their latest
A-X chip on a SBC form factor for $50 and open sourcing the drivers and letting people go nuts with it.
It's one of those things that will never ever happen because we don't live in a perfect universe.
There are SBCs with recent SoCs but when they cost 200€ you are better off by getting a x86 CPU that has sata, pcie, usb3 and is widely supported by Linux distributions.
They also aren't very attractive from a software freedom standpoint. Why give up decades of work on open source GPU drivers and then be forced to use a vendor provided Linux distribution?
Intel ME and AMD PSP are not a valid threat if you're forced to run proprietary code that may be backdoored on your SBC anyway.
Closest one I know of is the RockPro64 (https://www.pine64.org/?page_id=61454), iirc it starts at $59 (2GB RAM) but you need to add the cost for a PSU, eMMC, an eMMC flasher, a heatspreader, etc to that.
I have a Dragonboard 410c, which was based on what was a good smartphone SoC at the time. A downside was certain features like GPS and Bluetooth only worked on Android, not Linux. I realized one of the biggest advantages of the Raspberry Pi over similar and even more powerful <$100 single board computers is its huge community.
That's quad A15s + quad A7s. The A15s are way faster than the RPi3's A53's, but this is quite a few generations old at this point. They aren't 64-bit and lack all the ARMv8 instruction set changes.
Does that really matter much? Probably not. But if you're looking for the equivalent of a modern phone SoC it's also definitely not that.
i think such a thing would simply be impractical from a line of business perspective: if I'm going to spend the time/money developing a great soc I'm not going to give it away at cost (which would lead to never recovering dev costs)
Schools (at least around here in a pretty good school district) have terrible Wi-Fi, and if the school supports BYOD then the APs are commonly at capacity. It’s much easier to use Ethernet if you want to get some Pis for a classroom, since the teacher can just hook them up to a switch and not have to think about whether the Wi-Fi is good, sharing PSKs (or having every kid log in to 802.1x), making sure that the devices all get on the same subnet so that its easy to communicate with them, etc. And the Pi is aimed at schools, so that is what they will think about. Especially in lower-class areas I wouldn’t be surprised if they don’t have Wi-Fi on the entire campus (although in the US, we have eRate to help with that).
I think a "Thunderberry Pi" version with 2 thunderbolt ports instead of power, usb-a and rj45 would be really sweet for hobby purposes and provide a neat way to learn more about that tech
Pretty sure the 4 usb ports and ethernet were all being fed from one root usb controller port via a hub and usb ethernet bridge. You can easily add what they removed if you need it, or pay the $10 extra for the bigger board.
In it they say "Back in March, we explained that the 3+ platform is the final iteration of the “classic” Raspberry Pi", I've tried finding the corresponding blog post but didn't have any luck. Does anyone know where I can read more about this ? I'm interested in hearing more about their need for "new core silicon, on a new process node, with new memory technology".