> On May 11, 2015, at 2:19 AM, Laszlo Ersek <ler...@redhat.com> wrote:
>
> Andreas,
>
> On 05/11/15 02:09, Andrew Fish wrote:
>>
>>> On May 10, 2015, at 4:20 PM, Andreas Galauner <andr...@galauner.de> wrote:
>>>
>>> On 10.05.2015 15:32, Cohen, Eugene wrote:
>>>> I apologize since this was probably not the answer you were looking for.
>>>
>>> No worries, it's kind of what I expected. Hence the question about the
>>> virtual bus.
>>> What I didn't understand was the Driver Binding protocol just by looking
>>> at the source. I guess I should've looked a bit more into the specification.
>>>
>>
>> The BDS does a gBS->ConnectController() on the device path for the
>> boot devices. This causes all the drivers in the chain for the device
>> to get their Driver Binding Start() function called.
>>
>> So the driver gets called on a handle created by a parent bus driver.
>> The root of the device path chain is always a DXE driver (on a PI
>> system), and on a PCI this is the PCI Host Bridge.
>
> * I'd like to put emphasis on the above -- the UEFI driver model and the
> driver binding protocol will work once you have some "input" handles to
> operate on. A bus driver will then create child handles and install
> protocol interfaces on the child handles, a device driver will install
> (a) protocol interface(s) on the input handle itself. Both driver kinds
> need an "input" handle, and AIUI your question was how to create those
> "axiomatic" (= not originating from any other handle) / root handles.
>
> (Plus, as a technicality, the drivers that use the UEFI driver model
> don't do the above checks for support & the input handle binding in
> their entry points. In their entry points they just register instances
> (usually, one instance) of the driver binding protocol, and member
> functions of that protocol instance will get callbacks when BDS calls
> gBS->ConnectController(), as Andrew described.)
>
> So, as Andrew says, for producing the various "root handles", you need a
> DXE driver that incorporates platform specific knowledge, and just goes
> ahead and creates new handles and installs protocol interfaces on them
> in the driver entry point (ie. it would expressly not follow the UEFI
> driver model).
>
> * You can see one example for this here:
>
> ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/
>
On the BeagleBoard there is a fake PCI driver:
https://svn.code.sf.net/p/edk2/code/trunk/edk2/Omap35xxPkg/PciEmulation/
This driver was to allow the edk2 PCI EHCI driver, and USB stack, to “just
work”.
Thanks,
Andrew Fish
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
