Raspberry Pi 4 can finally boot directly from USB | Hacker News Reader

Raspberry Pi 4 can finally boot directly from USB

github.com

672 pointsethanpil261 comments

This sounds pretty cool! Features like this really open up exciting ways to deploy RPis, even for DIY folks like me who use them to do things like control projectors in a theatre show.

But man oh man, this page is a striking reminder that GitHub could probably use finer grained controls for commenting on issues. I sympathize with the person who wanted to close the issue originally, it looks like it just became a magnet for "Are we there yet?" seat-kicking and "I prefer commenting to thumbs-upping" spam. If there isn't already, there should be a way to toggle a single issue so that anyone can react but only org members can comment.

You can already lock conversations to collaborators. I can see how the ability to do that while still allowing reactions would be a pleasant enhancement, but it doesn't strike me as such a significant limitation.

Honest question, why couldn't you do this before, having the boot loader on an SDcard and everything else hanging off USB?

You can. See the other comments.

Best decision I ever made was setting up a Pi netboot server on my LAN. Now I have a whole bunch of Pi 3's and 4's scattered around my home with no local storage at all doing cool things, and I can make them boot into a completely different OS just by renaming a symlink on the server.

What are you using for a filesystem? NFS?

My worry would be saturating the older 100Mbit connections when downloading things like docker images.

That's more a problem of docker than NFS though. You probably would be better if you just use it traditionally or use something like NixOS.

There was a project that I read about a while ago: https://matthewbauer.us/blog/nixiosk.html

The Pi4 can do 300-350mbps, which is faster than most people's internet connection.

Netbooting and mounting NFS root would be done over local lan, the speed of internet connection has no relevance there.

Right, I was referring to my parent comment that talked about pulling Docker images which come from the internet unless you set up a proxy.

Ok, that depends on the docker images; things like pihole are relatively small (300 MB, including all layers); I would be more afraid of running containers over NFS slowed down by rpi ethernet, than downloading the images themselves.

Agreed. I'd have it set up so that there is some local storage via a USB3 thumb drive to hold the container images, which anecdotally pretty easily hits 80MB/s for reads, often hovering in the 100-110MB/s range.

True, but if you're netbooting you're probably not going to the internet.

Actually, just tested on my local network, got ~940 Mbps sending and receiving. Pi4 has real Gbit now, not limited by the USB bandwidth any more.

I can download large files from my pi at 900mb/s and upload around 800mb/s. The hard drives attached to the pie are formatted ext3. If you use an NTFS drive though, you will get speeds around what you are describing.

Yes, TFTP for the boot rom, and then NFS for the root fs.

I don't use docker or any other kind of container system because it's so easy to just reboot a Pi into a new OS on demand. Everything runs natively.

That's what we did when developing our original Embedded Linux stuff. Once you get it working it's really nice. You have your standard tools, version control, etc running locally on your system.

100mbit is similar to a slow sd card or usb stick anyway?

> My worry would be saturating the older 100Mbit connections when downloading things like docker images.

Is that too slow? I feel like 30 seconds to fill up half the ram is a perfectly acceptable boot time.

> Now I have a whole bunch of Pi 3's and 4's scattered around my home with no local storage at all doing cool things

Elaborate? I have a single pi3 as a Plex server, looking for more ideas.

https://github.com/badaix/snapcast this seems really cool, although I haven't got around to doing it myself.

Snapcast is really cool, Johannes did an awesome job! I used it for a long time at home on multiple RaspberryPis. I've been working for some time on a more user-friendly and cross-OS alternative. It's available here: https://github.com/geekuillaume/soundsync

I think I'm going to try to integrate net-boot in Soundsync this weekend. It would be awesome to be able to install Soundsync on any computer on the network, turn on an option and then just start the rPi to get it to play music.

Two play music, one into my hifi, one into my home audio distribution system.

One is setup for RetroPie. One has LibreELEC installed, showing TV from my HDHomeRun. One has a GPS hat and is a local NTP server.

And one boots into an Amiga emulator because I'm very old and nostalgic.

(If you’re able to play to both simultaneously) Do the music playback devices stay in sync?

No they're independent. But if I want multiroom audio I just use my very low-tech home audio system. Most rooms have ceiling speakers that are all wired back to the garage where one of the Pi's lives.

I actually tried this and it turned out to be quite a bit more complicated than predicted, due to clocks on the pis being slightly different

"I'll just sling udp multicast of the PCM samples around the network, can't be that hard right?"

ended up using MPD with pulseaudio over TCP, and they get out of sync after a few minutes, but good enough

The different clocks is a real hurdle.

I have to give credit to Apple on this one, as they had the genius idea to make the buffer >1s, and send control messages independent of the audio stream.

There’s gotta be a way to do it with PTP and the same ideas but clearly it’s either an extremely difficult problem, too niche, or both.

What is the requirement for synched audio? milliseconds, microseconds, nanoseconds,...

I'm currently working on devices that synchronises themselves wirelessly indoor over a large area and I'm now wondering if music could be an application I haven't though about...

10 ms is fine. 100ms works but you get odd echoes like a speaker system in a big building.

You need some way to compensate for clock drift between different playback devices. Even good clocks will drift 10ms in a few hours.

1ms is barely "ok". with 1ms you'll still hear ugly comb filter effects. (see my other comments)

At most 10ms. Sub 1ms would be awesome.

And yes, definitely. If you can build in a “chromecast receiver” so that a user could cast to multiple synced speakers (at full quality), you’d definitely have my attention

It's worth noting that for two speakers playing the same audio, a 5ms offset will move the point of perfect sync by less than a meter. Going below a millisecond is definitely overkill territory.

In 1ms sound travels just over 30cms - so just moving around a reasonable room affects the offsets between two well spaced speakers by 5-10ms. I use my own multi room audio system at home - http://strobe.audio - and although the sync isn’t perfect by any means the effect of moving around your house usually the problem. Eg if you have the volume in another room loud enough that it’s louder than the music from the room you’re in you get the weird echo effect. Otherwise nothing.

Turns out our brains are really good at compensating for relatively large offsets

I beg to differ: a good rule of thumb is that an (audio) sample takes about 8mm (44.1k). By the time you're a full 1ms late, that's a 44 sample difference between the two (or that's as though the speakers were about a third a meter apart.

And that distance, you're gonna hear some uncomfortable comb filtering. A third of a meter corresponds to a frequency of about 1khz, which is right smack dab in the middle of a critical band, so you WILL hear the constructive and destructive interference around ~1khz.

(and _5ms_? That means the speakers are now ~220 samples out of sync, so I'd expect any lows around 200hz to have some destructive interference, making the music sound hollow.)

1ms of sync is FAR less than adequate. It took effort, but I was able to get a distributed set of raspis to within about 5 samples at 44.1k, and I think I can do better.

Why do I know this or care? :) I've done (and still do) a lot of research (and inventions) in the field of microphone array processing and audio source localization -- tracking objects purely by their sound. With cheap commodity equipment I can generally get a resolution of 5cm, and with lots of fine tuning I was able to do sub-cm tracking.

All those problems happen even if your speakers are perfectly in sync. These aren't headphones. If you have a couch for listening, the difference between sitting on the left and sitting on the right is just as big or bigger. You get the same interference, yet it isn't a problem.

I think his thinking is still valid.

If you sit on the left or right the sound should still come from "center stage" or (x,y,z)=(0,0,0) without being shifted or drift.

Depends on whether you have a stage. If you're playing audio to go with a TV you don't want it drifting much. But when the scenario is playing music over an area you end up with a bunch of mutually-contradictory centers and it doesn't matter if they shift over a little. And music over an area is what sparked this talk.

Correct. You use PTP+NTP, the RT_PREEMPT patches, and then you have to deal with a constantly varying resampling ratio (!!) And not only that, but if you don't want nasty artifacts, the a LOT of thought also has to go into your filter design. It's hazy, but I remember using a pair of orthonormal time-varying allpass IIR QMF filters, with extra black magic I'm blanking on that allowed me to reduce the complexity of finding the coefficients for, and computing the filters by at least a factor of 4. Fun stuff. I think half the coefficients in the EQMF were zero, and of the other half, half were the reciprocal of another, which led to a fast implementation.

But yeah! I've done that. Kept audio streams to within a few samples of alignment for more than 24 hours. It was fun, and yes, somewhat hard. "will more than happily do it again for money". :)

Why would you send samples? If you do any kind of compression you’re going to convert to frequencies anyway and it isn’t that much of a hassle to expand that.

That sounds like a better solution - I'd guess most a/v systems are used for pre-recorded video that could deal with more delay during stop/start/pause but giving you more synchronization.

To really do it right though I think it would be cool to tune everything somehow. So have a microphone + photodiode sensor you put in your chair, then run a test and have it synchronize all audio and video sources together. (maybe it could even be pointed to your bluetooth headset and do that delay too)

I think with that setup, you could not only get good synchronization, you could probably tune the delay to the minimal value (maybe you could still do stuff like something live)

Take a look at snapcast if you want to fix your out-of-syncness

https://github.com/badaix/snapcast

"Typically the deviation is below 0.2ms." Impressive!

I successfully used shareport-sync and forked-daapd back a while ago with PogoPlugs and USB audio interfaces for multiroom audio. It worked without too much effort.

https://github.com/mikebrady/shairport-sync

http://ejurgensen.github.io/forked-daapd/

do you have a blog about this, or willing to share any more info? This sounds like something I'd like to start working towards

I haven't documented it, but it's very simple.

I, too, would appreciate a brief Google Doc or Pastebin on this if you can spare the time. I've never setup netboot before, but have been interested for years... reply

Unless you are running your own router, like the op, most likely his setup won't help you. You should start by understanding all the components of the system and then figure out how to make it fit in your environment and maybe what changes you need to make. Start here [0]

0. https://en.wikipedia.org/wiki/Preboot_Execution_Environment

The Pi doesn't use PXE. It's different, but documented here:

https://www.raspberrypi.org/documentation/hardware/raspberry...

You probably should read that link, section "DHCP Request / Reply". Virtually the entire world uses PXE.

Anyway, I find it funny that we are arguing about the proper name for network boot in a thread about usb boot.

OK sure. :) I guess what I meant was, if you're setup for booting Pis, you can't also boot arbitrary PCs without extra work.

