[edk2-devel] Device and driver

Tue Jun 9 09:56:53 UTC 2020

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 at gmail.com>
Sent: 08 June 2020 19:10
To: Tomas Pilar <Tomas.Pilar at arm.com>
Cc: devel at edk2.groups.io; nd <nd at 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 at arm.com<mailto:Tomas.Pilar at 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 at edk2.groups.io<mailto:devel at edk2.groups.io> <devel at edk2.groups.io<mailto:devel at edk2.groups.io>> On Behalf Of Kumar G via groups.io<http://groups.io>
Sent: 08 June 2020 09:15
To: devel at edk2.groups.io<mailto:devel at 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

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#60939): https://edk2.groups.io/g/devel/message/60939
Mute This Topic: https://groups.io/mt/74749142/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20200609/25eb9aea/attachment.htm>