I've now played with a Raspberry Pi 400 for a week and here are my conclusions
If you give it fast enough "disk" storage it really moves. I plugged in a Kingston brand 120GB SSD on a USB3 adapter. hdparm -t gave 292MB/s read speed and the default LXDE environment was really crisply responsive, with even a first launch of Chromium taking less than two seconds. With such good storage, the only real limitation is that heavy Javascript stuff is too slow - 5+ seconds to switch between folders in Chrome, or for the thumbnail gallery to appear in Youtube. Also, video calling is marginal. Aside from that the CPU is fast enough.
Then I accidentally yanked a cable. And the SSD was bricked. I was able to unbrick it again with the long-powerup-without-data-cable trick, but plainly this setup is too fragile.
USB boot is a game changer. A junk drawer 8GB USB stick works just fine, aside from the fact that it takes many minutes to copy the OS image onto it in the first place.
An old 60GB SATA laptop hard disk in the same USB3 case that I tried the SSD in is pretty good. About like a decent SD card, but without the scary wear/corruption issues. I can post the brand (Can$14 on Amazon) and the workaround needed for its broken (or at least Linux incompatible) UAS.
Bluetooth Audio actually works. In the typical use case, with this thing plugged via HDMI/DVI adapter into an old junk monitor, you can use additional clutter, like a $3 USB headset adapter and computer speakers to get sound or at least plug in a headphone. But if you have a bluetooth headphone or speaker, you don't need cables at all. I can post the recipe that worked for me for this.
222 comments
[ 3.6 ms ] story [ 204 ms ] threadA modern computer should have suspend/resume. This doesn't, but all kitted out with accessories - 7 port USB hub, USB headset, spinning laptop hard disk - it idles at 6-7 watts, plus it boots fast and shuts down almost instantly, so that's not a big issue.
Now for a list of things that I think this is good for:
1. As an accessory to the family TV - for online video that the "smart TV" is too dumb for, for games and such.
2. As a classroom computer, with a few sample setups.
2a. Overlay mode (i.e. immutable SD card image and no wear) and everyone uses the same generic userID but then logs into their own google account.
2b. Overlay mode, immutable SD card image and everyone brings a USB stick to store their data on.
2c. Completely diskless mode, everyone has a USB stick they boot from (this works very well even with a typical slow USB stick).
2d. Completely diskless mode, PXE boot from a server (needs gigabit wired ethernet for adequate performance)
2e. Like 2c but with NFS home directories. This needs some sort of centralized account management.
Practical as that is, probably Chromebooks are too well established for this to get any traction.
3. As the standard experimenter's Raspi. Costs about the same as a Raspi4 with a good aluminum fanless case, so you get the keyboard for free.
4. As a small NAS/DVR/whatever server node. Same as 3. You get Raspi4 performance and passive cooling for about the same price but a free keyboard.
5. As an extra homework/Youtube/whatever screen in a screen-constrained budget conscious family. Get a $10 monitor from Craigslist/Kijiji, a $2 HDMI/DVI adapter for it and you're off. Except for the sound thing; suggest Bluetooth for minimum clutter for that.
Really a practical little machine, comparable to a decent 10-12 year old laptop with an SSD upgrade.
I had to set my user agent to Windows/Edge to make it work in Firefox. However, I can't remember if the audio/video worked.
> I was able to unbrick it
I know it's a nitpick, but if it can be repaired, it's not bricked.
[0] https://www.raspberrypi.org/products/raspberry-pi-400-unit/
To you and me:
Static electricity from the carpet discharging into the joystick port of a Commodore 64? Bricked.
Yanked a cable from my Raspberry Pi and had to reboot in an unconventional manner? Not bricked.
People were up arms but I call not bricked!
Does it require a soldering iron to fix it?
No. Not “bricked”
Yes. “bricked”
(But I also totally accept that technical people are going to lose the language war here, same as when I used to rant about rc quadcopters not being “drones” since they’re not autonomous.)
To others, having to do a full drive reformat may be as intimidating as using a soldering iron.
Contrast to the second point, where non-autonomous quadrocopters are emphatically not "drones". Unless you consider the IMU and feedback loops that keep it level "autonomous", since it is technically some degree of autonomy...
Anyway, I'd be a little more specific and say something is "bricked" when it cannot be repaired with the speaker's skill level or equipment.
Ultimate bricking would be frying an IC with e.g. heat or ESD. Good luck removing those few hundred atoms shorting something inside.
Edit: To be more constructive, how about a definition for “bricked” as “unable to be recovered by the intended users of the device through reasonably expected efforts.”
The term arose because a brick cannot be transformed into functioning electronic equipment. A device is said to be bricked when it is no more useful than a brick. If you drop your smartphone into water, and it shows no signs of life even after a couple of weeks of drying, you've bricked it.
The average user is not competent at repair, as that's a specialized skill. They might not know what to do with a laptop if you blanked its SSD, but we wouldn't call that laptop bricked.
This makes term "bricked" somewhat theoretical, as in practice almost any state of electronics can be turned back to functioning. In extreme cases you'll have to replace vital parts (if imagination forbids actually fixing broken microchips with a lab equipment), but in many cases it's still possible.
In common usage, we consider 'permanently broken' to be meaningful, we draw the line somewhere reasonable, and don't worry too much about giving a legalistic precise definition. I think my earlier examples stand up ok here. The phone is bricked, and the laptop is not. There may be edge cases where it might not be clear whether we can say whether a device is 'bricked' or not. That's not a problem. There might be an edge case in furniture where it's not clear if it's a chair or a table, but the categories of chair and table are still worth keeping.
...anyway it looks like a promising ARM-based computer ;-P
Dude, setting aside the argument itself, I never expected to see the Ship of Theseus busted out to win an internet debate... well done!
Surely a typical brick contains a significant amount of silicon and sufficient trace amounts of germanium/boron/phosphorus to dope it into useable semiconductors...
(That’d make for an awesome YouTube channel project. How I melted down and refined a brick into pure enough elements to make semiconductors and working electronics, in my backyard... I’d totally subscribe to that Patreon.)
I've got a dictionary full of terms for you that arose from one concept to mean something else. Literally. Also figuratively.
I fully support efforts to gently nudge deviations of the vernacular toward reason and rationality, especially before it it crystallizes into some abomination like "literally" has become. That way lies muddy thinking, and madness.
The price of language-reality congruence is eternal vigilance and kindhearted pedantry.
lol. You can be as kindhearted as humanly possible and some people will still get pissed.
E.g. It's OK for "decimated" to mean "destroyed/removed a sizable part of" and not "killed precisely 10% of".
It's also OK for us to disagree on when the exact place an object becomes no more useful than a brick and to think that this could be a gray area. To me, something is slightly/soft bricked when it requires specialized, non-garden path recovery procedures to fix (e.g. a firmware flashing tool). It is hard bricked when it requires tools and processes only usually found in depot maintenance or manufacturer facilities, even if my home workshop happens to be capable of these things.
Of course, this means some things that are hard bricked could become soft bricked or even not bricked at all, if the manufacturer releases a tool or updates the normal software to deal with a situation.
But they have tooling on one test bench somewhere that could load new firmware and bring it back to life...
Is it bricked?
Is it bricked if they release those tools, but they require specialized repair skills?
Is it bricked if they release those tools and it's easy?
To me, bricked means "requires exotic recovery procedure (or more) to repair." Existence of tooling in one manufacturer lab doesn't make something not "bricked". Releasing that stuff to the public makes it "soft bricked". Making it so that an ordinary user can do it makes it "not bricked anymore". When we say something is "bricked", the permanence is unknown.
Sitting with the drive powered for an hour without a data connection to let its firmware do internal housekeeping and maybe have the drive come (partially?) back, in an undocumented recovery procedure, is definitely somewhere murky on this spectrum.
I didn't say otherwise. Again you're attacking the idea that 'permanently broken' is meaningful.
You've shifted from attacking the term 'permanently broken' as unworkably imprecise, to attacking it as unknowable. Neither holds water. In real-word use, we just make do. It's not practical to give perfectly precise legalistic definitions.
We'd all agree that a severely water-damaged smartphone counts as permanently broken, and as bricked, regardless of whether it would be possible in principle for the device to be repaired at great expense.
> Releasing that stuff to the public makes it "soft bricked".
I agree that the availability of tooling can impact whether we consider something permanently broken. A failed hard-disk in an old games console might be enough to write off the whole machine, if the machine is hostile to replacement hard-disks and official repair services are no longer available (and their special tooling/software not made public). A failed hard-disk in a desktop computer, though, can easily be replaced.
> definitely somewhere murky on this spectrum
Again, of course there are edge cases. This is true of just about any categorisation we use, outside of mathematics. To refer back to my earlier example, it's not possible to give perfectly precise definitions of chair and table, but this doesn't much matter, the terms are still useful.
I don't really hear "bricked" in use for things damaged mechanically or by water. It's usually in conjunction with a failed upgrade, etc. Almost none of these things are really permanently broken, though some of them for practical purposes may be.
avmich already did this, and it doesn't hold water. Please see my response to avmich's comment.
How would you called a device that meets a fate like that? Stuck? Blocked? Unaccessible?
The word appears to originate from the idea that a device has been turned into a brick. This seems a new meaning to me, as ‘bricked’ isn’t a word that previously meant ‘to turn the thing into a brick’.
https://english.stackexchange.com/questions/488450/etymology...
https://en.m.wikipedia.org/wiki/Brick_(electronics)
Some devices that become "bricked" because the contents of their nonvolatile memory are incorrect can be "unbricked" using separate hardware (a debug board) that accesses this memory directly.[5] This is similar to the procedure for loading firmware into a new device when the memory is still empty. This kind of "bricking" and "unbricking" occasionally happens during firmware testing and development. In other cases software and hardware procedures, often complex, have been developed that have a good chance of unbricking the device. There is no general method; each device is different. There are also user-created modifier programs to use on bricked or partially bricked devices to make them functional. Examples include the Wiibrew program BootMii used to fix semi-bricked Nintendo Wiis, the Odin program used to flash firmware on Samsung Android devices,[6] or the fastboot Android protocol which is capable of reflashing a device with no software installed.[6]
With enough resources, one could fix almost anything. So what's enough to be bricked?
* Configured badly in a way that could be fixed in just software, but in a very unintuitive and undocumented way?
* Firmware overwritten with broken firmware, requiring special software and images to fix/update?
* Firmware overwritten with broken firmware, requiring you to open the case and attach a serial cable to a hidden connector fix it?
* Firmware overwritten with broken firmware, requiring you to attach thin test wires to a flash chip and bit-bang flash programming sequences?
* Firmware overwritten, requiring you to lift and replace the flash chip.
* Broken hardware components requiring extensive rework?
Whether something is irrevocably bricked or not depends upon what tooling, documentation, and skills you have. Someone releasing a new tool that makes it easier to recover/unbrick doesn't make it not have been bricked in the first place...
I know people who refer to their phone as “bricked” when the battery is flat.
As an example, if I have a network device so screwed up that I have to do a little power and connection dance to get it to reload via tftp, I'd call that a soft brick. If I have to solder in jtag pins, that's pretty firm. If the magic smoke has come out, that's definitely hard.
Adafruit and PiShop don't have it yet :/
> Then I accidentally yanked a cable. And the SSD was bricked.
People who are going to use this as as their setup ought to buy a real, fast USB SSD, instead of relying on SSD drives plugged into adapters. They're engineered to deal with stuff like this and they're fast. (the Samsung T5 and T7 both benchmark even faster than what you saw, well above 300MB/s)
Would be nice for the next Pi to have an M.2 slot tho...
The RPi400 with Pico-8 seems to tick the same boxes, so I got one for my 10yr old. He's loving it. Perfect use case.
[0] https://colorcomputerarchive.com/repo/Documents/Books/Write%...
https://news.ycombinator.com/item?id=18228740
https://web.archive.org/web/20181109020203/https://www.risco...
(IA link as it's been removed from the site, but the installer is still available via IA).
https://www.bencollier.info/projects/electronics/emulation/f...
To reiterate, the Pi can be made directly backwards-compatible with 8-bit games from 40 years ago. It's wonderful.
https://www.raspberrypi.org/documentation/usage/python/READM...
https://www.raspberrypi.org/documentation/usage/python-games...
Especially with side-by-side with a Minecraft window and the Minecraft Pi Edition python integration.
Also, there's a whole lot of little boards that support Micropython, and boot straight to it, including ESP32 etc. I use them in the classes I teach.
Appears to still be available
https://minecraft.gamepedia.com/Pi_Edition
I don't think something like this is ideal for running a full-blown Linux/Chromium/Firefox desktop environment though - it's just too slow for the bloated web sites of today. And using a mouse isn't exactly "sit-in-front-of-the-tv" friendly.
I like the idea of running something like BMC64 ("a bare metal C64 emulator for the Raspberry Pi with true 50hz/60hz smooth scrolling and low latency between input & video/audio") but unfortunately it doesn't work on the Raspberry Pi 400 yet.
USB-C is so outrageously bad in this regard. I have a smartphone on my desk, connected via USB3 for debugging. At some point it started reconnecting if I just slightly touch the phone or cable, which is extra fun if it happens mid-deployment.
I have no working usbc-usbc cables right now. It's wild how quickly mine go bad and most of the time they're just plugged into a phone once a day (driving), if that.
I just have a drawer full of dead cables with some sort of usbc end..
The Pi has more memory, more computing power, and is more reliable.
Get him a Pi, and if he needs a laptop, pick up a used Thinkpad to go with the Pi.
Source: I own both a Pi 4 & a PBP.
But, I really like the idea of having everything just built into the keyboard.
In your experience was the 4GB of RAM on the 400 reasonable?
Ever since the 400 popped up on here i've been looking into both of them. I just worry the 400 lacks more long term versatility than a straight pi 4 with a kit.
Any thoughts on this?
More info here: https://www.jeffgeerling.com/blog/2020/raspberry-pi-400-tear...
EDIT: The comment I was referring to has been restored!
https://www.seeedstudio.com/blog/2020/02/12/how-to-safely-ov...
https://hackaday.com/2020/11/11/adventures-in-overclocking-w...
But I don't have any 4 right now, so I can't try it out.
SD cards are great for keeping cost down and getting started quickly by flashing OS images from a PC. However, enthusiasts spend so much time fiddling with external storage options and cobbling together messes of powered USB hubs, cables, external enclosures, and fiddling with kernel issues (USB attached SCSI) that a Raspberry Pi with built-in eMMC would be a breath of fresh air.
They could even keep costs down by adding a connector for an eMMC submodule, similar to what ODROID has done with their boards.
[1] https://datasheets.raspberrypi.org/bcm2711/bcm2711-periphera...
IIRC the layers above SDIO are slightly different for eMMC and SD(HC), but generally SoCs that have SDIO interface support both types of memory.
Jeff Geerling benchmarked it and found it faster than his fastest SD card: https://www.jeffgeerling.com/blog/2020/raspberry-pi-compute-...
It's definitely not NVMe fast, but it's perfect for average workloads.
Maybe there is some part that eMMCs have that SD cards don't, but SD cards absolutely do have a controller that does layout (wear levelling). It doesn't do the filesystem layer, but IIRC eMMC's don't either.
AFAIK the only reason SDs are less reliable, is because they're cheap and the socket can be loose, causing corruption during a write (or wear level). It would be interesting if you know of something logically different that also makes them less reliable.
Don't find source now though, so maybe I'm completely wrong.
e.g. https://www.digikey.com/en/products/detail/swissbit/SFSD032G...
For example, the microSD slot only has 4 data lines. eMMC isn't constrained to the microSD slot, so they can have 8 data lines.
The Raspberry Pi 4 Compute Module has onboard eMMC. Jeff Geerling tests a lot of SD cards on the Raspberry Pi, but he found the CM4's eMMC is faster than any SD card he's ever tested: https://www.jeffgeerling.com/blog/2020/raspberry-pi-compute-...
Quite possibly! Flash memory is absolutely not all the same. I wish someone would do for SD cards what Backblaze does for hard drives.
Oddly enough, Samsung, SanDisk, and Sony are the three brands I've had die on me. I had a GoPro eat two Sony cards in less than a year, I switched to SanDisk Endurance and it's been plugging along for about 2 years now. I've had one Samsung and a couple SanDisk SD cards die in Raspberry Pi's. I'm currently using MicroCenter, AData and one other lower tier brand that have held up much better than the name brands.
[1]: https://www.home-assistant.io/
The Pi themselves don't die because of a SD corruption. Only the SD cards do (and they can be recovered).
I'm not against on board storage but I understand the tradeoff to allow user expandability and reduce production costs. I think they'd get heat on the eMMC size unless it was like 32gb and I don't think that cost increase would make it very far. But maybe with the push to the 400 they will start to go that route to create a self contained but expandable system that is plug and play raspbian by default.
But they walk a fine balance with PCB space, backward compatibility, performance, cost and user-friendliness.
Throw in a PCIe switch or something so you can still attach a USB 3 controller and now you've doubled the price and power consumption.
And hopefully that would ensure the new form factor to be somewhat stable for a while after that.
SD cards are not all designed or optimized around small, random reads and writes - the typical workload of a boot drive - and latencies can be staggering. Similar for USB sticks. On the other hand, these days the overwhelming majority of M.2 SSDs are at least somewhat optimized for 4K IOPS. The latest Sabrent Rocket M2 SSDs get some 650,000 4K IOPS vs eMMC at ~13000 (the Rocket is 50X faster) an SD card around ~2000 (the Rocket is 325X faster).
Frankly if you stuck a Sabrent Rocket on a PCIe 1.0 x1 connector the performance would absolute savage an SD or eMMC solution on this workload. Even if they somehow also had identical sequential I/O specs.
you have to keep in mind the original goal of the raspberry pi project.
if you want nice performance and low power consumption, you're better off considering a cheap intel nuc.
SD card: $15.20 for 128GB on Amazon
The price difference is minimal.
But the SSD is much much faster in that price range.
https://www.slrlounge.com/sd-express-memory-cards-pcle-nvme/
Even if they removed the SD slot, you would still reflash the board over USB. That's how it's done with the Raspberry Pi Compute Module. With some software development it could be even easier than fiddling with SD cards.
In education environments, microSD cards tend to disappear a lot. Having one less moving piece to lose would be a win.
To be honest the large majority of RPi users I have ever met are only adults. Are there a lot of kids who are using it out there?
Students bring their own SD card, since else they are easily misplaced (stolen). This also means boards can be used by any student.
A lot of effort and cost, so we went with the microbit. The kids can easily own them, use a tablet to program them, and for the kids that are older, they can go for the rPi to expand this setup and learn more advanced stuff. By we do not use this as an entry. Kids that do robotics have a better time with them.
So yes, maybe mostly used by adults. The idea of SD cards was a good one. But several flaws held it back; like the non-5v tolerant GPIO. Lost several boards due to misuse... And they ain't cheap if they need to be replaced often.
You dont hear about it as often because for reasons, the kids aren't exactly encouraged to reach out to adults on the internet. Dogs on the internet and all that.
/meant humorously but also seriously serious.
It's sort of like Elon Musk saying on Electric Vehicles: "We could make the car infinitely desirable, but if someone does not have the money, they won't buy it"
Just pull up https://www.raspberrypi.org and you'll immediately see "someone" is kids.
So I think the fiddling is a given, maybe part of the experience, and usually there's a payoff.
that said I'm not immune to wishful thinking. I think an expensive $150 Pi Pro that makes a profit would be cool. Think mini-itx, pcie, m.2 and memory slots PLUS gpios.
That's actually a good thing, the raspberry pi community uncovered a ton of issues over the years related to storage drives over USB, which has been or can now be patched in the kernel to make such things more reliable.
Performance is roughly on par with the core 2 duo in the mini, but the graphics is more powerful and fully supported by webgl, so in practice it struggles less with the scratch environment and online games than the mini did. I would however not consider it snappy, it is quite sluggish to use chromium on it. I got both netflix and disney plus to work with minimal effort but disney plus is very slow to load, it takes almost a minute to fully pop up. It does play fine when streaming video.
The kids so far are quite happy and have been using it a lot more than they used the mac mini. It does everything they want (online educational games, some digital homework, and scratch), and they're not bothered by the sluggish loading of some sites. I think they also like the way it looks, it is a very fun looking little computer.
But I'd hardly consider that "minimal effort" in the general case. Did you find a better way?
Edit: also, Chrome itself. How did you manage that?
What's the long-powerup-without-data-cable trick, if that's not a stupid question? Sounds like a useful thing to know!
https://dfarq.homeip.net/fix-dead-ssd/
As an aside, why isn't there a market for a say 10gig usb medium that isn't flakey AF like microsd etc that die if you squint at it a little too hard
USB enclosure and an actually SSD seems like the cheapest option. There has got to be a middle ground here...
1. Lack of 3.5mm audio jack or built-in microphone/speakers 2. Unable to run Zoom reliably
Given that schools are closed (at least in India) and classes are happening over zoom, these two drawbacks makes it a no-go for my use case.
"Getting audio out of the Pi 400 was a bit of a challenge; it defaulted to attempting to deliver audio over HDMI, and Raspberry Pi OS' audio control dialog isn't the best. Even after changing the output device to USB Audio (my gaming headset), YouTube wasn't producing audio—and there's no "test" button I could find in Pi OS, like the one in Ubuntu's audio-control dialog. Closing and reopening the browser entirely after changing the output device resolved the issue, and audio played from the headset fine afterward." https://arstechnica.com/gadgets/2020/11/raspberry-pi-400-the...
So to get the usual 3.5mm jacks, just buy a cheap USB/analog headset adapter; about $3 from Ali Express. Select as input and output, and done. Microphone is usually not an issue if you're using a webcam since most have an adequate one built in.
I was following this guide and couldn't even get these steps to work: https://www.tomshardware.com/how-to/boot-raspberry-pi-4-usb
Of course if you get an Raspberry Pi made before this became the default then you're SOL.
[1]: https://www.raspberrypi.org/documentation/hardware/raspberry...
After that (and possibly rebooting?) I could run raspi-config and enable USB boot[2] there.
[1] https://www.raspberrypi.org/documentation/hardware/raspberry...
[2] https://www.raspberrypi.org/documentation/configuration/rasp...
I also ran a bunch of servers where they booted off of a small internal disk and otherwise lived entirely off of NFS.
It all ran "just fine" on 10bt.
Get off my lawn...
One of these things seems ideal for "diskless" operation, especially if used in a lab setting.
However, switching to a read-only SD card and a RAM file system seemed to eliminate the file system corruption and SD card damage I'd been seeing in my Raspberry Pi-based design. No problem with power cycling the thing.
“Linux” doesn’t write anything to the filesystem, but various helper utilities do, and this has become more true with systemd-journald.
He's already able to type letters & numbers on the keyboard since he can read them, so it should just amplify his learning.
And yes, he gets plenty of regular playtime outside and inside. He spends hours outdoors. It's mostly going to just "be there" to use as he pleases, especially with the upcoming cold weather and lockdown.
There's also endurance microSDs made for constant writing -- and I bought one for my current Pi 4 -- but I don't have enough experience with those to say whether it solves the Pi corruption issues.
[1] https://www.samsung.com/us/computing/memory-storage/usb-flas...
Always have been a fan of your site.
What's the nature of this phenomenon? Why does it happen to Raspberry Pi but doesn't happen to classic x86 systems?