Not much extra work I’d have thought. You might need to hardcode the Pis MAC address in your preferred DCHP server but the rest of the config should be equivalent.

I’ve already got isc-dhcpd running with PXE booting for x86 / AMD64 machines so might add some rules in for the Pis too.

Thanks for the heads up by the way. I hadn’t realised you could network boot Raspberry Pis.

The issue is that the Pi does something that is almost-but-not-quite PXE. In particular, the RPI firmware does not send anything that identifies itself as an RPI so that the DHCP server can determine what packet to send in response -- the option 60 string it sends in the DISCOVER packet claims to the DHCP server that it is an X86 server running in legacy BIOS mode. The only way the RPI will boot is if you send it that extra magic option 43. For those of us that write DHCP servers that try to be intelligent about how to respond to PXE requests, the plethora of stupid not-exactly-PXE mechanisms the various ARM SBC hobbyist boards are annoying as fuck. At least the server class ARM stuff usually has a UEFI implementation that adheres to the UEFI extensions to the PXE spec and properly identifies itself with options 60, 93, and 94.

Can I ask what software you're using for music on your home audio system? I have an HTD system with speakers throughout and while Chromecast Audio was great for a while, stability has been an issue that I'm no longer interested in hassling with.

(Also looking forward to researching this netboot solution you speak of)

Do you know homeassistant?

https://github.com/home-assistant/plugin-audio

Yes. I have a lot of respect for the HA project, but I stopped using it last year. It changed far too much for me too much keep up at the time, and I ran into too many issues with the zwave support at the time.

Thanks for the link.

Not the parent but I have a similar setup. I use volumio music software on 4 raspberry pi 3b+, each with a hifiberry amp to drive speakers. If you couple these with snapcast, you have a diy whole house sonos-like setup. Works well and I control volumes through home assistant.

Not familiar with netbooting, but will be looking into it!

I had been considering a similar setup and then got a notification for a barely used htd lync12 with amps on Craigslist at an insanely good price and hopped right on it. I've spent the past year or so wiring up the house a room at a time, which has been painful and sometimes stressful. But I've become such a huge fan of the simplicity and stability of a wired setup that it's all been absolutely worth it.

Thanks for the recommendation. I'll give volumio a closer look.

I use Moode Audio. https://moodeaudio.org

This looks great. Thank you

Also not the parent. For me, I want my speaker, position 4 meters away, to play some music from my phone or laptop. First, I tried to use use youtube feature to beam the video to my android smart tv connected to the speaker. However, it is a waste of resources to do that. Later, I found some scripts on the internet for my Pi 3 to play the sound via Bluetooth. It is a better solution than my original idea, I can use any app, not just youtube. However I recently found an even better way, by buying a Bluetooth transmitter dongle that can be connected to my speaker. It only costs me less than $2. I can ask my Pi 3 to do something else more important than this task.

Surprised not to see Pi Hole on that list!

Any old SBC can run that reliably on it's own, the parent is talking about swapping out the OS with netboot on the fly.

My router runs pfSense so I don't need Pi Hole, I can use pfBlockerNG instead, which is built in.

Emby also offers the ability to control and play stuff on other Emby devices on the same network. LibreELEC/Kodi + the Emby plugin [0] on a Pi makes it appear as an Emby device on other devices. Been using that for more than a year an it works like a charm. Plus the data is fetched from the Emby server and not device to device, so you can play something from your phone to your TV, then continue to control from your tablet while your phone is off.

[0] http://kodi.emby.media/

How do you serve up images to the retropie box?

Not related to the rest of the thread, but this popped up the other week and, honestly to my shock, worked well on my Pi3.

https://news.ycombinator.com/item?id=24441112

You may or may not get some latency with video. Seemed to vary for me.

I thought this was going to be about NymphCast, an open source alternative to chromecast

http://nyanko.ws/product_nymphcast.php

https://github.com/MayaPosch/NymphCast

Oh, yes!

I should have remembered this one, since I am particularly interested in it.

But, I have not actually tried it myself. I wish I had the immediate chops to contribute to the project.

pihole works really well for me as a LAN-wide ad blocker.

Does anybody know of something that will serve up tracker and game music files (e.g. .mod, .xm, .it, and .spc, .nsf, etc.)? I'd really love to be able to use one of my Pis as a compact music server with a web interface that will on-the-fly transcode and stream these old formats. I have literally tens of thousands of these sorts of files and outside of converting them all to TBs of mp3s wouldn't mind at all to serve these up from their smaller original formats.

MOC will play mods as well as other audio, and since it can be controlled over the console, you can probably hook it up to a web page too, if you're prepared to tinker with it.

mopidy/mpd

Woah, this might be it. Thanks!

>looking for more ideas

1. MotionEye can help set your own local security camera setup.

2. PiHole with Unbound can help setup network wide ad blocking and DNS over TLS.

3. SDR (DVB-T dongle) with rtl_433 can receive 433Mhz communication from your sensors like Fire Alarm, Gas Sensor, Car key etc. and notify you.

4. MQTT server on a Pi can act as a local notification server, MQTT client on your phone can receive notifications.

Of course, the possibilities with a SBC are endless, but I included just those projects which I feel can be implemented without much effort but provides huge lifestyle/cost-benefit improvements.

On 4, what MQTT broker(s) would you recommend? I’be been reading up a bit on different alternatives[0] for something lightweight with not too many dependencies to run clustered/HA and haven’t figured out which one to try yet.

[0] https://github.com/hobbyquaker/awesome-mqtt

Mosquitto seems to be the de-facto "standard" choice for a Pi. Easy to set up and definitely lightweight.

Yes, Mosquitto from default repo works as it should without any trouble.

As for android client, I recommend this[1] but it requires Tasker Autonotification plugin to display notifications.

[1]https://play.google.com/store/apps/details?id=in.dc297.mqttc...

> just by renaming a symlink on the server.

Wow. How?

Netboot instructions are here: https://www.raspberrypi.org/documentation/hardware/raspberry...

The important bit is that it will look for its boot files in a subdirectory named the serial number of the Pi. Only if that fails will it look in the root.

So I have symlinks for the serial numbers of all my Pis that point to whatever OS I want to boot.

Very interesting it looks for the serial number and not the MAC address!

Pretty sure that's because the pi doesn't actually have a hardcoded MAC; I think I've read that it's just set in software and persisted by the OS, which is weird but workable right up until there is no local storage to persist on.

Thats awesome. I asked about people netbooting for retropie in reddit and people were really confused why I would want to do that. I think I'm going to go ahead and set it up now.

I did this, but using a more traditional server. It was... OK. The pi3b+ bootloader was flaky and I ended up needing an SD card with just the kernel on it, but I wanted it ro. This made updating kind of touchy.

