| Summary: | [Minnow] Firmware should automatically boot from defined boot paths | ||
|---|---|---|---|
| Product: | [Hardware Platforms] MinnowBoard MAX Firmware | Reporter: | Darren Hart <dvhart> |
| Component: | minnowboard-uefi-firmware | Assignee: | Darren Hart <dvhart> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Low | CC: | leroy.p.leahy, mhalstead, scott.a.garman, sjolley.yp.pm, warthog9, wmills |
| Version: | unspecified | ||
| Target Milestone: | Production Release | ||
| Hardware: | MinnowBoard | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Darren Hart
2013-05-23 15:13:00 UTC
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. |