DMackG wrote: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.

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

DMackG wrote: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.

DMackG wrote: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.

linux_author wrote: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".

linux_author wrote: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".

linux_author wrote: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".

W. H. Heydt wrote: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.

ayttransfer wrote: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.

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.

Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

I'll do your homework for you for a suitable fee.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

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

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

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!

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.

ralphrmartin wrote: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.

DougieLawson wrote: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.

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

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.