I can imagine that if they've made the bootloader more robust on the pi4 that this is truly excellent now.

If you already have the SD card and USB, your probably better off using https://github.com/pftf/RPi3/releases/tag/v1.30 which is a open source UEFI implementation. Its far more capable of dealing with underlying os updates using your OS's preferred update method. You put the UEFI firmware on the SD, update the config.txt to point at it, and then pretend the rpi is a normal x86/uefi system and use apt/zypper/dnf/whatever for updates (including the kernel). Everything then boots/runs/updates off the USB disk.

The arm ecosystem seems to be slowly moving to some form of UEFI+grub boot for all the linux/etc distributions and away from all these platform specific boot methods.

what hardware does the netboot server run on?

It's a Dell Poweredge running FreeNAS, which I was already using as, well, a NAS.

The required DHCP responses come from my router running pfSense, which is some kind of cheap Supermicro thing.

Can you host the netboot server from a workstation by chance? This is something I had never considered and it would really change things up for me, how does that even work? Is it just an installed distro or just a network image on the device it's booting from? I'm somewhat familiar with netbooting an installer but I've never setup a server just used the tech to install an OS from the network to hardware.

I did bump into these docs:

https://www.raspberrypi.org/documentation/hardware/raspberry...

Are these the gist of it, or did you do a little more?

Well, that's instructions on how to setup a Pi itself to be the netboot server. That will work fine, but your DHCP server still needs to be configurable to emit the correct responses to find the TFTP server, if you don't want to use a Pi itself as your DHCP server, which I would imagine most people don't.

My DHCP server is pfSense, and I'm using a FreeNAS server as the TFTP/NFS server.

The Pi netboot procedure is documented in more general terms, here: https://www.raspberrypi.org/documentation/hardware/raspberry...

Pi notwithstanding, it feels like this process hasn’t changed in 30 years.

I know for a start Microsoft made some ‘updates to the standards’ when they found out tftp isn’t really suitable for fetching gigabyte size images.

> That will work fine, but your DHCP server still needs to be configurable to emit the correct responses to find the TFTP server, if you don't want to use a Pi itself as your DHCP server, which I would imagine most people don't.

Why wouldn'y you? That's what I do: I use the DHCP server (dnsmasq) that comes with pi-hole, with a few additional config files, and it works pretty well. It even grants leases faster than my router was (which has been an issue for radv packets & DNS).

Whaty the best way to do this without trusting the untrusted LAN?

If you just want to prevent other users from snooping you, use VLAN.

There's no protection against the network administrators though.

Pantera, é você? :-O

What happens when you get a power cut?

Or, assuming you are from a well functioning country, what would happen and how would you restart?

I'm not sure I see the problem. Most servers will come up before a netboot/PXE boot timeout. At least in my experience they do.

That server should be on a UPS. Some people like to use an old laptop as a server at home, and that's even more ideal as it has a built in battery, often allowing the machine to stay alive for an hour or so before dying.

Thanks, this answers my question. In some developing countries you could have power cuts of over 10 hours.

How do you handle persistent storage? I find it is often non-trivial to adapt an appliation-specific operating system to run via pxe boot.

No one in the thread has mentioned it yet, but NBD is also an option, either NBD root or NBD for particular filesystems. I've used it for managing Pis and a couple of SiFive boards. It has different trade-offs from NFS (not necessarily faster/slower/better/worse, depends on what you're doing).

For what I'm doing which is software builds I was able to write a specific NBD driver[1] for this task which has quite large performance gains, although there are trade-offs that only make sense for temporary build directories. I don't believe this is possible with NFS at all, or at least not without far more effort.

[1] https://rwmj.wordpress.com/2020/03/21/new-nbdkit-remote-tmpf...

Probably the most important tradeoff between nbd/nfs is that NFS by virtue of supporting shared mutation, means client-side caching is either non-existent or barely useful

With NBD you're giving a filesystem driver exclusive access to a block device, the kernel knows the underlying isn't expected to change, so for example no round-trips are required to read or revalidate some cached data, and something like "find /" while slow to run the first time around, will likely be served from cache on a subsequent pass, and thus lightning fast

This is very true, but I think NFSv4 makes things a little better?

That requires your network attached storage (NFS/iSCSI or something else) to be HA ;-)

I started booting from USB SSD a couple of months ago since I got my Pi 8GB, intended to use it as my low power consumption workstation replacing the Optiplex SFF Running Manjaro + KDE Plasma. Turn out to be, Manjaro ARM + KDE Plasma on Pi 4 runs pretty well (even all KWin eye candies work as well as the Intel HD integrated GPU on the x86_64 variant). However, USB 3.0 to SATA III SSD is clearly a bottleneck still. I am yet to check if NFS over 1Gbps ethernet can be faster (anyway, my btrfs backed consumer grade NFS may not be production grade to support 10+ devices).

This is such a misleading title. 2 and 3 have had this for a while, one can do this with 4.

I'm currently using a recent MicroSD card on my Pi 4 though, haven't had any real issues with it.

"Finally available for the RPI4 in the default bootloader" is probably more accurate.

Honest question, why did this take so long? Is this feature technically too difficult to implement?

As I understand it - the Pi4 has completely different USB hardware.

Good timing! Only today I was following these instructions to install 64 bit Fedora on a RPi 4B, booting from a USB 3 drive:

https://fwmotion.com/blog/operating-systems/2020-09-04-insta...

