Of all the gin joints in all the towns in all the world, Andrew Fish had to walk into mine at 18:02:30 on Wednesday 05 March 2014 and say:
> On Mar 5, 2014, at 5:53 PM, Bill Paul <wp...@windriver.com> wrote: > > Of all the gin joints in all the towns in all the world, Carsey, Jaben > > had to > > > > walk into mine at 17:26:07 on Wednesday 05 March 2014 and say: > >> A driver is able to do this, but whether your driver gets loaded and run > >> is a platform policy decision and may be different for your tablet. > > > > Can you elaborate? Where is the policy controlled from? > > The platform OEM. If you always new you would only support booting from > internal devices, then disabling running a ROM from the PCIe slot improves > security. 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? I'm surprised that this would be the case, because the last time I read through the UEFI spec, I saw several references to PCI option ROM loading, but I don't remember seeing anything about it being platform-dependent. > Does your tablet have an RTC with a battery backup? Maybe you could pull > the battery, and maybe reseting the RTC CMOS would trigger some kind of > recovery action? Just a wild guess. As a wise squirrel once said: "Aw Bullwinkle, that' trick _never_ works." Believe me: I've been there, I've done that, and the t-shirt didn't fit. Unplugging the backup battery had no effect on either the tablet or the Emerson MATXM-411 development board that I bricked with the same buggy code. The Emerson board at least has a jumper to activate a BIOS recovery mechanism -- you can re-flash the firmware via serial port, and the recovery option is presented before it gets hung -- but that didn't help either: I was able to re-flash the firmware, but that apparently wouldn't clear the NVRAM. I was only able to un-wedge it using JTAG. The tablet, by the way, is an ExoPC Slate. It was actually Intel's MeeGo development platform. > On a Mac you do cmd-opt-P-R to reset this kind of thing, but you are in the > area of platform specific behavior. So it is hard for us to give too much > concrete advice…. I find it ironic that the ability to brick the firmware is not platform- dependent, but the ability to recover it is. 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? 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. -Bill > Good Luck, > > Andrew Fish > > > I know that some UEFI firmware implementations have a setup menu option > > to enable/disable loading of option ROMs, but it's not clear to me if > > this applies only to BIOS option ROMs -- usually it affects whether or > > not the PXE ROM is loaded. And the setup menu on this tablet is very > > limited -- I'm pretty sure it didn't have any option to configure this. > > > >> If you go ahead with it, you may borrow some code from the shell's BCFG > >> command for BOOTXXXX variable manipulation. > > > > Oh I already know how to handle this with gBS->SetVariable(). (That's > > what got me into this mess in the first place.) > > > > -Bill > > > >> -Jaben > >> > >> -----Original Message----- > >> From: Bill Paul [mailto:wp...@windriver.com] > >> Sent: Wednesday, March 05, 2014 5:12 PM > >> To: edk2-devel@lists.sourceforge.net > >> Subject: [edk2] Question about firmware startup order of events > >> > >> You may recall that I mentioned that due to a mishap with some UEFI OS > >> loader code I was developing, I managed to brick my UEFI-based tablet by > >> setting an improperly formatted boot path variable as the default boot > >> path. > >> > >> Unfortunately unplugging the internal SSD drive didn't have any effect, > >> and I haven't been able to think of a way to directly re-whack the > >> NVRAM, and I don't have a way to hook my JTAG probe to it. I did think > >> of one potential way around the problem, but there's something I need > >> to clarify first. > >> > >> The tablet has wifi support, in the form of an Atheros mini-PCIe adapter > >> which is plugged into the main board. This adapter can be easily > >> unplugged and replaced. > >> > >> What I'm considering is using the EDK2 to cobble together a UEFI driver > >> with just enough code in it to erase the BootXXXX and BootOrder > >> variables and flashing it to some device which I can fit into this > >> mini-PCIe slot, in the hopes that I can get the firmware to run this > >> code for me. > >> > >> But this will only work if the driver is loaded and executed before the > >> firmware gets to the boot device selection code. Conceptually it would > >> seem that this would be the case (I mean, you need to load the drivers > >> for devices before you can use them as boot paths, right?) but I'm not > >> positive if this so. > >> > >> Can anyone tell me if this idea has a chance of working? It costs me > >> nothing to tinker around with the EDK2, but it would cost me a little do > >> obtain a suitable PCIe device, so I want to check before I end up > >> spending money for nothing. > >> > >> -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.cl > >> kt rk _______________________________________________ > >> edk2-devel mailing list > >> edk2-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > >> > >> ------------------------------------------------------------------------ > >> --- --- 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.cl > >> ktr k _______________________________________________ > >> edk2-devel mailing list > >> edk2-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/edk2-devel -- ============================================================================= -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
