johnwallace123
Posts: 16
Joined: Tue Feb 28, 2017 12:35 am

Boot order using GPIO

Tue Feb 28, 2017 12:53 am

I've been attempting to work through the boot process of a Raspberry Pi 3 (and CM3), and according to https://github.com/raspberrypi/document ... ootflow.md, it seems to be possible to control the way the pi boots using GPIOs. However, after reading the above link as well as the examples on network booting and USB booting the Raspberry Pi 3, I am still left with the following questions:
  • What bits are program_gpio_bootmode and program_gpio_bootpos? I see that the command program_usb_boot_mode=1 sets 17:0x2000000 in the OTP. How can I verify my OTP is set correctly, and how can I program it if it is not set correctly?
  • Assuming that the program_gpio_bootmode OTP bit is set, how should the GPIO be set in order to enable/disable the boot mode? I've tried to connect GPIO 22 and 39 both to 3v3 and ground (in order to avoid booting the SD card), but have not seen any change in the boot process.
  • Once we have the switches/latches in place, is there any concerns that we need to be aware of in order to avoid interfering with the normal operation of the GPIOs being used?
Thanks for all of your help, and the wonderful products!

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Tue Mar 07, 2017 3:36 pm

I would also like to finally get concise information about "program_gpio_bootmode". As the situation currently is, there isn't any usable information on how to correctly use program_gpio_bootmode; in particular, there's the inherent danger of bricking my Pis. So please, finally document program_gpio_bootmode as USB boot is supported by the main kernels.
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

User avatar
DougieLawson
Posts: 38553
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Boot order using GPIO

Tue Mar 07, 2017 4:36 pm

elkberry wrote: there's the inherent danger of bricking my Pis.
How? The hardware will always boot from an SDCard if that has a bootable FAT partition on it with bootcode.bin, kernel*.img and the related stuff. There's no way to "brick" any RPi without doing catastrophic damage to the hardware (usually with GPIO abuse).
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.

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Tue Mar 07, 2017 8:57 pm

Well, according to https://www.raspberrypi.org/documentati ... ootflow.md it's possible to disable booting from primary and secondard [m?]SD, see the boot flow description at the end of that link.

If users don't know how program_gpio_bootmode and program_gpio_bootpos work and may affect the enable/disable flags, how do we know that we can't brick accidentally by disabling (prim/sec) SD and USB at the same time? Or do you have detailed information which you can share with us?
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

fruitoftheloom
Posts: 22708
Joined: Tue Mar 25, 2014 12:40 pm
Location: Delightful Dorset

Re: Boot order using GPIO

Tue Mar 07, 2017 9:16 pm

elkberry wrote:Well, according to https://www.raspberrypi.org/documentati ... ootflow.md it's possible to disable booting from primary and secondard [m?]SD, see the boot flow description at the end of that link.

If users don't know how program_gpio_bootmode and program_gpio_bootpos work and may affect the enable/disable flags, how do we know that we can't brick accidentally by disabling (prim/sec) SD and USB at the same time? Or do you have detailed information which you can share with us?
Those gpio_modes are only applicable to the install you are configuring.

If you create a SD Card of an Operating System with configuration defaults, booting will seek the boot files on the SD Card.
Rather than negativity think outside the box !

Asus ChromeBox 3 Celeron is my other computer.

johnwallace123
Posts: 16
Joined: Tue Feb 28, 2017 12:35 am

Re: Boot order using GPIO

Tue Mar 07, 2017 9:30 pm

fruitoftheloom wrote: Those gpio_modes are only applicable to the install you are configuring.

If you create a SD Card of an Operating System with configuration defaults, booting will seek the boot files on the SD Card.
So, to clarify, does this mean that the only way to boot from USB/network is to physically remove the SD Card (or in the case of the CM3, to set the EMMC_DISABLE_N pin)?

From the boot flow documentation, it seemed that there was a method of bypassing the SD card simply by setting a OTP bit and pulling a GPIO pin (high?) at boot time. Can someone clarify the following sentence, as it seems to be baked into the ROM, not the SD card:
Subsequently, the boot ROM checks to see if program_gpio_bootmode OTP bit is set, if it is then it reads either GPIOs 22-26 or 39-43 (depending on the value of program_gpio_bootpos) and uses those bits to disable boot modes
As for our use case of a completely remote, headless CM3 unit, we can use the EMMC_DISABLE_N pin coupled with a watchdog timer to enter a "failsafe" boot, but it would have been nice to have a multistage failsafe as described in the boot flow documentation. The main concern that we have is if the bootcode.bin, start.elf or kernel.img becomes corrupted but still is there. In that case, we would get stuck in a kernel panic and essentially "brick" our unit (the labor involved in physically replacing the unit is prohibitive). I've also seen a number of occasions where I tweak a cmdline parameter or config.txt parameter and completely lock myself out of a unit, which would be a Bad Thing in the field.