(Unfortunately I didn't get to the end because my ancient spinning-rust USB drives take up a bit too much power to work reliably without a powered USB hub, so now I have to wait for some SSD-based USB drives to be delivered.)

From this page [1] on Raspberry Pi's Docs it seems like it's been like that for a while. Had there been a big change with this ROM specifically?

[1]: https://www.raspberrypi.org/documentation/hardware/raspberry...

I know it was in beta. Maybe it's now the default?

"USB msd boot support is now available in the default bootloader version 2020-09-03"

(although the page you reference doesn't really reflect that - see the last paragraph)

I can confirm that it is the default now. I installed a PI4 yesterday (ordered it right after release). I installed Raspberry Pi OS on an sd card first. When I tried to update eeprom, it was already up to date. After flashing the RPI OS image on an ssd, it worked perfectly fine. I did not have to touch a command line to make it boot from ssd.

It was previously in beta (may still be). I've been using this feature for some time now (at least 2-3 months I feel?).

The bootloader with USB support was first marked "stable" on 2020-06-17. This post is about a firmware with USB boot support being released on the "critical" update channel, which Raspbian will install by default without any user intervention.

I've been doing this on a 3B for almost a year now. (At least I think it's a 3B; it's not a 4 in any case. The article title has since been updated to clarify that the change is relevant to the 4.)

IIRC, enabling usb mass storage boot involves setting some OTP bits, which permanently disables usb host boot. But AFAIK, the 3B doesn't support usb host boot anyways. Is there any feature you could lose by enabling mass storage boot in this case?

I think (but haven't checked) that you lose the ability to boot from a microSD. I just switched it to USB because I wanted higher reliability for a semi-permanent installation and never checked if it would boot from SD if I removed the USB.

It will still boot from SD. Enabling USB boot just adds USB booting at the end of the list of things checked to boot from.

Thanks. I wonder what's with the dire warning about changing the OTP bits then? https://www.raspberrypi.org/documentation/hardware/raspberry...

The dire warning is mostly for the 3A+, where enabling USB host boot mode (which allows booting from USB mass storage devices) will permanently prevent booting in USB device mode. (Maybe...see below).

Device mode is only supported on the Compute Module, CM3, Zero, Zero W, A, A+, and 3A+, so if you don't have one of those there is nothing to worry about as far as this goes.

It still deserves a warning on other models, but not a dire warning. It's still permanent, but it is much harder for that to be a problem. It will only be a problem if you are going to have situations where you will have a bootable USB drive attached at boot time, without a bootable SD card inserted, and you will want it to not boot rather than boot from the USB drive.

Although OTP changes are permanent, it looks like there is still a way to sort of work around the USB host boot mode one, albeit at a cost of losing access to 7 GPIOs or at least making them a lot harder to use. With another irreversible OTP change, you can tell your Pi to determine what devices to consider booting from by looking at 7 GPIOs [1]. Using GPIO boot mode, you could easily switch between SD card only, USB only, and SD followed by USB, and device mode, by just changing pull up resistors on the relevant GPIOs.

[1] https://www.raspberrypi.org/documentation/hardware/raspberry...

Burning the OTP will prevent you from starting the 3A or 4 in OTG mode; you can still do that in software by dynamically loading the dwc2 overlay once Linux has booted up and specifying the mode=peripheral parameter (then loading the kernel module).

I believe this applies to the RPi4 only.

The 4 is a bit different under the hood (as evidenced by the different procedures). There was support on the older models, while the 4 launched without it.

I see in the docs for "Pi 4 Bootloader Configuration", under the BOOT_ORDER setting:

- 0x4 - USB mass storage boot (since 2020-09-03)

https://www.raspberrypi.org/documentation/hardware/raspberry...

Not a fan of Raspberry Pi. It hides behind proprietary Broadcom chip, no DSI/MIPI support and you're at the mercy of Raspberry PI for any sort of commercial implementation (RPi Zero and independent module). They do guarantee upto 2026 availability for their DIMM modules which is nice. We wanted to build commercial device using RPi but its a no go due to its blackbox nature.

What they should do is to leverage their position in the market and convince Broadcom to open source the bootloader and drivers. There are a bunch of binary blobs from Broadcom that are a mystery as to what they do. No docs, no anything. HAL layer is completely at the mercy of Raspbery Pi.

Raspberry Pi is an ecosystem which is based on proprietary technologies and masquerading as an open source friendly thing.

If you want to support proper open source development (I understand, at some point things get proprietary the closer you get to the hardware, but with RPi, there isn't even a datasheet for the processor that you can get your hands on), buy Beagle board and other alternatives.

Agreed. Thoe closed-source blobs and lack of docs also made it hard for WoA folks to write proper drivers for RPi4. I remember they had this beyond 3GB PCIE memory corruption issue for quite a long which is only recently fixed. I hope they can reverse engineer the GPU tho, it is nightmarish.

> Raspberry Pi is an ecosystem which is based on proprietary technologies and masquerading as an open source friendly thing

It depends on what layer you care about. At the application layer it is completely open. Even if the chip designs and drivers were open source, you could claim that there are proprietary processes and supply chains for the hardware and material themselves. Unless amateurs could build one from scratch you will never be satisfied.

I mean, you're not wrong and it is open source at the app layer but it's not like Raspberry Pi is a purely software product. They're a hardware company, acting like a maker friendly, open source device - similar to Arduino (which btw is totally open source, even the bootloader and you can get data sheets for every single component on it), but it falls short with only the top app layer being open source. The middle layer (HAL, drivers, etc.) is all closed source. And hardware is closed source.

It's ok to be closed source IMO, but they should not be marketing themselves like Arduino folks.

Arduino is a for-profit company with open source hardware; Raspberry Pi is a charity with closed-source hardware.

Nothing wrong with either approach. But your comment makes out they're a for-profit company with closed-source hardware acting like the good guys.

Not sure it's fair to label them as just another company when they're not-for-profit and pump all their money into a) product development and b) education programmes.

To be honest, if the Pi was open source hardware, everyone would buy the clones (like they do with the Arduino ones) and the charity side would have much less funding.

> To be honest, if the Pi was open source hardware, everyone would buy the clones (like they do with the Arduino ones) and the charity side would have much less funding.

As opposed to now, when people buy such totally-not-clones as the Banana Pi and Orange Pi? For that matter, Arduino seems to somehow have stayed profitable in spite of getting murdered from every angle by the clones.

>For that matter, Arduino seems to somehow have stayed profitable in spite of getting murdered from every angle by the clones.

The clones are fine for simple stuff. But they really cut every corner possible, so even the chip is counterfeit, which means it doesn't behave like a real Arduino does. Deep sleep will use 1000x as much current on some clones compared to a real Arduino, for example.

You really can't only use clones. You have to develop/test on real Arduino hardware, then deploy to clones. Because the clones aren't reliable in their behavior.

The thing helping the Raspberry Pi fend off clones is their deal with Broadcom, not whether the board, firmware, and boot code are open or closed source. It's easy to copy the board and binary blobs either way. The closed nature of the boot code hurts tinkering without helping sales.

It's true that Broadcom is the reason why most clones are not as good as the Raspberry Pi but it is not because of the boot code. It's because Broadcom has a custom graphics chip that has nothing in common with the official ARM GPUs. Any effort into open sourcing the very popular Raspberry Pi will not help open sourcing other boards that have the way more common Mali GPUs. Raspberry Pis are their own island so to speak.

Furthermore, right now there the open alternatives for Broadcomm's chips just aren't nearly as good (at this price-performance point). They made a compromise.

> It depends on what layer you care about. At the application layer it is completely open.

I'm not down with this injection of skepticism. This is slipperly language trying to make a pretty clearly contrasted situation murky.

Sure, if you just need something to process instructions, maybe the well-defined cpu architecture is enough. But kernels need things like timers to run. They need USB hosts to attach keyboards & mice. They need GPUs to out things to screen. They need power management to not run hot. They need SD(-card) io to access storage.

Yes, you can run any code on an RPi, that is some definition of open. But it should be obvious that for this to be useful & prevalent, a lot more is required, and those layers being locked away, in proprietary systems, that we have to keep reverse-engineering usage of, is a huge detractor from civilization & it's functioning.

> you could claim that there are proprietary processes and supply chains for the hardware and material themselves

> Unless amateurs could build one from scratch you will never be satisfied.

I was not expecting slippery slope to descend quite so quickly! But perhaps you are right!

There is a lot of interest in open source chipmaking these days, and hopefully we indeed do start to see a re-opening of the foundries that lead to such growth & science in the 80's, that created so much progress. Companies like Oracle & IBM certainly seem to have similar desires, to insure that we can satisfy ourselves & learn & grow, first with OpenSPARC in 2005, and OpenPOWER in 2013 certainly indicate that some very big entities in the world see & understand the value of open, through and through. More recently, works like RISC-V & OpenROAD show architectures & processes are once again coming back into focus as a thing that people see the value in opening, in being able to work together in. Google is doing free chip fabrication runs to try to help re-grow this once proud & mighty but clearly ossifying sector that has undergone a massive wave of buy-outs & consolidation. Because we have to keep the knowledge & know-how alive & growing. Because people should be making chips. And too few are these days.

That all said, I think there's a pretty clear cut difference between what you are posting about "proprietary processes and supply chains" versus situations like what we have here, where Broadcom makes chips, then conceals & makes it difficult for anyone but a couple chosen embedded partners to understand or use those chips. It's a bit frustrating that Broadcom continues to use their own proprietary peripherals they've adapted over the decades versus using more off-the-shelf standard-operating peripherals. But it's not necessarily the proprietary bit that makes this so sticky: it's the overarchingly user-hostile attitude of this behemoth, the lengths they seemingly go through to keep amateurs out & away, in contrast to other companies that if not directly support at least don't obstruct upstreaming & open source driver development. I look at the wifi-router world, & Broadcom routers are basically get-what-you-buy now, no ability to customize or change OS. Broadcom used to allow alternate OSes, but since 802.11ac, they have more or less cut off access. This was always proprietary, but at least it was something we could learn about, interface with, but now, it is locked down.

I've heard some of Broadcom's stingeyness with documentation may stem from the risks created by the perverse environment created by IP laws. With a patent troll only one manual away, I can somewhat understand to a degree holding things close to your chest if you want to continue to exist.

I mean it sucks massively, but I can at least understand it. It's part of why I strongly disagree with the "IP" side of semiconductor products, and believe that we really need to treat everything about computing as if it were straight up math. Doing anything else simply ensures that the knowledge will only very slowly percolate outward in the process of becoming a naturally endemic proficiency of the average modern human.

IANAL, but it would seem that the more documentation you release on your patented product the MORE you are protected, since it becomes less likely that they independently discovered your solution.

I think the issue is more one less of Broadcom wanting protection as much as having a chip foundry and selling chips, but not wishing to risk a legion of Non-Practicing Entities combing through their implementations with a fine tooth comb and a portfolio of held semiconductor IP.

As a long-time rPi user and embedded developer, it’s really not about ideological purity (or at least not entirely). There are real ramifications for the lack of open documentation for the GPU interfaces on the Raspberry Pi that make it really hard to use (as in utilize) if not running a mainstream Linux w/ binary blobs and device overlays. The GPU even does the system startup and initial boot loading; it’s not just closed source, it’s also entirely opaque and undocumented (documentation only available for bulk purchasers from Broadcom and under NDA, purchasing Raspberry Pi in bulk doesn’t get you the SoC documentation).

(Unlike typical devices, the CPU doesn’t do system startup and initialize the GPU as an add-on or co-processor, on the Raspberry Pi the situation is more or less reversed.)

The first binary blob you boot on a Pi is based on ThreadX, a proprietary OS now bought by Microsoft.

And this binary blob fucks up the thermal control as well.

Largely agreed. There's been some very dedicated people open sourcing support for RPi pieces, which is amazing to see, but it's been herculean efforts over many years with seemingly no support.

This is unfortunate & sad, but at least things have been moving forward. The much sadder story is wifi routers. OpenWRT used to have pretty broad support for a wide range of routers, but there have been less & less people making chipsets, and now you're probably getting either Broadcom or Qualcomm/Atheros. Broadcom has never been a "good" player in this space, but since 802.11ac routers started showing up over half a decade ago, the community has been unable to get a foothold in on Broadcom routers (I'm not sure if we have access to the bootloaders that we need, and I'm rather confident that we don't have access to open or closed drivers that we can use to run these Broadcom wifi routers).

It's frankly scary how controlled & inflexible the wifi router world is. This is further compounded by a general un-availability of add-on wifi cards: even though these chips are just PCIe devices, there's incredibly poor availability of things like PCIe cards & m.2 and mpcie cards one might add to a regular PC to make one's own wifi-router.

This is all to say, watching Broadcom has been really a scary, horrifying company to watch. The consumerization- the exclusion of the enthusiast & maker- has been very clear with Broadcom in specific, amid a market that's already shaky & at risk. The rich geeks keep fleeing to enterprise gear, the consumer keeps getting more and more stratified tiers of expensive consumer devices, and the ability to run our own networks keeps seemingly vanishing. And Broadcom is a colossus of a company that has obstructed & prevented the kind of healthy, resilient, community-powered growth that has lead to so much progress in every other sector of computing.

Leaving wifi-router discussion, I'm really hoping we start seeing more Broadcom SoC competitors show up with good offering, more single-board-computer offerings. Amlogic is doing very well with keeping upstream support, their S905X3 is a very nice chip. But the Cortex A55 core is not as powerful as the Broadcom's A73's, & there's not the dual-video out. Folks like MediaTek and Qualcomm have lots of good offerings, but no presence in the maker world. NXP does a pretty good job supporting makers, but usually at a high price point for somewhat aged cores. If you do want to investigate alternatives to RPi, this comparison of the Broadcom-based RPi4 vs an Amlogic S905X3 Odroid-C4 is a decent starting point:

https://www.cnx-software.com/2020/04/24/raspberry-pi-4-vs-od...

You're not wrong. 10 years ago I had openwrt everywhere. Now I run unifi. Very happy with it (though I wish they'd release that WiFi 6 ap they have in beta) but yeah I don't have control at that level anymore.

