Thanks Tom On Tue, 9 Jun 2020 at 15:27, Tomas Pilar (tpilar) <tomas.pi...@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 <kumarg27061...@gmail.com > <kumarg27061...@gmail.com>> Sent: 08 June 2020 19:10 To: Tomas Pilar > <tomas.pi...@arm.com <tomas.pi...@arm.com>> Cc: devel@edk2.groups.io > <devel@edk2.groups.io>; nd <n...@arm.com <n...@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.pi...@arm.com <tomas.pi...@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 <devel@edk2.groups.io> <devel@edk2.groups.io > <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 > <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 * > > > > > * * > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#60951): https://edk2.groups.io/g/devel/message/60951 Mute This Topic: https://groups.io/mt/74749142/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
