STICKY: USB boot now working on Pi3

[DMackG]

Just to be clear.....Do you still need the OTP even with Raspbian 4-10-2017?

[W. H. Heydt]

Just to be clear.....Do you still need the OTP even with Raspbian 4-10-2017?

Setting the OTP bit is--essentially--a hardware change. 4-10-2017 Raspbian is the software that will recognize that change.

When this whole thing started, there was talk of having all Pi3Bs (the Pi2B2 didn't exist at the time) having the OTP bit set at the factory. I haven't anything about that since, but now that the feature has been released, it would be nice if those in the know would let us know if that is still the plan and/or let us know when that change takes place. The RPF/RPT tend not to announce trivial board changes (and this would qualify), but it does have ramifications for those considering booting over USB on boards not yet acquired.

[linux_author]

good posts in this thread... i'm getting ready to explore USB [boot] filesystem support for the pi0 series (personally, i think this form factor is the future of the Raspberry Pi offerings - JMHO mind you)... i know others here are better versed in the effort...

willie
on the tiny-computing Gulf of Mexico

[andrum99]

Just to be clear.....Do you still need the OTP even with Raspbian 4-10-2017?

Setting the OTP bit is--essentially--a hardware change. 4-10-2017 Raspbian is the software that will recognize that change.

That's not quite correct - the OTP bit is checked by the boot ROM inside the BCM2837 SoC to see whether it should attempt booting from USB. This is an earlier stage in the boot process - before Linux has started loading.

What has changed in the 2017-04-10 release of Raspbian is that it has been made to work seamlessly when you image it onto a USB mass storage device, as it does when you image it onto an SD card.

[W. H. Heydt]

Just to be clear.....Do you still need the OTP even with Raspbian 4-10-2017?

Setting the OTP bit is--essentially--a hardware change. 4-10-2017 Raspbian is the software that will recognize that change.

That's not quite correct - the OTP bit is checked by the boot ROM inside the BCM2837 SoC to see whether it should attempt booting from USB. This is an earlier stage in the boot process - before Linux has started loading.

That's part of why I said "essentially". Yes, setting a bit (so that the boot ROM will check for a bootable USB device if there is no bootable SD card (or eMMC) is really "software", or--more likely--"firmware", but since it's (a) a one time irreversible change, and (b) entirely internal to the SoC, it functions as a hardware change. And, indeed, it *is* a change to the hardware, albeit a very minor one.

If the OTP bit were to be set as part of the masks in the chip manufacturing, no one would question that it was a hardware change. If it gets set as part of board manufacturing, most people would consider it to be a hardware change. The only time it's going to be debated is when the end user can "blow" the bit himself. So for all *practical* purposes, it's a change to the hardware. (This is not the place for the classic joke about what "for all practical purposes" means.)

All of this is, after all, where the line between software and hardware gets a little fuzzy.

[W. H. Heydt]

good posts in this thread... i'm getting ready to explore USB [boot] filesystem support for the pi0 series (personally, i think this form factor is the future of the Raspberry Pi offerings - JMHO mind you)... i know others here are better versed in the effort...

willie
on the tiny-computing Gulf of Mexico

As part of your exploration, you might take a look at the WD Labs "PiDrive Node Zero".

[fruitoftheloom]

good posts in this thread... i'm getting ready to explore USB [boot] filesystem support for the pi0 series (personally, i think this form factor is the future of the Raspberry Pi offerings - JMHO mind you)... i know others here are better versed in the effort...

willie
on the tiny-computing Gulf of Mexico

As part of your exploration, you might take a look at the WD Labs "PiDrive Node Zero".

Yes WD Labs have created some great products: https://www.wdc.com/products/wdlabs/wd- ... -zero.html

[linux_author]

good posts in this thread... i'm getting ready to explore USB [boot] filesystem support for the pi0 series (personally, i think this form factor is the future of the Raspberry Pi offerings - JMHO mind you)... i know others here are better versed in the effort...

willie
on the tiny-computing Gulf of Mexico

As part of your exploration, you might take a look at the WD Labs "PiDrive Node Zero".

Yes WD Labs have created some great products: https://www.wdc.com/products/wdlabs/wd- ... -zero.html

tks, folks! placed an order for a node and enclosure - should be fun, especially with a pi0w!

willie
on the tiny computing Gulf of Mexico

[andrum99]

That's part of why I said "essentially". Yes, setting a bit (so that the boot ROM will check for a bootable USB device if there is no bootable SD card (or eMMC) is really "software", or--more likely--"firmware", but since it's (a) a one time irreversible change, and (b) entirely internal to the SoC, it functions as a hardware change. And, indeed, it *is* a change to the hardware, albeit a very minor one.

If the OTP bit were to be set as part of the masks in the chip manufacturing, no one would question that it was a hardware change. If it gets set as part of board manufacturing, most people would consider it to be a hardware change. The only time it's going to be debated is when the end user can "blow" the bit himself. So for all *practical* purposes, it's a change to the hardware. (This is not the place for the classic joke about what "for all practical purposes" means.)

All of this is, after all, where the line between software and hardware gets a little fuzzy.

I wasn't disputing that part of your statement, which is correct. The part that is not correct is where you state that Raspian 2017-04-10 is the software that recognises the OTP bit being changed.

[Nastanir]

I have tried to use USB boot and this is what happened. Suggestions are welcome.

1. Pi3 + 2017-04-10 Raspbian on a sd card, booted
2. Edited the /boot/config.txt, sudo reboot. No problem.
3. Shutdown, removed sd card. Booting with a Sandisk ultrafit 32GB drive having same software installed using dd.
4. Booting starts after few seconds, progressed and then stays stuck for at least 15min. Drive activity LED occasionally blinks.
5. Screen shot is below


I can boot with sd card without problem.

[Nastanir]

Just a general notice to others looking into this USB booting. Once I forced another BRANCH=next rpi-update everything worked perfectly (using a SanDisk Ultra Fit USB 3.0 Flash Drive, 64 GB). I'm using my RPi3 normally without any need for an SD card. Further, other distributions besides Raspbian have also worked for me, including RetroPie and Ubuntu-MATE.

How do I force BRANCH=next rpi-update ? Writing on /boot/config.txt ?

Thanks in advance

[DougieLawson]

You shouldn't be using BRANCH=next rpi-update that's now stale behind BRANCH=master rpi-update.

Also your failure to boot is because the system booted from USB but can't find the root filesystem (as defined in /boot/cmdline.txt and /etc/fstab). You need to ensure both of those places point to the right PARTUUIDs.

[PeterO]

I have tried to use USB boot and this is what happened. Suggestions are welcome.

1. Pi3 + 2017-04-10 Raspbian on a sd card, booted
2. Edited the /boot/config.txt, sudo reboot. No problem.
3. Shutdown, removed sd card. Booting with a Sandisk ultrafit 32GB drive having same software installed using dd.
4. Booting starts after few seconds, progressed and then stays stuck for at least 15min. Drive activity LED occasionally blinks.
5. Screen shot is below

I can boot with sd card without problem.

Did you edit /coot/config.txt (wrong) or /boot/cmdline.txt (correct) ?
Did you also edit /etc/fstab ?
Are you sure you edited the versions of these files on the USB drive and not on the SD card ?

PeterO

[linux_author]

I have tried to use USB boot and this is what happened. Suggestions are welcome.

1. Pi3 + 2017-04-10 Raspbian on a sd card, booted
2. Edited the /boot/config.txt, sudo reboot. No problem.
3. Shutdown, removed sd card. Booting with a Sandisk ultrafit 32GB drive having same software installed using dd.
4. Booting starts after few seconds, progressed and then stays stuck for at least 15min. Drive activity LED occasionally blinks.
5. Screen shot is below


I can boot with sd card without problem.

make sure that the /boot/cmdline.txt "root=" entry on your new 'boot usb drive' points to the second partition of your ultrafit... during the dd copy, an incorrect partition id will be copied from the sd card!

you must manually edit the /boot/cmdline.txt on the newly copied USB compact drive to reflect its new second partition - the copy process will not do this for you!

at least this has been my experience, YMMV

willie
on the usb-booting Gulf of Mexico

[eaque]

Hi guys, I'm trying again!

My RPi 3 boots on HDD using the older way (BEFORE 2017-04-10 release).
Actually, my version of Raspbian is the february one I downloaded on the site.

I just wanted to know if I could do "apt-get dist-upgrade"? I'm afraid the RPi won't be able to boot on the HDD.

I want my RPi to be up to date for security reasons but I don't want to mess with my RPi.

Thanks!

[DougieLawson]

sudo apt-get update && sudo apt-get dist-upgrade will get you a 4.9.24+/4.9.24-v7+ kernel and that includes everything you need for USB booting.

[Nastanir]

Thank you all for the suggestions. There are multiple checkpoints and things to test before I can reply. I am going out for few days. So hopefully next weekend, I will be able to understand, check and experiment on these and let you know what happened.

[eaque]

sudo apt-get update && sudo apt-get dist-upgrade will get you a 4.9.24+/4.9.24-v7+ kernel and that includes everything you need for USB booting.

Yeah, thanks!

I was asking because it messed up my RPi when I tried 2 months ago (it wasn't able to boot on the HDD).

Good to know !

[ralphrmartin]

If I have 2 USB drives, is there a way to specify which one is used as the boot drive (the other one is used for backing up the boot drive, so both are bootable...)

[andrum99]

If I have 2 USB drives, is there a way to specify which one is used as the boot drive (the other one is used for backing up the boot drive, so both are bootable...)

According to the documentation the Pi will find all mass storage devices, then check each in turn for a bootcode.bin that it can boot from. This implies that if you have more than one bootable mass storage device then there is no way to select which one the Pi actually boots from, unless you can somehow ensure that one gets found first.

[bravotransfer]

I think I found a few things that are going to trip up less sophisticated folks if this isn't going to ultimately be encapsulated in a script or GUI utility.

[sihui]

sudo apt-get update && sudo apt-get dist-upgrade will get you a 4.9.24+/4.9.24-v7+ kernel and that includes everything you need for USB booting.

Yeah, thanks!

I was asking because it messed up my RPi when I tried 2 months ago (it wasn't able to boot on the HDD).

Good to know !

Just to verify: I'm booting on a USB SSD since https://www.raspberrypi.org/blog/pi-3-b ... rage-boot/ was published but had the same problem that sudo apt-get update && sudo apt-get upgrade broke that booting.
Since then I'm using sudo apt-get update && sudo apt-get -y dist-upgrade && sudo BRANCH=next rpi-update (I have to delete /boot/.firmware_revision before that sequence starts) without any problems.

May I switch to

sudo apt-get update && sudo apt-get dist-upgrade

without breaking my system again?

Thx in advance ...

[DirkS]

May I switch to

sudo apt-get update && sudo apt-get dist-upgrade

without breaking my system again?

Yes. rpi-update is not needed anymore.
The docs have also been updated: https://www.raspberrypi.org/documentati ... des/msd.md

[W. H. Heydt]

Has there been any update to the rather vague and fuzzy intent to have the boot-from-USB bit set during board manufacturing? If and when, will that be applied to the Pi2B2 as well? (I know the intent is NOT to apply it to the CM3/CM3L.) I haven't seen any announcements, but such a change might be considered too minor to say anything about...

[NoNameHere]

I can't get USB/Network boot to work for some reason. OTP bit is set and vcgencmd otp_dump confirms it, but Pi just acts like it's not set. Red light comes on and then nothing, even after 15 minutes. It appears that USB doesn't power on at all. Also program_usb_timeout=1 seemed to do nothing, as otp_dump after it was completely same as before.