> Raspberry Pi is an ecosystem which is based on proprietary technologies and masquerading as an open source friendly thing.

In a world increasingly more virtualized, multilayered, and interconnected, how would you ensure "purity" in that regard? And can you?

I think if they had the following done right, it would be pretty much on par with open source hardware/software expectations:

1. Hardware datasheets for all components

2. Bootloader available to view the source for, if not completely open source. I understand bootloader can be proprietary tech and they can use non-commercial compete license but allow people to hack them and at the very least view it.

3. All PCB and gerber files available. Clean schematic documentation.

4. HAL/Middleware - this is by far the most crucial portion. The user should be able to write drivers for anything. Right now, if I want to connect a VR 2048x2048 LCD (3.5" square) with a DSI/MIPI interface, I cannot write a driver for this with RPi. It's not entirely their problem either - the DSI org gatekeeps the datasheet and development for it unless you fork out a generate multi thousand dollar membership.

That's all. Obviously they cannot compel each component manufacturer to open source their silicon... at some point the expectation fades.

> 2. Bootloader available to view the source for, if not completely open source. I understand bootloader can be proprietary tech and they can use non-commercial compete license but allow people to hack them and at the very least view it.

This is a bit of a nitpick, but assuming point one of your post, tbh as an embedded developer there’s nothing magical or worth protecting in a bootloader. It’s such boring and, in the case of embedded systems on a chip, specialized code that really has no commercial value if the hardware documentation is available except in letting you gatekeep what runs on your chip. As in, anyone with the datasheets can write a bootloader and the bootloader provides no value to someone that has their own (proprietary or knockoff) SoC.

All that is to say, the Broadcom bootloader is closed for the same reason the datasheets and documentation are: it’s to prevent revealing the internals of the chip for fear of making it easier to reverse engineer or clone.

There is an open bootloader, sadly it needs a non-upstream toolchain:

https://github.com/librerpi/rpi-open-firmware https://github.com/itszor/vc4-toolchain/issues/7

Bootloader available to view the source for, if not completely open source.

...also known as the original IBM PC/XT/AT, which had the BIOS source code available, although still copyrighted to IBM. However, documentation for everything was in general very well done, and the IBM PC Technical Reference manuals had schematics too.

An older (preferably pre-ME, pre-EFI, pre-secure-boot) standard x86 PC, which you might be able to get for free (although "retrocomputing" enthusiasts have driven demand and cost up), I would consider more open than the RPi ecosystem. More relevantly to the article, they have also been able to boot from USB since the mid 2000s. ;-)

> If you want to support proper open source development ... buy Beagle board and other alternatives.

What more open alternatives are there with similar price and performance? The Beagleboards are ridiculously underpowered compared to a Raspberry Pi 4. I like the ODROIDs but I don't think they're any more open than Raspberry Pi. They also tend to be more expensive.

YMMV on all of this stuff:

* Some folks are doing microcontroller-esque things and care about openness more than performance.

* For my applications, I need the performance. The sort of open hardware, no blob stuff you're talking about would be great on principle but I may or may not take advantage of it. I'm still able to run and develop open-source Linux userspace apps without it.

Odroid series come with a wide variety of chips. The Amlogic S905X3 has good upstream support (largely via a very active volunteer community) & is on their Odroid-C4.

If performance is your top concern, you should stick with x86. There's no ARM gear with anywhere near the bang/$ of an Odroid H2+, which is an rpi-like $120 x86 single-board system. It is fantastically well supported by the cpu vendor.

The ODROID H2+ is perfect for one of my applications, with the extra CPU power, second NIC, included real-time clock, onboard SATA and an official case option that fits 2 3.5" drives, and onboard eMMC socket. $120 [edit: plus RAM cost] rather than $35 is a whole other price category though.

at that price range why not just go all the way to mini-itx, when you hook SATA etc you will need a larger case with some cooling space inside, mini-itx seems to be a much more practical option then, a quick search found https://www.newegg.com/p/N82E16813157930 there are many to choose from actually.

or just nano-itx, both are easier to get cases and power supplies etc.

I think we're getting more and more expensive. The Raspberry Pi 4 made a lot of deliberate trade-offs to stay at $35. Going to the ODROID-H2+ means paying another $85 plus (I forgot this in the parent) RAM cost. Then going to a "real mini-itx" board probably means paying for a "real" mini-ITX case and power supply. It'll be nicer for sure but there's significant price creep. Looks like the CPU isn't included either.

The ODROID-H2 Case Type 1 has a fan and space for two 3.5" drives for $20. The ODROID-H2 power supply costs $9.40. I'll be astonished if anything compatible with that ASRock board will match that.

Sure but the rpi's can be quite price misleading. If you go pick them up at your local retail store that carries them its frequently a $120 date by the time case, heat sink, powersupply, and disk are thrown in. The base cost for the 8G rpi is something like $70, Then you still have to figure out what to do about the missing RTC, SATA, whatever, for a lot of applications.

So, yes its obvious that the $35 model (which at a minimum is really more like $45 because its not usable without a powersupply and maybe SD card) is sufficient for a lot of things. But its also being wedged into places where its not $35 anymore and in those cases its fair to compare with more expensive boards if those boards come with features that someone is adding a hat or external device for.

That's true for the ODROID H2+ too—you need to add in the power supply, case, eMMC, battery, SATA cables, and also RAM. (I forgot to mention RAM in the parent, so the difference is more like $85 + whatever you pay for RAM.)

Orange Pi looks pretty good

And Banana Pi, better designed hardware. Lots of alternatives.

Pine64's offering is pretty good, and they are all-in into open source, although their boards might be a bit less competitive now that the RPi4 is out. the Rockpro64 for instance has a PCIe connector.

https://www.pine64.org/

https://www.pine64.org/rockpro64/ http://wiki.pine64.org/index.php?title=ROCKPro64

