Raspberry Pi 4 usb boot?

[vintozver]

Unbelievable how people (or bots?) hate the raspberry pi 4 despite so many new things!

Nobody is talking about OTG on USB-C (it's opening new possibilities btw ...)
Nobody is thinking that 512k of EEPROM onboard may solve other things or even help customizing the boot without the SD
Or USB controller on the PCI-E

But oh yeah "I cannot boot from PXE or USB" are the true deal breakers for the 35$-55$ unit.

[Biggen]

Unbelievable how people (or bots?) hate the raspberry pi 4 despite so many new things!

Nobody is talking about OTG on USB-C (it's opening new possibilities btw ...)
Nobody is thinking that 512k of EEPROM onboard may solve other things or even help customizing the boot without the SD
Or USB controller on the PCI-E

But oh yeah "I cannot boot from PXE or USB" are the true deal breakers for the 35$-55$ unit.

I think it’s the stuff that’s “piling up” that is causing some of the disenfranchisement. Can’t use most USB-C chargers, can’t USB boot, video acceleration is broken, HDMI problems popping up, etc...

The Pi is an amazing device. Sure. But the devs should have held off and provided more testing before releasing into the Wild. How was the USB charging thing even missed? We’re they only testing with their official chargers? That’s mystifying...

[Gavinmc42]

I think it’s the stuff that’s “piling up” that is causing some of the disenfranchisement. Can’t use most USB-C chargers, can’t USB boot, video acceleration is broken, HDMI problems popping up, etc...

Perhaps expectations are higher than they used to be?
Noobies won't remember how USB boot came to be in the first place.
Or how long it took for X to get fixed or Y to now work.

I think I had Zero's for about a year before I got around to using USB OTG boot.
What would I use Pi4 USB OTG boot for yet?
Yes USBboot does compile on Pi4 so I can use Zero's at least.
More needs to be known about the 2711 to be able to do anything with it.

USB-C chargers? Have you read the spec for those?
Not going to be done with $0.50 worth of parts.

Yep, the Pi4 is broken, should never have been released.
Yet for the past week this 4B1 has worked fine for me as a desktop.

Nobody is talking about OTG on USB-C (it's opening new possibilities btw ...)
Nobody is thinking that 512k of EEPROM onboard may solve other things or even help customizing the boot without the SD
Or USB controller on the PCI-E

I keep getting warned for brain dumping, so I better not say anything except I think about it, a lot

[k-pi]

Perhaps expectations are higher than they used to be?
Noobies won't remember how USB boot came to be in the first place.

Yeah, expectations were high, we had been led to believe it would be better, no, much better than the RPi3B/3B+ - & it is - as a board, but it was the lack of software testing that was the problem, & has brought about all these gripes of things not working as expected , at release the software just wasn't up to it.

No one was expecting to have the new model until next year, so a few more weeks delay could have saved all the gripes.

I wouldn't buy my first RPi until it had at least 1GB ram as a minimum, that was the RPi3B, but I had to buy a micro SD card to set the OTP bit to get it to boot from USB, only to find it didn't like to boot HDD/SSD, not enough power, but at least it would boot from pendrives.

That was fixed in the RPi3B+........ so only needed more ram & USB3 to make it really useful as a desktop.

[thagrol]

The Pi is an amazing device. Sure. But the devs should have held off and provided more testing before releasing into the Wild. How was the USB charging thing even missed? We’re they only testing with their official chargers? That’s mystifying...

No, it's pragmatic. Have you any idea just how many different USB C charges there are in existance? it's impractical in terms of both time and expense to test anything more than a tiny subset of them.

Speaking as someone with significant experience in QA and software testing, you can never test everything prior to release. There are always things that crop up in the wild. The best you can do is mitigate those issues and add them to the test plan for the next release.

[thagrol]

Perhaps expectations are higher than they used to be?
Noobies won't remember how USB boot came to be in the first place.

Yeah, expectations were high, we had been led to believe it would be better, no, much better than the RPi3B/3B+ - & it is - as a board, but it was the lack of software testing that was the problem, & has brought about all these gripes of things not working as expected , at release the software just wasn't up to it.

No one was expecting to have the new model until next year, so a few more weeks delay could have saved all the gripes.

I wouldn't buy my first RPi until it had at least 1GB ram as a minimum, that was the RPi3B, but I had to buy a micro SD card to set the OTP bit to get it to boot from USB, only to find it didn't like to boot HDD/SSD, not enough power, but at least it would boot from pendrives.

That was fixed in the RPi3B+........ so only needed more ram & USB3 to make it really useful as a desktop.

You ever worked in software testing? Or in any sort of test/QA role?

It's not an easy or simple job. The Pi is a complex piece of hardware. Linux is a complex piece of software (well multiple peices of software that interact with each other and the hardware). It's simply impossible to test everything.

In my (over 20 years of) experience there's always something that slips through. The best that can be done is to learn from it ready for the next release.

Oh, and if a company the size of Microsoft can't produce bug free software (there'd be little need for patch tuesdays if it could) what on earth makes you think a company the size of RPT can?

Edit (subsequent to the two posts below): Hardware isn't exempt from this either. Just ask Whirlpool and most car makers.

[PeterO]

I think it’s the stuff that’s “piling up” that is causing some of the disenfranchisement. Can’t use most USB-C chargers, can’t USB boot, video acceleration is broken, HDMI problems popping up, etc...

The Pi is an amazing device. Sure. But the devs should have held off and provided more testing before releasing into the Wild. How was the USB charging thing even missed? We’re they only testing with their official chargers? That’s mystifying...

You are falling into the common trap of believing that what you see on these forums is representative of the wider user population.

Maybe when you've been here for a few more of the PI upgrade launches you will understand how this process works.

PeterO

[Gavinmc42]

I wouldn't buy my first RPi until it had at least 1GB ram as a minimum,

The thing with the smaller lower powered Pi's is it forced me to learn to be frugal.
Most of my gadgets can use Zero's or B+'s.
Gone from 1GB Raspbian to 100Mb PiCore to <10MB Ultibo, lots of learning involved.

The 3B+ got very close to desktop usable to do all this development on.
This Pi4B1 is near perfect for this now.
USB booting would have been nice but is NOT a deal breaker for me.
Will I be able to get a Pi4B4 before USB booting works?
I don't care, plenty of other stuff to learn in the meantime.
Why bother about stuff that will get fixed sooner or later?

[JumpZero]

Jamesh and RPF people I'm with you, as are most of longtime Pi users here.
I'm enthusiasmed by the Pi4. Thanks to have launched it. We can wait to have USB/PXE boot and others minor stuff. We are happy with SD cards as we have always been.
It's a shame some folks can complain and be rude when they haven't even read the docs, but well we are on the web...

[Herbaldew]

Couple questions on this subject -

1. Scenario - RP4 with updated EEPROM after the USB boot capability release - Will that update make it boot from USB forevermore (unless EEPROM is changed)? In other words, if I burn a fresh image to a USB drive will it boot right up or would there be a procedure required each time I want to start with a fresh image?

2. With said update applied - Will the RP4 *only* boot from USB or will it still boot from the SD card slot if no USB is present like my 3B+ does now?

Thanks

[jamesh]

Couple questions on this subject -

1. Scenario - RP4 with updated EEPROM after the USB boot capability release - Will that update make it boot from USB forevermore (unless EEPROM is changed)? In other words, if I burn a fresh image to a USB drive will it boot right up or would there be a procedure required each time I want to start with a fresh image?

2. With said update applied - Will the RP4 *only* boot from USB or will it still boot from the SD card slot if no USB is present like my 3B+ does now?

Thanks

Not sure we have made the decision on that yet. I suspect there will be an area of the EEPROM used for user data that will take on the role of the OTP bits, and that will be (re)settable. But don't quote me on it. I would also expect it to default to SD card if no USB device was found. We may even be able to have a hierarchy of boot options like you get with some PC bios's, but as I said, this is still being discussed internally. We certainly have more space to play around with the code, and of course, it's no longer hardwired in to the SoC which means was can actually do it!

[jcyr]

Couple questions on this subject -

1. Scenario - RP4 with updated EEPROM after the USB boot capability release - Will that update make it boot from USB forevermore (unless EEPROM is changed)? In other words, if I burn a fresh image to a USB drive will it boot right up or would there be a procedure required each time I want to start with a fresh image?

2. With said update applied - Will the RP4 *only* boot from USB or will it still boot from the SD card slot if no USB is present like my 3B+ does now?

Thanks

Not sure we have made the decision on that yet. I suspect there will be an area of the EEPROM used for user data that will take on the role of the OTP bits, and that will be (re)settable. But don't quote me on it. I would also expect it to default to SD card if no USB device was found. We may even be able to have a hierarchy of boot options like you get with some PC bios's, but as I said, this is still being discussed internally. We certainly have more space to play around with the code, and of course, it's no longer hardwired in to the SoC which means was can actually do it!

No OTP on the new SOC?

[jamesh]

Couple questions on this subject -

1. Scenario - RP4 with updated EEPROM after the USB boot capability release - Will that update make it boot from USB forevermore (unless EEPROM is changed)? In other words, if I burn a fresh image to a USB drive will it boot right up or would there be a procedure required each time I want to start with a fresh image?

2. With said update applied - Will the RP4 *only* boot from USB or will it still boot from the SD card slot if no USB is present like my 3B+ does now?

Thanks

Not sure we have made the decision on that yet. I suspect there will be an area of the EEPROM used for user data that will take on the role of the OTP bits, and that will be (re)settable. But don't quote me on it. I would also expect it to default to SD card if no USB device was found. We may even be able to have a hierarchy of boot options like you get with some PC bios's, but as I said, this is still being discussed internally. We certainly have more space to play around with the code, and of course, it's no longer hardwired in to the SoC which means was can actually do it!

No OTP on the new SOC?

Yes, there is OTP in the 2711, used for serial numbers etc. But because it's one time, it's not the best place for something like USB boot flagging, where you may want to turn it off.

[jcyr]

Not sure we have made the decision on that yet. I suspect there will be an area of the EEPROM used for user data that will take on the role of the OTP bits, and that will be (re)settable. But don't quote me on it. I would also expect it to default to SD card if no USB device was found. We may even be able to have a hierarchy of boot options like you get with some PC bios's, but as I said, this is still being discussed internally. We certainly have more space to play around with the code, and of course, it's no longer hardwired in to the SoC which means was can actually do it!

No OTP on the new SOC?

Yes, there is OTP in the 2711, used for serial numbers etc. But because it's one time, it's not the best place for something like USB boot flagging, where you may want to turn it off.

Sure, for customer provisionable things. Would it be naive on my part to hope that a few bytes of actual OTP be reserved for end-user use?

[jamesh]

No OTP on the new SOC?

Yes, there is OTP in the 2711, used for serial numbers etc. But because it's one time, it's not the best place for something like USB boot flagging, where you may want to turn it off.

Sure, for customer provisionable things. Would it be naive on my part to hope that a few bytes of actual OTP be reserved for end-user use?

Seems unlikely, might be a security risk to provide that ability. Might happy though, I'll ask around.

[W. H. Heydt]

Yes, there is OTP in the 2711, used for serial numbers etc. But because it's one time, it's not the best place for something like USB boot flagging, where you may want to turn it off.

We used to get the occasional question of "How do I reset a Pi to factory original condition?" from people who were thinking PC type BIOS. We would always tell people that you did that by simply replacing the SD card with one with a fresh install.

Now with the EEPROM, it would probably be a good idea to have a way to revert it to "default" configuration (whatever that turns out to be) and doing so would be restoring a Pi4 to "factory condition", and--indeed--the most current "factory condition" as the initial contents are bound to change over time.

In that sense, having to set or reset boot over USB would be very reasonable, especially if that (and, if possible, boot order) through a raspi-config selection would appear to be a near-ideal solution coupled with a "set to default" option.

[wildestpixel]

I’m just utterly disgusted by the poor level of trolling on our part since this and pxe boot should have been enabled before I got my 4B.

In fact I’m talking to the point that whilst Royal Mail had it in their post system on its way from the wonderful Pimoroni to me it was resizing the rootfs partition already having anticipated the total block count of my usb 3 device.

I’ve worked through a plethora of stuff on 4B, I’ve done github participation stuff on mpd_oled and hyperpixel 4 relating to pi4 and buster, was the unfortunate person to highlight to Pimoroni they needed to take note that fan shim broke i2s audio - all of it and I’ve spent countless hours working on cooling solutions, which I think I’ve finally cracked.

Day one I was bothered Retropie was a no go. Not so much now. Currently I have Retropie on a 3B+ and I’ve no desire to put it on either of my Pi4’s now I’ve so many things to work through that I’m finding the early adopter role a most brilliant ride.

Please Jamesh and crew keep upsetting me just a bit more, I’ll be so downtrodden once you’ve implemented all this sexy stuff in eeprom I’m looking at various means of self harm such as beating myself around the head with marshmallows.

[jamesh]

I’m just utterly disgusted by the poor level of trolling on our part since this and pxe boot should have been enabled before I got my 4B.

In fact I’m talking to the point that whilst Royal Mail had it in their post system on its way from the wonderful Pimoroni to me it was resizing the rootfs partition already having anticipated the total block count of my usb 3 device.

I’ve worked through a plethora of stuff on 4B, I’ve done github participation stuff on mpd_oled and hyperpixel 4 relating to pi4 and buster, was the unfortunate person to highlight to Pimoroni they needed to take note that fan shim broke i2s audio - all of it and I’ve spent countless hours working on cooling solutions, which I think I’ve finally cracked.

Day one I was bothered Retropie was a no go. Not so much now. Currently I have Retropie on a 3B+ and I’ve no desire to put it on either of my Pi4’s now I’ve so many things to work through that I’m finding the early adopter role a most brilliant ride.

Please Jamesh and crew keep upsetting me just a bit more, I’ll be so downtrodden once you’ve implemented all this sexy stuff in eeprom I’m looking at various means of self harm such as beating myself around the head with marshmallows.

A waste of marshmallows. Use Turkish Delight. No-one likes that, except the Turkish, and even they are not that keen

[jdb]

Sure, for customer provisionable things. Would it be naive on my part to hope that a few bytes of actual OTP be reserved for end-user use?

We've previously allowed for customer OTP rows to be programmed for e.g compute module customers that want to key certain software to certain installations. That functionality will be maintained on 2711 based products (or a lot of CM customers will be upset).

The key distinction is that our intent is to have no user modifiable OTP bits outside of the user-defined OTP rows - this means that the unresettable ROM options for USB/Ethernet booting and the additional delay counters for slow USB mass storage devices are going away. These ROM options will be in EEPROM on Pi 4.

[jdb]

I think it’s the stuff that’s “piling up” that is causing some of the disenfranchisement. Can’t use most USB-C chargers, can’t USB boot, video acceleration is broken, HDMI problems popping up, etc..

The Pi is an amazing device. Sure. But the devs should have held off and provided more testing before releasing into the Wild. How was the USB charging thing even missed? We’re they only testing with their official chargers? That’s mystifying...

Your insightful commentary will most certainly be fed back into our next multi-million GBP investment decisions and will definitely steer the direction for our future products. Thanks for taking the time to make 3 posts on our forums.

[derekp]

If you don't mind using the SD card for an initial boot loader, you can run the OS off a USB drive. Just edit the cmdline.txt in /boot, and add "init=/sbin/usbroot.sh", rsync the OS from the SD card to the usb drive, then create a script "/sbin/usbroot.sh" that mounts the usb, runs pivot_root, and then exec /sbin/init. Now you have the OS running of the usb drive, and the SD card is only in use while the system is initially booting.

If you want, I can put together details and write up a procedure in a separate post.

[Gavinmc42]

Now with the EEPROM, it would probably be a good idea to have a way to revert it to "default" configuration

I spotted this Pi4 recovery process, in case you brick the EEPROM?
https://www.raspberrypi.org/downloads/

I like Turkish delight, but then I'm not normal

Re USB booting perhaps release that EEPROM version first, worry about netbooting etc later.
RPT don't have to make an all in one EEPROM that does everything.
Could have different versions for different purposes.
Test different options in the wild before combining.

Does not matter what version is released someone will complain

[HawaiianPi]

I wouldn't buy my first RPi until it had at least 1GB ram as a minimum, that was the RPi3B, but I had to buy a micro SD card to set the OTP bit to get it to boot from USB, only to find it didn't like to boot HDD/SSD, not enough power, but at least it would boot from pendrives.

Nonsense. I've been booting a Pi 3B from SSD for years, and I've booted them from HDD as well. I know you had trouble, but don't generalize and try to make it seem like everyone had your problem. Lots of people boot the 3B from SSD or HDD.

Edit (subsequent to the two posts below): Hardware isn't exempt from this either. Just ask Whirlpool and most car makers.

Let's not forget Samsung (Note 7 and Galaxy Fold were epic disasters).

[Gavinmc42]

Pi's we have the fun of fixing ourselves.
So much fun for $35

[incognitum]

Sure, for customer provisionable things. Would it be naive on my part to hope that a few bytes of actual OTP be reserved for end-user use?

https://www.raspberrypi.org/documentati ... /README.md


Would rather have a bigger part of EEPROM space reserved instead though.
(For things like storing private keys/iSCSI passwords to authenticate a Pi to a server, when network booting).