From past experience, this should work like this: On first boot the firmware scans SATA, MMC, and USB (in that order) and automatically boot the standard EFI payload (EFI/BOOT/BOOTIA32.EFI). I think that path changes in the spec for fixed media like SSDs. On the subsequent boot, it will attempt to boot only that path. If that fails, I believe it drops to the shell, you run the commands to get your payload ready, then "exit", select from the options to boot, and that choice should be selected on the next boot.
Is there something that you want changed? I believe the desired support is in place already. The boot order currently specified by the PCDs is: PcdBootOrderPayload | 0 PcdBootOrderHD | 1 PcdBootOrderDvdCd | 2 PcdBootOrderUsb | 3 PcdBootOrderNetwork | 4 HD includes SD and SATA.
It is my understanding that if the existing path disappears, the automatic boot stops and it must be added manually to get it working again. Is that still the case? In other implementations, the boot path order would be scanned again in the event the previous boot path failed.
Lee, is this bug likely to get some cycles? Should we continue tracking it?
Dropping to low as we have the bcfg commands documented. It would be nice if it were more friendly, but it isn't too terrible to deal with.
I have found the bcfg command very scary to deal with. I was very hesitant to play with it until I had a known good external SPI flash programming solution. When I was playing with it I was able to get myself into a situation where I needed to reflash (this was mostly using "bcfg boot rm XX") At a minimum I think you should: Add documentation to show how to use "bcfg boot mv XX 00" Where XX is the desired boot mode. (What I found non-obvious about this command was that it moved the target and higher boot options down, it does not overwrite like array assignment. This makes it easier to use than what I was thinking.) I find this to be the safest option. If the boot does not work you can disconnect the 00 device (eth cable, SD Card, etc) and it will try and give up. You can then select the shell and fix things. You can still get into trouble with this method if you put the "EDK2 Utility" first since it will always succeed and has no method to boot something else. I think it would be good to add a Firmware failsafe mode: If the first user button is pressed at startup it should boot the shell regardless of what the user has put into the UEFI vars.
Thanks Bill, good suggestions. Chao, any thoughts on this one?
1. bcfg is in shell spec scope. You can reference UEFI Shell Specification 2.0 which is available on UEFI.org 2. Recovery is a good suggestion. We can present all boot options for users to choose after boot failure
Assigning this NEEDINFO to the person who needed the INFO since the INFO has been supplied. Moving it to Accepted at RP's suggestion.
MinnowBoard v1 has reached new feature EOL, FW development is done as are new hardware features. If you feel EXCEEDINGLY strongly about an issue please re-open it for discussion but be aware that we are recommending individuals migrate to the MAX platform.