I think people forget what it was designed for. It was to reboot IT education which was (is) badly floundering. It's success was so good it started to be used in small commercial applications. The Foundation tried to help fill this gap in the market with the compute module. Even though there is a lot of open source features the use of the Broadcom chipset was probably driven by cost as keeping the Pi price down was a factor. If a fully open source and open document solution is required perhaps the Pi isn't the right choice but then that was never it's original goal.

No doubt, RPi has been a boon to the world and the popularity speaks for itself.

I can't imagine having to sysadmin a bunch of raspberry pis in a serious "production" setting with all the reliability problems they have, that would be godawful, you'd go through a brace of SD cards every month

Why? I supported 40 of them (rpi 3) as remote serial hosts and custom reboot/repower for a QA farm. Not a single one failed and don't think I had a single issue during that whole time. As far as I know it's still going just fine. It was a cheap and dependable solution. 99% of the SD card issues go away when you don't cheap out and don't go cheap. get a large card that is 32GB plus from a respectable vendor. That's not the rpi's fault on the failures, it's the cheap ass SD cards that people buy.

It is the fault of Pi hardware when it still refuses to provide a hardware shutdown button for proper file system unmounts, after all these years.

Dependence on SD Cards and lack of orderly shutdown was what caused my company to not go with the Raspberry Pi. Even then we have back up power to allow the system time to shutdown.

Considering it was designed for IT teaching and not for embedded use, I cannot fathom why your company and many others contemplate using it in such a capacity.

Machines no longer degrade when the power is yanked. Any corruption caused by a mid-write devoltage event is handled gracefully by whatever modern filesystem of choice you are using, is it not?

Is there some more fundamental hardware damage that occurs when USB devices are unplugged without prior warning to the device itself?