User avatar
DougieLawson
Posts: 38553
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Boot order using GPIO

Tue Mar 07, 2017 11:32 pm

elkberry wrote:Well, according to https://www.raspberrypi.org/documentati ... ootflow.md it's possible to disable booting from primary and secondard [m?]SD, see the boot flow description at the end of that link.

If users don't know how program_gpio_bootmode and program_gpio_bootpos work and may affect the enable/disable flags, how do we know that we can't brick accidentally by disabling (prim/sec) SD and USB at the same time? Or do you have detailed information which you can share with us?
Since program_gpio_bootmode is another OTP bit then you really don't want to set that until you're sure you'd never want to revert to booting from an SDCard. GPIO22 through to GPIO26 are available on a RPi3 so you can pull those high to control it regardless of the OTP bits but that will be a major pain in the tail if things get set wrong.

But, you still can't brick it.

Checking the OTP bits is trivial: vcgencmd otp_dump | grep 17:
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.

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Wed Mar 08, 2017 1:47 pm

DougieLawson wrote:Since program_gpio_bootmode is another OTP bit then you really don't want to set that until you're sure you'd never want to revert to booting from an SDCard. GPIO22 through to GPIO26 are available on a RPi3 so you can pull those high to control it regardless of the OTP bits but that will be a major pain in the tail if things get set wrong.[/color]
Doug, please forgive me for being slow-witted here; I just want to get a clear understanding of you have in mind.
  • The individual OTP bits/fuses, when set disable a certain booting source, regardless of any associated boot source GPIO## wiring? Argh, only now I'm understanding that terse note "note this cannot enable boot modes that have not already been enabled in the OTP" in the documentation; this may be misleading as the OTP rather disables, or am I mistaken here?
  • When a certain OTP isn't set, then a corresponding GPIO## level does enable or disable a certain booting source? Do I need to pull up or down, and which resistance to Vcc or GND will be needed?
  • How is the GPIO## mapping exactly?
    • GPIO22: boot from primary SD
    • GPIO23: boot from secondary SD
    • GPIO24: boot from NAND
    • GPIO25: boot from SPI
    • GPIO26: boot from USB mass storage device
  • What are GPIO39-43 then used for or on which hardware?
Even after rereading the documentation many and multiple times, it is still totally confusing as to how the OTP setting and GPIO levels really work together: does a OTP set to 1 disable or enable a certain boot source? Does a GPIO set to 1 by pulling up using a 5k resistor enable a boot source if OTP is 0, or 1, or...?
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

User avatar
DougieLawson
Posts: 38553
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Boot order using GPIO

Thu Mar 09, 2017 11:34 am

The GPIOs being high can override the OTP bits.

The second set of GPIOs are only externalised on a compute module.
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.

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Thu Mar 09, 2017 4:58 pm

Override in which sense? Boolean AND or OR? I don't understand why only terse tidbits are thrown in, why not talking clearly to us, in an understandable manner. Sorry, but this is ... exasperating. :roll:
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

User avatar
DougieLawson
Posts: 38553
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Boot order using GPIO

Thu Mar 09, 2017 5:02 pm

Set the PIN high and that completely overrides whatever setting the OTP bit has so the system will boot from the device mapped by the PIN.

Sorry, I don't know how to explain it better.
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.

johnwallace123
Posts: 16
Joined: Tue Feb 28, 2017 12:35 am

Re: Boot order using GPIO

Thu Mar 09, 2017 6:00 pm

I think the trouble here is that we're not sure how to set the OTP bits appropriately and how we can override them with the GPIO. In that case, let's take a step back and see if we can work this via an example.

My goal is to create a hardware switch on a Raspberry pi that bypasses the SD card at boot time without physically removing the card. The reason for this stems from having a Pi in a remote location where it is difficult to remove the SD card. If I can boot to the USB/network, I can re-image the SD card without physically accessing the Pi.

My steps so far:
  • Take a stock Raspbian image (02/2017) with a factory-fresh RPi3
  • Add the lines "program_usb_boot_mode=1" "program_gpio_bootmode=1" and "program_usb_timeout=1" to the /boot/config.txt file to set OTP bits
  • Reboot
After reboot, my OTP bits for word 17 are set as follows:
0x3030000a

