If I were to wager, I would say that your computer does load PCI op roms.
Most general purpose home/work computers do. I could be wrong, but if I
were you I'd give it a try.
One thing to keep in mind ... drivers probably have not been connected to
their devices yet when loading PCI op roms, so you won't be able to use a
lot of stuff like printing to the screen unless you call it yourself first
in your driver. Here is code to do that (this came from somewhere in edk2 I
think):
EFI_STATUS
EFIAPI
ConnectAllEfi (
VOID
)
{
EFI_STATUS Status;
UINTN HandleCount;
EFI_HANDLE *HandleBuffer;
UINTN Index;
Status = gBS->LocateHandleBuffer (
AllHandles,
NULL,
NULL,
&HandleCount,
&HandleBuffer
);
if (EFI_ERROR (Status)) {
return Status;
}
for (Index = 0; Index < HandleCount; Index++) {
Status = gBS->ConnectController (HandleBuffer[Index], NULL, NULL, TRUE);
}
if (HandleBuffer != NULL) {
FreePool (HandleBuffer);
}
return EFI_SUCCESS;
}
On Thu, Mar 6, 2014 at 4:08 AM, Bill Paul <wp...@windriver.com> wrote:
> 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
>
------------------------------------------------------------------------------
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