It does, when your crappy hardware doesn't lie to the kernel. Go take a look at the amount of unrecoverable FS corruption discussions at LKML. It still happens relatively frequently, and is almost always caused by shitty hardware ignoring fsync and lying to the filesystem. SD cards and cheap SSDs are especially terrible in this regard (that's why I refuse to buy anything except from the most respected vendors, and they still have their issues). Many devices don't even report checksum mismatches on read requests and simply return garbage data, and most filesystems don't notice it (because they don't implement a data integrity checking mechanism of their own)

Because of large erase blocks, it's unavoidable that a flash device needs to involve some kind of very careful bookkeeping and sector-shifting to safely handle power loss during writes. Otherwise it could lose a big chunk of sectors unrelated to what you were actually writing, and that's not something a filesystem can paper over. I barely trust a proper SSD controller to do this, let alone whatever cheap thing is in an SD card or flash drive.

1. A modern filesystem will stop the filesystem getting corrupted by power loss - but a file that was mid-write, or an install process that had copied half the files it needed to, will still leave that thing incomplete.

2. SD cards can wear out (i.e. too many write-erase cycles) regardless of the filesystem.

3. SD cards have controllers running firmware, doing things like write levelling and bad block remapping. Some cards have bugs, and if the card is lying to the OS about a write completing, or if the remapping table is less resilient than the filesystem's journaling, you get problems even if the OS and everything on it is perfect.

4. Problems like pins with poor connections and power supplies not providing enough current are exacerbated, as microsds have no space for power capacitors and few SD card holders are rated for hundreds of insertion cycles.

5. SD cards start out a lot cheaper than SSDs (easier to find a sub-$10 SD card than a sub-$50 SSD) and the market is awash in fakes

All these problems look very similar - "My RPi stopped booting, I replaced the SD card with a freshly written one and it started booting again" - making forum anecdotes and user bug reports hard to rely on.

I just spent $10k on 4 Siemens 32Gig industrial SD cards for S7-1500 PLC's, in safety service.

Gauranteed 500,000 writes, probably much more, but they have "mission life" quoted at ten years on the vendor cert, so will be ditched after ten years and replaced.

Apparently they are a whole different type of logic design, hence the cost. Even the no-name or branded equivelent I could find were close to $1k each, but given use in safety service we went legit all the way anyway.

Anything with the magic S word stamped on it seems to double in price...

Lots of points you make are true. Yes, if you yank the plug without saving you lose your work. Or Exim will have to flush the queue again. Or vim will have a dangling swapfile that it will ask you about next time. Or you’ll have to start over on your game of solitaire.

And yes, SD cards have flaws.

My question was: if I turn my computer off every day by yanking the power cord, I expect nothing to break, so what am I missing when people seem so wary of doing it?

(Recall that this was all in the context of a parent comment lamenting a lack of a dedicated shutdown button on the RPi.)

With the number of GPIO pins available - you could always wire-up one yourself if a physical button is important to you.

That said, I don't think the Pi was ever designed for "serious" industrial usage; I don't think the production runs (or the foundation) could support that, without undoing the core mission.

I can talk to managing Pis in an educational setting, and honestly, it is less bad than expected. (Disclaimer: No longer a school sysadmin. But was for a number of years.)

First some comparisons. Kids are seriously rough on technology. We had a fleet of about three hundred laptops, two hundred iPads, and two hundred Pis in the junior school.

In a year, we'd end up with about a hundred laptop screen replacements, two hundred keyboard replacements and about a hundred hard drive replacements. About ten "I accidentally dropped the laptop in the river"s. We'd cycle the laptop out for a brand new one at four years, if it survived.

In the same year, about sixty iPad screen replacements, ten or so battery replacements, and twenty or so river dunkings. Only ever had one hard drive failure, apart from water damage, but the iPads were on a short two-year upgrade cycle.

The Pis were used for the robotics clubs (optional) and programming (compulsary). Pis aren't great for kids and robotics due to lack of protection on the pins for dumb mistakes. We had about twenty fizzle the mysterious smoke every year. About twenty more than experienced SD card failure in the year, usually related to yanking a power cord, not direct write failure. We also had a couple students a year who snapped theirs in half.

All in all, the cost of maintaining the Pi fleet was negligible besides the rest.

I've snapped/bent a few microSD cards myself trying to remove them from "exotic" cases, both times in hasty situations (interactive art shows). I've learned to slowly remove them while not exerting any vertical pressure when it's still halfway inside the Pi - just keep trying to slide the card out while using fingernails to catch the bump on the end.

Ah, sorry. When I said "kids snapped theirs in half", I wasn't referring to the SD card. I was referring to the Pi itself. Kids can be monstrous when it comes to technology.

How on earth do you get a “hard-drive failure” on an iPad?!

By sitting the iPad in the mysterious gunk that lies at the bottom of a kid's backpack. After stewing for a few weeks in exotic biological material the internals can begin to break down.

The cases are sealed, but they're still permeable to stuff you wouldn't let near your computer because you have a slight respect for technology.

I found fungus growing inside more than one iPad case, usually directly in the boards.

The iPad doesn’t have a hard drive. It has flash storage. The term “hard drive” is not a synonym for on-device storage: hard drives were a prevalent form of storage, but let’s not become so lax with terminology that it no longer means anything...

Yes, the iPad has flash storage. The same specific kind of flash storage that you'll find inside an SSD. And SSDs are typically referred to as hard drives.

The semantics on this one aren't worth exploring.

If you avoid the extremely common mistake of mounting the SD card RW instead of RO then Pi problems are negligible.

Raspberry Pis are actually very reliable if you don't use the cheapest possible power supply and SD card from Amazon. I have several that have years of uptime.

That said, I agree kids are rough on any technology.

Actually the problem is with unexpected shutdowns so logically if you’re having years of uptime you wouldn’t be seeing these issues.

I’m tired of pointing this out. The reply is consistently “So what? It’s my cheap Linux SBC now and until you can find something better for $40, go away.”

I‘be been booting off of eMMC on an A7 for years now. I don’t get any of this anymore.

It has a huge support community that is very friendly, that's as valuable as anything.

I too, am tired of giving that reply - I don't know why the issue must be continually raised on every Pi article; it's a little patronizing ("Oh, those poor Pi users don't know any better"), and that grates when you have researched and ended up with the Pi as the best-fit.

Both things are true - yes the Pi is not the most robust SBC on the market, but the Pi also offers the best value for money hobbyists and tinkerers. You (generalized) and I have completely different priorities and we will accept very different trade-offs: price is important to me - reliability, not as much. I would rather drop $40 on an SBC that may or may not kill my $5-$15 SD card in the next few months than spend >$100 on a rock-solid eMMC-/CF-based one. Most of Pi users are hobbyists who are not running critical code, if it fails they will fix it next weekend. Maybe.

If the pros fail to understand that the needs of hobbyists are different, then this back-and-forth will never cease.

I don’t even address hobbyists. Let them do what they want.

I’m taking about the people I encounter that are trying to use an RPi as an off-the-shelf compute solution for a production device.

I'm always amused and simultaneously annoyed by those ads about Raspberry Pi "killers" that are X amount faster or whatever, but they never get around to pointing out the price factor. They nearly always start at double the price. I'd only expect them to outperform the Raspberry Pi if they are double the price.

The Raspberry Pi is what it is, and is in every way brilliant for it. If you want X amount faster, you pay for that. That's not a Raspberry Pi killer. It's a different category altogether. Those SBCs cost more, and therefore you get more. If you need that, Raspberry Pi isn't what you need. But if you are within the group that Raspberry Pi caters to, it's hard to find better.

It's like saying the new electric Harley Davidson motorcycle is an e-bike killer. Of course it's faster and more powerful and has more this and that more features. It costs more. It's just not the same thing.

PS: The new Rpi 4 with lots of RAM is certainly getting there. I actually use one as my desktop even though I have far more powerful equipment in my studio.

How exactly does it help IT education and what was wrong with it that it needed a "reboot"?

The original idea was giving kids a device they could just connect into a TV (no need to buy a new screen) and learn by screwing up like ~"we all did when computers were simpler."

iPads, iPhones, Windows, etc.

They're expensive and complicated. Kids can't take the family computer and screw up installing linux 3 times while Mom needs to do something for work. A $25 computer is something a family could easily afford and so could school districts.

We had computers at school, but we didn't have great teachers. Wouldn't be better if school spent money on good specialists willing to share their knowledge or at least make sure kids watch certain channels on YouTube that have wealth of knowledge? If parents won't spend $200 on a computer to help their children get better future, their certainly won't spend $25. I bet they wouldn't even treat this seriously.

Most kids only experience computers through a smart phone and a collection of social media apps.

It's the standard pattern where someone comes along and says "hey, we made this thing which does X pretty well for a good price". Then someone else comes along and say "we wanted to use it for Y, but it's not good at that, therefore the thing itself is bad, and it's creators should have focused on making it good at Y instead".

AFAIK, Raspberry Pi was, among other goals, was designed to help poor students learn software and hardware. I am not sure how one can do this with such a huge proprietary blob.

Anything capable of playing HD content is going to have a binary blob. The Pi (at least the first version of it) used the same chipset that was in the Nokia N8. Even Nokia got given those blobs.

I also thought that, but then somebody here mentioned (in another topic), that the RK3388 from Rockchip runs entirely blobless. I'm having trouble digging up that post, but i'm sure I did not dream it. I'm hoping that statement applies to other members of the Rockchip family too.

By datasheet, do you mean the equivalent of a document detailing all the innards and details of the IC's down to the Opcodes/datapath?

Because I've gotten basically down to apparently what you're to write drivers for OSes with, and I know there is the annoying "teehee, let's implement OpenGL calls in firmware so the open source software is a stupid passthrough interface to the IC" which is understandably frustrating given I'd hoped to use my Pi to finally get around to driving graphics hardware to do something useful I can grok, but it's far from documentationless unless I'm missing something fundamental.

"Position in the market"? Broadcom makes STB chips that trivially dwarf all the shipped Pis. Heck, the first Pi was based on a bunch of chips from an aborted project. The RPi folks are, unfortunately, lucky that Broadcom even gives them the time of day.

Not that I disagree with your overall statement -- certainly I've found myself explaining to folks in a commercial setting that while Raspberry Pi might be a great way to a quick prototype, you're going to need to reimplement against some other hardware. Really what you're getting with the R-Pi is the community that goes with it, who have so far been very loyal to that series of devices.

There is libre RPi boot firmware, unfortunately it relies on toolchain support that isn't upstream yet:

https://github.com/librerpi/rpi-open-firmware https://github.com/itszor/vc4-toolchain/issues/7

> We wanted to build commercial device using RPi but its a no go due to its blackbox nature.

I think you misspelled prototype.

I think there are probably plenty of commercial devices for which the raspberry pi compute module makes perfect sense. Think about things like PoS terminals, information kiosks, digital signage. Why would you bother making your own hardware for those when a raspberry pi is exactly what you want and way cheaper.

It's made for tinkering and learning. It's used for a lot more due to it being so easily replaceable.

After all, I don't care if there are binary blobs from a trusted vendor for the device playing retro video games -- the TV is bound to have more spyware anyway...

great point, especially since now they try to sell the "compute module" variants which are aimed at commercial use, having to use a blackbox bootloader is wtf and I dont think many companies will accept that

Not just all that, but also hardware DRM (!!) on the camera module interface: https://mobile.twitter.com/marcan42/status/10884725497159188...

And the rebuttal:

https://twitter.com/EbenUpton/status/1088440503622909952?s=2...

The outrage and entitlement in the original tweet is laughable. It's an education charity, they need to raise money to fund their cause and do their work. I'm glad they do stuff like this. I bought both versions of the camera.

Eben Upton was a Broadcom engineer and executive. He basically used his contacts there to setup Raspberry Pi, and the relationship has continued ever since.

Oh man I feel for the maintainers here, with the many "this isn't the place for that" and now-deleted comments.

It's on my mind, as I just set up a vpn gateway on a Pi, and while I sorta want to document the process, I don't want to support randos.

Yes, the sense of frustration in the threads is palpable. Its a no-win situation: bleed time/labour dealing with "no" answers and the consequences, and get hated, or, be harsh up front, and get hated.

I feel like the RPi reps were incredibly condescending and rude in the thread. Starting with the immediate closing as a support request they were off on the wrong foot. Once they reopened, if people are looking for one place to follow for "can I boot from USB?" then their responses were between pointless and confusing:

"We have this thing updated, but it's not ready for anyone to use" so why did they send an update?

Followed predictably by "So when can we use it?"

Then they threaten the user asking about it and lock the thread, only to unlock it the next day.

All the while none of that matters, because only this week they finally got whatever was left finished (GPU firmware?) so it can work.

I do get this, but i also get the other side. The sense of entitlement inherent in the requests, the frustration of people who can't be bothered to read before posting

(I am btw, a serial offender of this, in FreeBSD land)

I'd love to boot my por from usb as I have plenty of usb sticks/disks and not many as cards. Is there a performance benefit to this?

Jeff Geerling has some great and very detailed write ups on this.

To quote directly from his post: "The results really speak for themselves. For sequential operations, using a USB SSD is 3-4x faster than using a microSD card."[0]

[0] - https://www.jeffgeerling.com/blog/2020/im-booting-my-raspber... [1] - https://www.jeffgeerling.com/blog/2020/fastest-usb-storage-o...

Just posted more results talking about TRIM and UASP support too! https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot...

I thought you'd stop by this thread! Thanks for all your work, it's very helpful and much appreciated.

As a pi noob: does this make it more reliable/feasible to use a pi to run a home server/application/etc? I've read in the past that SD cards aren't good with repeated read/writes, which makes it somewhat unreliable in the long run. If a pi is configured to run via USB, does that make it as reliable as other consumer hardware like a pc/laptop?

Other commenters in this thread have mentioned netbooting their Pis to avoid that exact issue. A typical USB flash device won't be any more reliable than an SD card, though it might be better cooled.

> A typical USB flash device won't be any more reliable than an SD card, though it might be better cooled.

That’s not strictly true, as the USB storage controller abstracts away the NAND and can manage wear leveling and free blocks. There are also more “enterprise class” USB sticks than SD cards, and the USB3 interface to USB drives is much faster than pretty much any SD card interface.

Best SD cards and best USB drives are Sandisk Extreme Pro, built entirely differently from their other lines. While Samsung Evo SSDs are top-of-the-line in each budget class, stay far away from their Evo SD cards which shamelessly borrow off the SSD reputation then drive it to the ground. They all tend to go read-only after undergoing “extended” writes.

Suggestion: if you’re using Linux, stay away from the ext family of file systems when using SD cards. Use nilfs or f2fs, and XFS if you absolutely must use a journaled fs.

Can confirm the read only. Indeed had it with 2 cards now. It's really annoying because the OS still caches writes in RAM so you only find out when you reboot and all your changes are lost.

Still, not quite as bad as completely corrupting I suppose...

Several manufacturers offer endurance-oriented microSD cards. They're designed to store footage from security cameras and the like, so they should have the write endurance to handle most any workload you throw at them. Depending on the write endurance you desire, they range from only a few bucks more than a regular microSD card to roughly double the cost.

My router / firewall is an RPi3 booting from a USB drive. A regular SD card would wear off after a few months, but a USB drive will last a long time.

You could always use a real drive for storage on some mount point, or even as an overlay on a read-only SD card. Being able now to boot directly off a SSD is more convenient, though.

I have a Pi4 set up to do this with a cheap Walmart portable SSD, it all has been far more reliable and faster than microSD.

Been using my Pi 4 8GB with K3s and found it to already be quite enjoyable. I’ve seen some odd things being new to the Pi. I started off with the full desktop raspberry os and saw my usb storage devices weren’t mounted when I did not connect my a monitor or set a default resolution in rasp config.

Which devices now support this? Does this require updating some built-in flash/eeprom memory?

The bottom of this page has the instructions for it: https://www.raspberrypi.org/documentation/hardware/raspberry...

It doesn't seem to say which specific versions support it, so perhaps all of them?

That page is for the Pi 4; it has a somewhat different boot setup than earlier versions.

Instructions for USB boot on Pi 2 and 3 variants are here; this has been officially supported for a few years now (Pi 4 took longer because its boot process is different): https://www.raspberrypi.org/documentation/hardware/raspberry...

I just did an "apt dist-upgrade" and looks like my EEPROM got updated. These are the before and after versions.

  pi@4b:~ $ vcgencmd bootloader_version
  Apr 16 2020 18:11:26
  version a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release)
  timestamp 1587057086
   
  pi@4b:~ $ vcgencmd bootloader_version
  Sep  3 2020 13:11:43
  version c305221a6d7e532693cc7ff57fddfc8649def167 (release)
  timestamp 1599135103

