assuming I have a bootable USB mass storage device AND a bootable sd card inserted, is there a setting which device will be preferred for booting?
Search back a few posts in the thread. I have the same question. Here's what I know so far:
This document implies that with the correct OTP settings you can then use GPIO pins to select what to boot from: https://www.raspberrypi.org/documentati ... ootflow.md
However it is not clear how to enable this mode. I've submitted a gitlab issue asking for clarity on this.
The other option (still in this thread), is to short CMD and Vcc (not recommended, look back at this thread) on the SD card for a virtual eject. This works for me about 99% of the time (yes I have measured it). So, I've gone forward with this approach.
My requirement is for fully automated testing of an SD flash image without having to rely on access to that image in the event of a failure. So hacks like dual partitions, or editing /boot, etc... are not an option.
My autotesting rig has a sparkfun microsd breakout board with the microsd card in it. I have the SD card CMD and Vcc connected to a relay. The RPI3 is connected to an Odroid C2 emulating USB mass storage from its OTG port. This way I can remotely control the contents of the USB drive. Lastly I use a Yepkit hub to power the RPI3 and also power it on/off. Oh, and I use a "null modem cable" to get to the serial console by connecting the GPIO serial pins of the Odroid (ttyS1) to the GPIO serial pins of the RPI3 for console access (the Odroid has 2 serial ports, S0 for console, and S1 for whatever you like).
With this setup from the Odroid C2 I can see the RPI3 console, power it on/off, and via the relay insert/eject the SD card. The later controls booting from SD or USB. The USB images are delivered by OTG from the odroid and managed there as well.
About 1 out of 100 the CMD/Vcc short does not work. To fix I just power cycle (power off, sleep 5, power on). My USB RPI3 image has sshd and I use that to test if the boot to USB worked (ssh hostname some verification command). Once booted from USB, its safe to turn the relay off to remove the short. In < 1 sec the SD card shows up to the USB OS (from /dev/sda) as /dev/mmcblk0 and I can then dd a test image and just type reboot to boot it.
My current application takes 35 min to go from dd, to boot, to completing all tests. I have had this running continuously for about a week without issue and have completed 100s of tests.
Again, the threads above do not recommend this approach, but it works for me now.
That all said my preference would be:
1. Network boot first, then fail to USB, then to SD. With this I could control network vs SD via DHCP or TFTP control. Untested but I assume that if the TFTP payload is missing for that host then it would fail through to the next boot method (like x86 does with PXE configure to boot before HD).
2. The GPIO control based on the docs above.
Let me know if you figure out something more elegant.