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.
Elaborate? I have a single pi3 as a Plex server, looking for more ideas.
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.
(Also looking forward to researching this netboot solution you speak of)
Not familiar with netbooting, but will be looking into it!
Thanks for the recommendation. I'll give volumio a closer look.
Thanks for the link.
Anyway, I find it funny that we are arguing about the proper name for network boot in a thread about usb boot.
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.
"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
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.
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". :)
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)
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...
You need some way to compensate for clock drift between different playback devices. Even good clocks will drift 10ms in a few hours.
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
Turns out our brains are really good at compensating for relatively large offsets
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.
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.
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.
As for android client, I recommend this but it requires Tasker Autonotification plugin to display notifications.
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.
You may or may not get some latency with video. Seemed to vary for me.
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.
I did bump into these docs:
Are these the gist of it, or did you do a little more?
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...
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).
For what I'm doing which is software builds I was able to write a specific NBD driver 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.
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
My worry would be saturating the older 100Mbit connections when downloading things like docker images.
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.
There was a project that I read about a while ago: https://matthewbauer.us/blog/nixiosk.html
Is that too slow? I feel like 30 seconds to fill up half the ram is a perfectly acceptable boot time.
I can imagine that if they've made the bootloader more robust on the pi4 that this is truly excellent now.
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.
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).
Or, assuming you are from a well functioning country, what would happen and how would you restart?
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.
There's no protection against the network administrators though.
The required DHCP responses come from my router running pfSense, which is some kind of cheap Supermicro thing.
I'm currently using a recent MicroSD card on my Pi 4 though, haven't had any real issues with it.
(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.)
"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)
- 0x4 - USB mass storage boot (since 2020-09-03)
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 . 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.
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.
"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 am btw, a serial offender of this, in FreeBSD land)
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.
I‘be been booting off of eMMC on an A7 for years now. I don’t get any of this anymore.
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’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.
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.
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.
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 semantics on this one aren't worth exploring.
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.
Is there some more fundamental hardware damage that occurs when USB devices are unplugged without prior warning to the device itself?
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.
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.)
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...
That said, I agree kids are rough on any technology.
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.
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.
(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.)
It's ok to be closed source IMO, but they should not be marketing themselves like Arduino folks.
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.
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.
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.
And this binary blob fucks up the thermal control as well.
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 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.
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.
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.
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.
or just nano-itx, both are easier to get cases and power supplies etc.
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.
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...
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.
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.
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.
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:
In a world increasingly more virtualized, multilayered, and interconnected, how would you ensure "purity" in that regard? And can you?
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.
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.
...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. ;-)
I think you misspelled prototype.
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."
 - https://www.jeffgeerling.com/blog/2020/im-booting-my-raspber...
 - https://www.jeffgeerling.com/blog/2020/fastest-usb-storage-o...
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.
Still, not quite as bad as completely corrupting I suppose...
pi@4b:~ $ vcgencmd bootloader_version
Apr 16 2020 18:11:26
version a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release)
pi@4b:~ $ vcgencmd bootloader_version
Sep 3 2020 13:11:43
version c305221a6d7e532693cc7ff57fddfc8649def167 (release)
It doesn't seem to say which specific versions support it, so perhaps all of them?
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 have always assumed that the SD card had a much faster, more performant bus than USB. It sounds like that’s wrong?)
Even UHS card with over clocked card reader can reach only ~ 40 MB/s on RPi.
CURRENT: Tue 10 Sep 2019 10:41:50 UTC (1568112110)
LATEST: Tue 10 Sep 2019 10:41:50 UTC (1568112110)
$ sudo apt update
$ sudo apt upgrade
$ sudo apt dist-upgrade
$ sudo rpi-update
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.
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.
> 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.
Does this work with the official Ubuntu images or only Raspbian?
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.
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.
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).
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.