Almost all of my SBCs run from USB storage, the performance improvements over SD card are obviously night and day; but I never had success with the direct boot from USB(official methods) and had to jump from SD card to USB storage after boot i.e. having only /boot on SD card. RPi 4 being newer, I assume it's designed with USB boot in mind and perhaps USB boot might work better than earlier iterations.

Can you elaborate on the performance improvements over SD card?

(I have always assumed that the SD card had a much faster, more performant bus than USB. It sounds like that’s wrong?)

Sorry, that's not the case. Also I'm on USB SSD, which I should have mentioned.

Even UHS card with over clocked card reader can reach only ~ 40 MB/s on RPi[1].

[1]https://www.jeffgeerling.com/blog/2019/raspberry-pi-microsd-...

Please add rpi4 to the title

FYI the EEPROM page in the Raspberry Pi docs still says:

> USB boot support is currently being beta-tested. See > the "USB mass storage boot" section of the Bootloader > Configuration Page for further details.

But in general, it seems like it works without having to change your 'FIRMWARE_RELEASE_STATUS' setting from 'critical' to 'stable' anymore.

Rpi4 and still no usb version of bootloader. What am I missing?

    # rpi-eeprom-update
    BCM2711 detected
    BOOTLOADER: up-to-date
    CURRENT: Tue 10 Sep 2019 10:41:50 UTC (1568112110)
     LATEST: Tue 10 Sep 2019 10:41:50 UTC (1568112110)
    VL805: up-to-date
    CURRENT: 000137ab
     LATEST: 000137ab

I wish this was better documented.

You gotta do:

  $ sudo apt update
  $ sudo apt upgrade
  $ sudo apt dist-upgrade

Then do a restart and the bootloader should be updated, if that doesn't work you also need to do a:

  $ sudo rpi-update

Now the eeprom should be updated and the default option should be to boot from SD, then USB.

That's the easy way for Debian or Raspbian users, sure.

But I am on archlinuxarm.

I have used rpi-eeprom-update in the past with no issue, but it won't see the update this story is about, for reasons unknown.

... figured it out.

rpi-eeprom is not in archlinuxarm, but rather, I did install it ages ago from the AUR, manually.

There's a new version, which does the trick.

It turns out, the updater does not look online for the latest version as I'd imagine it did, but rather, it looks at a local path, and the hope is that the distribution will take care of the latest firmware being in that path for you.

There is a section of the documentation labelled 'Updating the bootloader' at https://www.raspberrypi.org/documentation/hardware/raspberry...

I wonder if this will help improve its status on https://www.fsf.org/resources/hw/single-board-computers, moving it out of the category of SBCs which have "fatal flaws"

Boot media isn't the problem, proprietary firmware is, and that's not changing here.

So where does the firmware reside? On the sd card/usb drive? Or on a chip on-board? Or somewhere else I haven't thought of?

I believe the main blob is loaded from the SD card and boots the GPU, which then starts the CPU and loads the OS (the Pi architecture is weird), although I suppose there must be some tiny blob on a chip on the actual Pi board to load that stage from the SD card. There's an attempt to make an replacement for the part on the SD card: https://github.com/christinaa/rpi-open-firmware

Might be a silly question because I'm a noob in this area, but:

Does this work with the official Ubuntu images or only Raspbian?

From the github page (https://github.com/raspberrypi/rpi-eeprom/issues/28) you can see that this needs an updated firmware which you can install via rpi-update. Never used Ubuntu on the Pi only raspbian, but I am sure they also have those rpi tools. How does Ubuntu run on the Pi work? I never got passed installation, because after install the first boot just hangs. It seems to me it wants to install additional stuff via ethernet which in my case is not attached and I never had the option to configure wifi....

Hmm, I'll have to check it out.

I think it works great. Using the 64 bit 20.04 and now 20.04.1, I've had no problems with my 4 4Gb Pi4s (so many 4s!). You should be able to set up the wifi using netplan, although I do only run mine wired so haven't tried it.

It’s not clear what method you used but for the benefit of others: Don’t install Ubuntu, it doesn’t have the needed closed source firmware blobs and isn’t compiled with some of the kernel modules the Pi uses. Instead burn a copy of the preinstalled Ubuntu Raspberry Pi disk images to an SD card.

Downloads here: https://ubuntu.com/download/raspberry-pi

64-bit is only supported on newer 3B and 4 devices and is missing some Pi-specific features.

Now if someone could make this possible across NVidia's Jetson platform ...

It's pretty tied to the hardware. Closest obvious option might be to boot your board to uboot and then chain to the real payload?

It's nice but I'm honestly baffled that it's seen as such a big deal as it's pretty trivial to make grub boot off USB, leaving the SDcard only being used doing the initial boot. Is it just about the convenience?

Instead of downvoting me, maybe you could explain what I'm missing?

> Instead of downvoting me, maybe you could explain what I'm missing?

I didn't downvote you, just my opinion:

> it's pretty trivial to make grub boot off USB, leaving the SDcard only being used doing the initial boot

In that case you still need an SDcard, and it requires manual setup. With this you can truly boot from USB drives easily WITHOUT the SD card.

You have to update it using an SD card?

After the initial update, you can use it for something else.

There is no grub

You need two parts instead of one. I'd need a microsd just to boot. And most people would then use a usb drive because they're usually faster, especially with USB 3.0.

So, the microsd is an unnecessary hassle and additional component. That's why people are so happy

(and it used to work on rpi3 since years).

Now you don’t need an SD card at all!

Big improvement over having to use SD chip!

Is thhere any way to use OS X on a Pi?

Asking for a friend

Technically it should be possible, since Darwin at least used to run in qemu. But... it's gonna suck performance-wise, since you're emulating x86_64 on AArch64, and of course I don't need to remind you of the legal issues. And, for that matter, that we're basically talking about a hackintosh VM, so don't expect long-term stability.

Once OSX on ARM arrives, this would be a lot easier; however, I'd expect Apple's silicon would be a lot newer (and have more instructions) than the rpi's, so it might not end up being possible/feasible.

Nice one, can't wait to try it! hope hackintosh is still a thing then

I've run OS X on a very low powered Debian box before. I'd wager it could be made to run on a raspi 4 (VERY SLOWLY) with sufficient effort. (you'd have to use qemu TCG, not KVM).

It would be easier to run on a SBC that uses an x86_64 chip, like the Atomic Pi, or LattePanda.

I'm curious though, why in the world would you ever want to run OS X so slowly?

We just need to run one app (OmniPlan) which is OS X exclusive in our Windows work machines.

We would get in via RDP or such I guess?

I bet I could do that. (or otherwise solve the problem.) My email address is on my profile, send me a note if you're interested in talking more.

Can I boot on ZFS root yet?

Reply on news.ycombinator.com