Raspberry Pi 4 usb boot?

[LTolledo]

...Lots of people boot the 3B from SSD or HDD.

count me in on this.... most of desktop RPi's boot from SSD, another one boots from HDD, and another one boots from USB thumbdrive...

ok lets take it up a notch...
booted my RPi2Bv1.2 on old samsung 2.5" 250GB HDD! (no microSD card on slot). Just set the OTP bit!
used as a desktop with attached to 7" monitor, keyboard and mouse, LAN connection
Worked fine, used it for about half a year.... coding and stuff, some chromium browsing.... mostly used for maintaining other SBCs via ssh....
its now working as a NAS though...

[LTolledo]

Nonsense.

No, absolutely true - you've just been lucky!

No... you've just been unlucky!!

[jamesh]

Nonsense.

No, absolutely true - you've just been lucky!

For goodness sake, stop this concern trolling. You are wrong. Loads of people are USB booting their Pi models using an SD card, and it works fine. They haven't been 'lucky'. If 99 people out of 100 have something that works - are they all 'lucky'? Or is the 1 unlucky?

[epoch1970]

Turkish Delights can be delicious. Please do not harm or waste Turkish Delights.

This being said, I want to add some background noise to the EEPROM discussion.
I have no idea how resilient it is, how big it is etc.
I am a devotee of the uboot/model B/SD trinity.

In a pure stock hardware config, all uboot environment is stored on the SD. The SD can move around, so the only thing uboot, or linux later on, can do is lookup the platform's serial number and see if that matches what's in the SD. If it doesn't match, there was a change of platform or SD swap between 2 nodes.
So, although not absolutely critical, I think I would love to be able to get uboot to store at least a few variables (not only bits) directly in the platform.
I am not sure I would store the full uboot redundant environment in the EEPROM, were that even possible.

HTH.

[chapas]

Hi,
i think my question can be accommodated here;
With all the changes on the RPi4, now we have faster SDCard and USB data transfer, which one is faster?
Which one has the fastest access times?

Just need to know where should i install the OS.

Thanks

I found an acceptable answer to my own question so I'm sharing it here for other board members:
Reference: https://www.youtube.com/watch?v=kbn_6ixtIpA



Will definitely use USB ASAP instead of a MicroSD card.

[timg236]

Answering a few random questions

• The next boot mode will be PXE/network boot, then probably USB mass storage mode.

• We intend to post beta-images on the forums for new features.

• There's no plan for general purpose storage in the EEPROM, maybe a small number of settings that can be read back from Linux. Maybe we'll look again after it's feature complete but that's a way off

• The existing user modifiable OTP rows are still supported on Pi4 and are independent of bootloader features. Although it might be useful to have a common settings API/gencmd

• The ability to change the EEPROM and have some modifiable state creates some opportunities to customize the boot-flow sequence e.g. timeout a network connection and failover to local store. We don't want to add too much complexity here because the boot sequence needs to be predictable for most users but there's some room for improvement.

• For baremetal firmware hacking the recommended is to create a start.elf file instead of bootcode.bin

[Daddyfix]

Your team is doing a great job.
I can't wait to try PXE Boot on RPi4, in fact I have never tried this before.

Thanks for the updates,
A Raspberry Pi Foundation Loyalist

[epoch1970]

Answering a few random questions
...

Very good. Thanks.

[W. H. Heydt]

This being said, I want to add some background noise to the EEPROM discussion.
I have no idea how resilient it is, how big it is etc.

It's been stated several times... 512KB.

[dickon]

Your team is doing a great job.
I can't wait to try PXE Boot on RPi4, in fact I have never tried this before.

Network booting >> sliced bread.

Incidentally, anyone else had trouble booting a Pi3 B (not B+) on a GbE network without a bootcode.bin on an sd card? Recently discovered mine isn't happy, which is annoying, albeit basically OK.

[epoch1970]

Incidentally, anyone else had trouble booting a Pi3 B (not B+) on a GbE network without a bootcode.bin on an sd card?

Yes. The forum certainly has posts from the time that feature was released. You will see the reasons for non-deterministic netboot behavior on 3B are more subtle than "GbE network".
3B+ added support for POE (remote power cycling) and the firmware contained modifications to improve netboot reliability.
And as we know the firmware in Pi4 is now upgradable.

[dickon]

Oh good. I'm not going entirely mad, then.

[W. H. Heydt]

Oh good. I'm not going entirely mad, then.

The quote the Cheshire Cat... "We're all mad here..." And if you aren't mad when you arrive, we can fix that.

[HawaiianPi]

No, absolutely true - you've just been lucky!

It's rather arrogant of you to assume your experience is the only one that counts, especially when myself and many others here have proven you wrong. Both my Pi 3B and 3B+ boot from SSD or HDD with no SD card using the Eluteng (black) or TNP USB3-SATA3 adapters. I have tested this with loads of different drives, and I have yet to find one that doesn't work with those adapters.

Of course, none of this has anything to do with the Pi 4B, which is the subject of this thread.

With the Pi 4B you can put /boot on SD card and run the main OS from SSD without too much trouble, and pure USB boot will be enabled in a future firmware update. Oh, and it's very fast when using the USB 3.0 port!

[Gavinmc42]

Oh good. I'm not going entirely mad, then.

I am
It has been so long I forgot how to boot from SD and run from USB.
That goes back to Pi3 days?
We have all been talking about it but in the official docs I don't see the temporary fix for it.

With the Pi 4B you can put /boot on SD card and run the main OS from SSD without too much trouble,

Er I'm old now better explain it again.

