Bill, The User Interface is not defined in EFI, so it is an implementation detail, so there is not a generic answer to this.
In general there are hot keys to enter setup, and hot keys to clear “CMOS” which should also clear the EFI Variables on a modern system. You will need to find the mapping for the hardware that you have. Thanks, Andrew Fish On Feb 11, 2014, at 4:51 PM, Bill Paul <[email protected]> wrote: > So, while working on my UEFI OS loader, I managed to brick a couple of > machines. I recovered all but one of them so far (sadly that one is my > personal tablet -- there may yet be a way to save it but I'm holding off on > it > until I'm better prepared for the attempt). > > I want people to be able to set their machines to boot VxWorks via UEFI > unattended, preferably in a consistent fashion. (Consistent, because there > seems to be enough variation in setup UIs that I can't count on the user > always being able to figure it out.) > > Now, I know UEFI handles boot path selection using the BootXXXX and BootOrder > variables, and I know that OSes can use the GetVariable()/SetVariable() > runtime services to set up the boot order during install. > > Having VxWorks call the UEFI runtime service routines is a bit of a hassle > though (especially if you're running a 32-bit VxWorks on a 64-bit UEFI > system) > and being an embedded OS we don't go through the same installation process as > a self-hosted OS like Windows anyway, so instead I fixed it so that you can > configure the boot path in the OS loader. After the OS loader starts, you can > hit a key to pause the OS launch and then enter a small boot manager menu > where you can add or remove boot path entries. > > Note that I am testing with UEFI 2.3.x systems, but they're not particularly > recent. One example system is from Emerson Network Power and it has an AMI > BIOS from 2009. Actually, so far all three of the machines I managed to > clobber have AMI BIOSes, but are from different hardware vendors. (One is > from > Dell.) > > The tests I do involve setting the system to boot from a USB thumb drive. > With > the first case that I encountered was with a Dell laptop. I was correctly > adding a new BootXXXX variable and updating the BootOrder, and booting from > the thumb drive worked. As near as I can figure, the problem was that the > routine to undo this change was faulty: it would delete the recently created > BootXXXX variable but fail to update the BootOrder. This left the laptop > stuck > trying to access a BootXXXX variable that didn't exist. (For example, the > BootOrder could be saying 0001000200030004, yet there is no Boot0001 variable > present.) Hitting F2 caused it to say "Entering setup..." but it would never > get there. Similarly, hitting F12 would cause it to say "Preparing one-time > boot options..." (or something similar) but it would never reach that point > either. > > I finally managed to un-wedge it by disconnecting the hard disk (which > luckily > was easy to do on this model laptop as it was designed to be upgraded). After > I did that and rebooted the machine a couple of times, it finally seemed to > go > back to normal. I suspect that unplugging the disk caused the firmware to re- > probe the available boot devices and finally it updated the BootOrder such > that it threw out the bogus entry. > > I found the bug in my code that was preventing the boot path removal from > resetting BootOrder correctly and fixed it, and that took care of the issue. > I > was a bit annoyed that I had almost irretrievably bricked the machine > (especially since it was on loan from IT) but once I had it back I forgot > about it. > > Then recently I managed to introduce another bug which caused me to brick my > Emerson board and my tablet. The failure here was a little different. From > what I can tell in this case, I was adding an incorrectly formatted BootXXXX > variable. The "Firmware Boot Manager" section in chapter 11 of the Beyond > BIOS > book descripes the EFI_LOAD_OPTION structure. You're supposed to have a > Description field followed by FilePathList array. The FilePathList is > supposed > to immediately follow the null-terminated unicode description string. In my > case, I was calculating the offset for the FilePathList incorrectly and > placing it father away. > > The result was that the machine would start up, display the Emerson banner > and > the "Press F2 or F7" prompt, and then get stuck. As with the Dell, trying to > hit F2 to enter setup or F7 to access the BBS screen would fail (it would say > "Entering Setup..." after hitting F2, but would never make it.) > > I enabled the BIOS recovery jumper and tried to reload the BIOS image via the > serial port -- it allowed me to do that, but this apparently didn't reset the > NVRAM contents because the system was _still_ wedged. > > Finally I remembered that, this being a development board, it has an XDP > connector on it and I have a Wind River ICE2 which is compatible with it. > Using the ICE I was able to take control of the CPU and found it was stuck in > a loop. I forced it to break out of the loop... and then found it got caught > in another outer loop. I forced it out of that one too, and it got farther > along and launched the PXE option ROM. It got stuck before booting correctly, > but when I reset it this time I found it had updated the NVRAM contents to > remove the BootOrder entry for the bad boot path and it was no longer bricked. > > Now, I don't know if this is a general problem with the EDKII code or not. I > tried to trigger the same condition with OVMF, but I may be hamstrung by the > fact that the QEMU/OVMF combo doesn't actually emulate a persistent flash > device. I'm also simulating booting from a hard disk drive rather than a USB > thumb drive. (I'm not sure how to do the latter.) OVMF seems to retain the > bogus boot path in the data store -- I can see the BootXXXX variable with > dmpstore from the shell and I can see that BootOrder is still set to consider > it first -- but it seems to be smart enough to ignore it as I always wind up > back at the shell prompt rather than entering my boot loader. > > There are several possibilities here: > > 1) The problem is specific to a particular vendor implementation of UEFI > 2) The problem is not specific to any vendor but has been fixed in the EDKII > code already and I'm just rehashing ancient history > 3) The problem only occurs with certain boot devices (USB?) > 4) The problem only occurs with certain specific invalid data in the BootXXXX > variable > 5) I really do need to simulate having a persistent NVRAM in order to pass > through the right code path to trigger the failure > > One thing I would like to know is whether it's the case that, in general, > UEFI > evaluates all the boot paths before allowing the user to enter the setup > screen. I found it very frustrating that the machine would taunt me with the > catch-22 of getting stuck before letting me into the setup menu with which I > could cure the problem that was getting it stuck. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, > [email protected] | Master of Unix-Fu - Wind River Systems > ============================================================================= > "I put a dollar in a change machine. Nothing changed." - George Carlin > ============================================================================= > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
