Re: [edk2-devel] Device and driver

["Andrew Fish" <afish@apple.com>]

[-- Attachment #1: Type: text/plain, Size: 10024 bytes --]

Kumar,

Tom gave a really good answer. Let my give you some history. 

Big picture the UEFI Driver Model that uses the DRIVER_BINDING_PROTOCOL is the the replacement for old BIOS Option ROMs. In olden times the BIOS Option ROMs started to get workarounds for the BIOS and the BIOS had work around for the ROMs and on servers different vendors had different custom Option ROMs to make stuff work. So in EFI we took all the policy out the Option ROM and that is why they just publish DRIVER_BINDING_PROTOCOL today. 

The DXE Driver you referenced is more about moving the BIOS proper to use drivers vs. being a monolithic block of code. If you look at an INF file and see a depex that is about the order of the DXE Driver dispatch. TRUE means right now, and no depex means depend on all the EFI services being available. So in general DXE drivers abstract the chipset and the EFI Boot and Runtime services that other UEFI Driver Model drivers depend on. 

The last DXE driver is called BDS (Boot Device Selection) and it contains the platform policy. So this is the code that will connect your driver, or not. The idea is you can just replace the BDS and make your system look like an ATM machine, PC, or Mac. 

BDS and DXE are actually defined in the PI Specs (still owned by the UEFI Forum). PI is about building the modular BIOS, and UEFI is about how to write Option ROMs and OS loaders. 

Thanks,

Andrew Fish

> On Jun 9, 2020, at 2:56 AM, Tomas Pilar (tpilar) <Tomas.Pilar@arm.com> wrote:
> 
> Hi Kumar,
>
> The UEFI drivers follow a two stage loading mechanism. When the driver is loaded/executed, it loads itself into memory and installs a DRIVER_BINDING_PROTOCOL on its own handle. That protocol provides API for the platform to ask the driver whether it supports a particular device and to bind/unbind from a particular device. Once all drivers are loaded in this way in memory, the platform then tries to bind all devices In the system to all drivers, one by one, using each DRIVER_BINDING_PROTOCOL instance. So as a driver, you provide the API and then sit there until a platform gives you a device to drive (The platform will offer you ALL of the devices, so your Supported() function has to be very fast and very quiet).
>
> Devices that are offered to drivers are in the form of a ControllerHandle with a device path and some form of communication protocol based on the bus the devices sit on. So for PCI devices that would be a PCI device path and a PCI_IO_PROTOCOL. However, as a driver, you might need to create a new handle as a child with a different device path based on functionality. For example, as a network driver, you will be given a handle with PCI_IO_PROTOCOL for communication and a PCI device path installed on it. During binding, you will have to create a child handle with some networking protocols installed on it (that you produced) and a MAC media device path.
>
> Roughly:
>
> Controller usually means a device and ‘connecting a controller’ means offering the devices to all resident drivers to see if one can bind to it. Represented by a handle with a hardware device path installed on it and with some form of messaging protocol that can be used to talk to the hardware. Usually PCI_IO_PROTOCOL.
>
> Driver really is anything that produces DRIVER_BINDING_PROTOCOL installed on its own handle. Usually with a device path pointing to a file/memory from where it was loaded. Will have also have LOADED_IMAGE_PROTOCOL describing the memory where it resides.
>
> The early chapters of the UEFI spec describe this process in more detail.
>
> Also, the enumeration of devices and creating the controller handles with low lever IO protocols and hardware device paths is done by the platform, I wouldn’t worry too much about that at this point.
>
> Cheers,
> Tom
>
> From: Kumar G <kumarg27061979@gmail.com <mailto:kumarg27061979@gmail.com>> 
> Sent: 08 June 2020 19:10
> To: Tomas Pilar <Tomas.Pilar@arm.com <mailto:Tomas.Pilar@arm.com>>
> Cc: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; nd <nd@arm.com <mailto:nd@arm.com>>
> Subject: Re: [edk2-devel] Device and driver
>
> Thanks Tom,
> I really appreciate your reply, 
> I didn't get 100% but I went through ~3K pages of UEFI specification. 
> 
> I understand a bit of protocols and handles now. 
> Handle is an identifier on which some sort of function pointers (protocol in UEFI world) are installed.
> 
> Thing which I am trying to understand, where EFI Boot service's connect controller API says
> 'connect one or more drivers to controller'
> Basically at code level, where this differentiation is done, what is controller-handle and what is driver.
> 
> If you say , at entrypoint controller needs to install a protocol such as I/O or read/write protocol supported by this controller-handle 
> (Say C1). 
> Later some piece of code (may be bus or other) create another controller-handle (C2) (which is a device, connected over this i/o).
> And the driver needs to install *only* device binding protocol.
> During binding , this driver looks for controller (C2) and when found it happily says matched or supported. 
> If the above rule is true, then it’s easy to understand the device (aka controller-handle) and the driver.
> 
> But in a few places, I am not able to understand what is a controller and what is a driver really. 
> e.g   
> at ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
> By name this looks to be a driver for Lcd gfx,  but if this is driver then what it has to do with device path. 
> Is this driver and controller  managed by the same code ? no clear differentiation
> 
> For sure, this is new world for me, There will be differences w,r,t Linux
> 
> Thanks
> KumarG
> 
>
> On Mon, 8 Jun 2020 at 17:04, Tomas Pilar <Tomas.Pilar@arm.com <mailto:Tomas.Pilar@arm.com>> wrote:
> Hi,
>
> By no means a complete answer but some important points below.
>
> There are two important concepts in UEFI that you absolutely need to get comfortable with. These two are Handles and Protocols.
>
> You can think of a protocol as an implementation of a well defined API that allows you to do something. For example, do you want to print a string to screen? There is a SIMPLE_TEXT_OUT_PROTOCOL provided by the platform (hopefully) that allows you to do that. There might be multiple instances depending on how many devices support displaying/printing/outputting text. Do you want to send some data to a PCI device? The PCI_IO_PROTOCOL is your friend. Syntactically, a protocol
> is just a well-defined C struct, defined in a header file in an include folder somewhere (both the producer and the consumer of the protocol must have access to the header file). You can navigate to MdePkg/Include/Protocol to look at some examples.
>
> Then there are handles (EFI_HANDLE). The main use of handles is that protocols are installed on handles, and as such can be conceptually grouped (a handle can carry many different protocols but a protocol instance is usually installed on only one handle). A ControllerHandle is just a handle – lets you install protocols on it. But importantly, the ControllerHandle contains those protocols that pertain to a single device. You can’t really do much if you are given a handle but you can check what protocols are installed on it and use those. When the platform enumerates peripheral devices, these are represented internally as ControllerHandles and each of them will have a PCI_IO_PROTOCOL already installed by the point a driver gets to it. That PCI_IO_PROTOCOL is then the way the driver can talk to the device. Handles are tracked in an internal database and you can search through them.
>
> Speaking of which. Most of the stuff you do in UEFI is done by protocols, with the main exception being the intrinsic services such as allocating memory, handling callbacks/events/locks, connecting/disconnecting devices, loading and executing files/code, and of course installing/using/removing protocols. These functionalities are provided by the BootServicesTable which you really need to read about in the UEFI Spec.
>
> There really are no quick answers here unfortunately, you’ll have to get stuck in and play around until you get comfortable with things. I appreciate that the paradigm is quite different to for example Linux, but there are (usually) quite good reasons for many of the differences.
>
> Cheers,
> Tom
>
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> On Behalf Of Kumar G via groups.io <http://groups.io/>
> Sent: 08 June 2020 09:15
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Subject: [edk2-devel] Device and driver
>
> Hi Edk2 expert folks, 
> I am starting on UEFI coming from Linux background, 
> In Linux,
> There is clear identification of device and driver, platform code adds the device into system and 
> later OS code binds driver for the same. 
> With UEFI driver writer guide, I am bit confused,
> please help me, how devices are being added in UEFI.
> what code/API adds device. 
> Let me ask with an example, say i have PCI controller then
> driver for this controller (DXE_DRIVER) could be named as controller handle. 
> Now there could be a driver represented as device handle, which handles
> device connected over this PCIe. 
> Now when PCIe bus driver scans the bus then it found a PCIe device, 
> how this bus driver adds the device into system ? 
> Second, say we have spi controller and with this controller
> there is spi flash. 
> with UEFI terminology 
> spi controller will be controller handle 
> spi flash will be device and 
> driver for this flash will be called driver handle. 
> spi controller and spi flash are marked as DXE_DRIVER
> what I am missing,where are added spi flash as device in system ?
> Sorry for basic question, but UEFI is complicated w.r.t originally i thought
> Thanks
> KumarG
>
> 


[-- Attachment #2: Type: text/html, Size: 22863 bytes --]