You know with the uSd and two USB 3.0, we could have a choice of which OS to run on boot.
PINN is too hard for me, or too simple, not sure which.

[dickon]

Yes, the 3B and 3B+ can network boot without an SD card, but from cursory testing here, the 3B won't send any data frames when plugged into a GbE switch, or the GbE NIC on the motherboard of my (amd64) desktop. With an SD card containing bootcode.bin in the first FAT32 partition, the 3B can boot happily. I assume the bootcode.bin network controller configuration is a bit more rigorous than the one blown in the ROM. And I really don't mind having a bootcode.bin SD card in a machine; it still allows me to keep /boot on the network, where it belongs, hosted on a snapshotted ZFS filesystem.

To boot an OS from SSD, copy the filesystem to the SSD, and edit /boot/cmdline.txt to point to it. root=/dev/sda2 or the like. It isn't rocket science.

[Andyroo]

And your point is?

Never seen version two of any other bit of equipment?

If you want a real fright just go https://www.gov.uk/check-vehicle-recall

This error has work arounds at the cost of one new cable or at worse one new power supply. Having been caught for weeks by the issue of using a poor supply with a Pi 3 (network and random errors) personally I’m happy to spend the extra on a Pi power supply and not just something I’ve got laying around.

[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.

Bullshit. They admit the issue and their fault.
They will have to release a new version of the pi4 to fix that.
https://arstechnica.com/gadgets/2019/07 ... -chargers/

Please mind you language.

Whether or not RPT/RPF have admitted the issue (they have), and whether or not there will be a future board revision to address it (it has been stated that there will be) does not make my comments invlaid (or B*sh?t)

That this was missed is an error in a complex process. Writing test plans is not straight forward and as for beta testers, most of those won't be experience test/QA engineers (I am but I wasnt' a beta tester) and will have used the equipment they were given. Without hindsight, if you were sent a 4B, associated cable and an official power supply would you have plugged in a random USB C charger that you just happened to have lying around?

It is not practical to expect RPT/RPF (or any other company) to have tested every possible combination of their device and all third party devices.

To illustrate my point about designing test cases/test plans I'm going to set you a achallenge:

Give me three test cases for the piece of software specified as follows:
Program will repeatedly prompt for a number until it receives a "*". It will then calculate and display the average of the numbers entered.

Please, can no one jump in before kyliael has responded.

Oh, and as I said in another thread, you need to grow up, gain some maturity, and calm down. And learn a little more about where yo fit in the world and how things actually work.

[LTolledo]

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.

Bullshit. They admit the issue and their fault.
They will have to release a new version of the pi4 to fix that.
https://arstechnica.com/gadgets/2019/07 ... -chargers/

hmmm... seem like you have a capacity to engage the RPF in a lengthy and costly legal battle over this?

[scaramonga]

Motherboards (PC) are the same. Revisions change, so one month it could be v1.0, the next 1.1, it is what it is, and if one wishes to get on the bandwagon early, then you will have that early revision, simple really, and lets be honest, in this case, it's peanuts for a new board regardless

[W. H. Heydt]

Motherboards (PC) are the same. Revisions change, so one month it could be v1.0, the next 1.1, it is what it is, and if one wishes to get on the bandwagon early, then you will have that early revision, simple really, and lets be honest, in this case, it's peanuts for a new board regardless

Yup. One of my 3 RPF 7" displays is so early that the backlight control really only has two values: on and off. For the other two, I needed finer control than that, as they're used as "alarm clocks" and I don't want a display that is capable of lighting up the whole room. (Put an RPF display in a reasonably dark room. You'll be amazed at how much light it puts out.)

[Gavinmc42]

it's peanuts for a new board regardless

Are you offering to pay for the PCB revision?
15K PCB's per day with a pipeline 1-2 weeks long.
Not a simple PCB,, many layers, so a few dollars each?
Peanuts must be expensive in your neighbourhood?

Do RPT wait to see if any other "defects" show up?
How many users have MacBook chargers?

What else needs fixing?
Some people might regard this as a serious, instant recall issue.
Perhaps a warning label, "Caution this SoC could get hot"?
Like those McDonald's coffee cups?
Hmm third party opportunity, stick on temp label, changes colour if above 65C?
MacBook charger adaptors with built in resistor?

Opportunities for the entrepreneur, perhaps who knows Shenzhen.
RPF swag opportunity, colour shifting Pi labels/heatsink.

Sorry, more brain dumping but problems can be opportunities too.
Milk half full or empty?

[Mastiff]

Do you guys boot from USB3? I can only manage to boot from the two left, black USB2 ports with my M.2 SSD in an USB enclosure. The USB3 ports give me an error message after the four raspberries.

Edit: And an USB 3 memory stick isn't reliable either on USB3. It's like there's an error on the USB chip in addition to the power chip!

[trejan]

it's peanuts for a new board regardless

Are you offering to pay for the PCB revision?

Read the rest of their reply as well. They mean buying a new RPi 4 board.

[HawaiianPi]

Do you guys boot from USB3? I can only manage to boot from the two left, black USB2 ports with my M.2 SSD in an USB enclosure. The USB3 ports give me an error message after the for raspberries.

The new Pi4 cannot boot from USB, yet, that feature is planned for a future firmware update (after netboot).

You can hybrid SD-USB boot by putting the boot files on SD card and the root OS file system on a USB drive. I'm doing that on my 4B with a SATA3 SSD and a USB 3.0 adapter cable. I've been meaning to do a full tutorial, but I've been busy and haven't had time (yet). See the following post for the short version.

https://www.raspberrypi.org/forums/view ... 0#p1498774