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 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 > 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 * >