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.