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 <devel@edk2.groups.io> On Behalf Of Kumar G via groups.io
Sent: 08 June 2020 09:15
To: 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