Of all the gin joints in all the towns in all the world, Andrew Fish had to
walk into mine at 05:27:28 on Thursday 06 March 2014 and say:
It occurred to me that I may have come off sounding a little brusque in my
earlier reply, but I sent it around 2AM and my frustration was showing. I
greatly appreciate the replies I've received.
> > Okay, I have to ask this: are you speaking from experience, or is this
> > speculation based on what you've read/heard? Have you actually seen a
> > UEFI (non-Apple) machine that avoids loading drivers from PCI devices?
>
> It depends on how PC like the chipset is. The more PC like it is the more
> likely it is to POST the ROM.
It's very PC-like. The firmware on both my tablet and the Emerson board is
from American Megatrends, and is probably of 2009-vintage. (I upgraded the
Emerson board once to a newer release which I think is from around 2011.)
On both machines, the firmware does not include secure boot support, so that's
not a concern.
> > I find it ironic that the ability to brick the firmware is not platform-
> > dependent, but the ability to recover it is.
>
> Well its probably a bug in the open source code….
It could potentially be in American Megatrends' common code as well.
> > I was hoping someone would at least answer my original question: assuming
> > that the firmware does load and run drivers from PCI devices, does this
> > occur before the Bds code runs or after?
>
> The PCI bus driver is an EFI Driver Model driver. So the enumeration of PCI
> is triggered in BDS usually by the code that connects the console.
> Processing the boot options is the last thing that happens in the BDS.
That's what I was hoping. Thanks for the confirmation.
> > Also, I'm not convinced the Apple EFI implementation would be able to
> > recover from this either. Anything's possible, but the only way to find
> > out is to test it and I'm unwilling to risk it unless I know for sure I
> > have some way to recover the machine.
>
> Have you tried bricking the NT32, EmulatorPkg, or OVFM? It would be good to
> verify this bug does not exist on TOT of the edk2.
I have tried bricking OVMF with the same image -- I wasn't able to do it. With
help from Laszlo, I set things up to use the -pflash option with QEMU to
simulate actually saving the boot variables to the datastore, and I was able
to create the bogus boot variable, however when I reboot, the firmware seems
smart enough to detect the incorrectly formatted entry and remove it from
BootOrder.
> I’m guessing you have a miss formed device path.
I'm using an EFI_LOAD_OPTION structure defined according to what's in the
Beyond BIOS book. It looks like this:
typedef struct
{
UINT32 Attributes;
UINT16 FilePathListLength;
CHAR16 Description[1];
EFI_DEVICE_PATH FilePathList[1];
} PACKED EFI_LOAD_OPTION;
The Description is a unicode string terminated by a NUL unicode character. The
device path information should come immediately after that NUL termination. In
my error case, I accidentally introduced some extra space between the
Description terminator and the start of the file path data.
> There was a case where the
> Length of the device path was zero would cause an infinite loop. Looks
> like it got fixed around 2012-09-23.
That sounds like it could be the culprit, and if it was fixed then, it would
explain why I can't trigger the problem with OVMF now. Thanks for the pointer,
I'll have to look into this at some point.
With the Emerson board, I found when I connected the JTAG debugger that the
CPU was spinning in a loop of some kind and never hitting the exit condition.
I managed to break it out of that loop, and then it seemed to get stuck in
another outer loop. Once I released it from there, the firmware seemed to get
past where it was jammed, after which it removed the bad entry from BootOrder.
I was able to reset the board and start it up successfully after that.
Also, to follow up to Thomas Rognon:
> - PCI enumeration occurs before BDS (boot device selection). PciBusDxe is
> the driver that does it. Here is the source for the part that actually
> loads the drivers if you're interested:
> https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Bus/Pci/PciBusD
> xe/PciOptionRomSupport.c
Another confirmation is always good. :) Thanks.
> - If SecureBoot is on, all hope is not lost. You may have one of the
> machines where SecureBoot doesn't check op roms (crazy, right?). Otherwise,
> you'd have to have your driver signed.
Fortunately neither machine includes secure boot support in its firmware build
(there are no setup screen options for it anywhere that I can find).
> - Make sure to use the efirom utility. Flashing just the driver won't
> work.
I was able to create a working driver ROM by adding my own sample driver to
the OptionRomPkg directory. It even worked (see below).
> Also, from a security perspective, crashing because of improperly formatted
> boot variables is really bad because it's so easy to do and so hard to fix
> if you don't have IPMI or something.[...]
Well, yes. I agree. I've managed to do this three times so far. The first time
the failure was a little different (I added an entry to the top of BootOrder
for a BootXXXX variable that didn't exist). I got lucky that I was able to
recover the machine just by unplugging the hard disk and rebooting it a couple
of times.
But as I said before, what's extra frustrating is that you should be able to
enter the setup menu and fix this by just deleting the bogus entries, but you
can't because the firmware gets stuck before entering the setup menu (even
though it clearly knows you want to get there and even prints "Entering
Setup..." on the screen). To me it makes more sense to abort the boot path
selection entirely and just go straight to the user menu where the human in
the equation can make sense of things.
Anyway, I think I have a potential solution now. As an experiment, I was able
to create my own sample UEFI driver ROM using the OptionRomPkg framework. One
thing I have a lot of around here is ethernet cards, so I dug up an Intel
PRO/1000 82574L PCIe NIC and flashed my driver onto it in place of its
original PXE ROM. (Yes, I saved a copy of the original flash contents.) Right
now all the sample code does is use SetVariable() to create a datastore entry
named "BLAH" with the contents "THIS IS A TEST" in unicode. Booting up the
Emerson target with this card plugged in and going to the UEFI shell, I can
see that the variable has been successfully created using the dmpstore
command.
The one tricky thing was figuring out how to flash the card. Intel is nice
enough to provide a tool for re-flashing all their NICs -- it even comes in
the form of a UEFI application binary. Unfortunately it only knows how to read
images from a proprietary "FLB" file format -- I can't just give it my sample
EfiRom file and tell it to save that into the flash.
I got around this using flashrom:
http://flashrom.org/Flashrom
It runs on FreeBSD. I had to edit the nicintel_spi.c file to add the PCI ID
for the 82574L chip, but then it worked fine.
The only issue now is connecting the 82574L NIC to the tablet. For that I plan
to order one of these:
http://www.amazon.com/KZ-B24-PCI-Express-to-MiniCard-Extender/dp/B00B2C21PM
I need to get one of these things anyway since we've started getting eval
boards for VxWorks development with miniPCIe slots, and to test them we need
to be able to plug in a device for which we have a VxWorks driver.
Anyway, thanks again for all the information. Hopefully I'll be able to test
this soon and find out of it works.
-Bill
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Member of Technical Staff,
wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=============================================================================
"I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