If I remove the SD card, I can successfully boot to USB devices, both LAN and MSD.

Now, how can I implement a switch that determines the boot order without removing the SD card? I have implemented the circuit attached, which will pull GPIO 22 high only when the button is pressed. I can verify this because the LED will light up. However, the boot process remains unchanged regardless of whether I push the button or not.
Attachments
gpio_boot_sw.png
gpio_boot_sw.png (6.93 KiB) Viewed 4848 times

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Thu Mar 09, 2017 8:35 pm

DougieLawson wrote:Set the PIN high and that completely overrides whatever setting the OTP bit has so the system will boot from the device mapped by the PIN.

Sorry, I don't know how to explain it better.
Now that is crystal clear. Thank you very much!
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Thu Mar 09, 2017 8:38 pm

johnwallace123 wrote: Now, how can I implement a switch that determines the boot order without removing the SD card? I have implemented the circuit attached, which will pull GPIO 22 high only when the button is pressed. I can verify this because the LED will light up. However, the boot process remains unchanged regardless of whether I push the button or not.
With Doug's answer in mind, my understanding is that you need to use the OTP to disable SDcard boot, and then use the switch/button to enable it when required.
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

johnwallace123
Posts: 16
Joined: Tue Feb 28, 2017 12:35 am

Re: Boot order using GPIO

Thu Mar 09, 2017 8:51 pm

elkberry wrote: With Doug's answer in mind, my understanding is that you need to use the OTP to disable SDcard boot, and then use the switch/button to enable it when required.
That works for me. I can wire a switch that is default closed and opens when pushed. However, what is the way to set the OTP to disable SDcard boot? What bit in word 17 corresponds to the OTP disable SD card boot? Note that I see no difference in boot order with GPIO 22 pulled high (1k pull-up) or low.

If your understanding is correct, this method DOES have the risk of bricking the Pi. If I set the OTP bit to disable the SD card boot and set the OTP bit to shift to the second bank of GPIO pins (39-43), there's no way for me to pull GPIO pin 39 high on a Rpi3, effectively killing the typical SD card boot.

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Sat Mar 11, 2017 8:56 am

Yes, it's my impression too, that we still got hold on only half the picture. But at least it's a step forward, with the missing piece being the precise OTP bit definitions. It's like pulling roots from the earth, I'm afraid.
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Sat Mar 11, 2017 9:04 am

John, why do you need to disable USB boot, and then enable it through the GPIO pin? What use case do you have in mind?

My application is dev lab use, where I want to avoid mSD cards and use USB thumb drives so I can easily swap in and out different OS configurations. My guess then would be to disable SD boot in the OTP instead, as this would speed up USB boot by skipping the 5s timeout during the SD boot attempt. If at any time later an SD boot would be required, I could simply pull up the GPIO for SD boot. Otherwise, USB boot would come next. Probably I wouldn't need mSD boot anytime again.
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

johnwallace123
Posts: 16
Joined: Tue Feb 28, 2017 12:35 am

Re: Boot order using GPIO

Mon Mar 13, 2017 1:12 pm

elkberry wrote:John, why do you need to disable USB boot, and then enable it through the GPIO pin? What use case do you have in mind?
I'm actually more interested in disabling SD boot through the use of a GPIO pin. Our use case is to have a "remote sensing" Raspberry Pi, powered by PoE. Because we're delivering power and data over ethernet, we can assume that if a unit has power, it has access to a local network. As many people have noted, the SD cards are easily corrupted, especially by unexpected power outages, so we'd like to enable a method where if we find ourselves in this situation, we will boot from the network and re-image the SD card. If that fails, we'll just run from the network until we can get onsite to replace the unit. If I can wire up a hardware switch that will bypass the SD card, we can design a small external PCB that has this watchdog timer that acts as a "dead man's switch."

In our final production run, we're planning on using the CM3, which provides the "EMMC_DISABLE_N" pin that we can use, but it's an "all or nothing" proposition; if we turn off the SD card, we are forced to USB boot. We'd instead prefer a gradual failover, where if the eMMC fails, we attempt to boot from secondary SD. If that fails, we then fall back to USB (network) boot, do a "factory reset" and try everything again. If we keep failing, we just run from the network until we can replace the unit.

User avatar
elkberry
Posts: 167
Joined: Wed Dec 28, 2016 9:21 pm

Re: Boot order using GPIO

Mon Mar 13, 2017 6:42 pm

John, thank you very much for your concise explanation! Sounds sound.
From ZX81 to Raspberry Pi, but wait ... where's the 7805 gone?

Return to “Advanced users”