On Mar 6, 2014, at 2: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?
>
It depends on how PC like the chipset is. The more PC like it is the more
likely it is to POST the ROM.
> 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.
>
Well if there is a GPIO to turn power on to the device….
>> 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.
>
Well its probably a bug in the open source code….
> 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.
> 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’m guessing you have a miss formed device path. 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.
/**
This protocol can be used on any device handle to obtain generic
path/location
information concerning the physical device or logical device. If the handle
does
not logically map to a physical device, the handle may not necessarily
support
the device path protocol. The device path describes the location of the
device
the handle is for. The size of the Device Path can be determined from the
structures
that make up the Device Path.
**/
typedef struct {
UINT8 Type; ///< 0x01 Hardware Device Path.
///< 0x02 ACPI Device Path.
///< 0x03 Messaging Device Path.
///< 0x04 Media Device Path.
///< 0x05 BIOS Boot Specification Device Path.
///< 0x7F End of Hardware Device Path.
UINT8 SubType; ///< Varies by Type
///< 0xFF End Entire Device Path, or
///< 0x01 End This Instance of a Device Path and start a new
///< Device Path.
UINT8 Length[2]; ///< Specific Device Path data. Type and Sub-Type define
///< type of data. Size of data is included in Length.
} EFI_DEVICE_PATH_PROTOCOL;
~/work/edk2>svn log MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
------------------------------------------------------------------------
r14504 | niruiyu | 2013-07-25 20:00:21 -0700 (Thu, 25 Jul 2013) | 5 lines
Add 4 APIs to DevicePathLib: ConvertDeviceNodeToText, ConvertDevicePathToText,
ConvertTextToDeviceNode and ConvertTextToDevicePath.
Add a new instance of DevicePathLib which tries to locate the protocol and if
it's not found, it uses the internal functions.
Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
Reviewed-by: Liming Gao <liming....@intel.com>
------------------------------------------------------------------------
r13737 | niruiyu | 2012-09-23 20:20:35 -0700 (Sun, 23 Sep 2012) | 5 lines
Add new API IsDevicePathValid() to UefiDevicePathLib.
Signed-off-by: Ruiyu Ni<ruiyu...@intel.com>
Reviewed-by: Liming Gao<liming....@intel.com>
Reviewed-by: Kinney Michael D<michael.d.kin...@intel.com>
Thanks,
Andrew Fish
> -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
