Re: [edk2-devel] Device and driver

["Kumar G" <kumarg27061979@gmail.com>]

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

Thanks Tom

On Tue, 9 Jun 2020 at 15:27, 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
> <kumarg27061979@gmail.com>> Sent: 08 June 2020 19:10 To: Tomas Pilar
> <Tomas.Pilar@arm.com <Tomas.Pilar@arm.com>> Cc: devel@edk2.groups.io
> <devel@edk2.groups.io>; nd <nd@arm.com <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 <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 <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   *
>
>
>
>
> *  *
>
>

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