From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) by mx.groups.io with SMTP id smtpd.web11.948.1591639840912457497 for ; Mon, 08 Jun 2020 11:10:41 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IcQb+Pwp; spf=pass (domain: gmail.com, ip: 209.85.222.46, mailfrom: kumarg27061979@gmail.com) Received: by mail-ua1-f46.google.com with SMTP id r9so6181984ual.1 for ; Mon, 08 Jun 2020 11:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HOAr5LtL0P2AjcI+YtHY8pqrQ+hu43ksXLA84slipl4=; b=IcQb+PwpM0zMHtJhh3EWu7xGRhcAeWyrgyi1BCuxQjBzPD8vBUIMtphukFkbmxcm8P tvBHLPbQmRRX8w7EvfnuOt+cxWDWptS9HT2cUV0yjAyKfosWv+0Hpm3qrujilBRDdHGo m8PUIeXQTjPGbqprSJ40r12tetkGXJlMGz4sV99gSGp15/9miQmIaZfvIB62KQqt0VCc aXdmU03ULWSB67ad6+Vwtq6rJ1MQcEXxsxGXV3ckB7zdQ0DAJ9xHWqshI9ZkTMyfpfNG XlrPUQ9walqeXaTqY03WX9tlTPyLIZ91diAM7ma/QMfILt94OgmNLdb4GlgjyDt2faLp Ya8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HOAr5LtL0P2AjcI+YtHY8pqrQ+hu43ksXLA84slipl4=; b=P4ptUDLrbfoM9YhuIwNi5hmvC0zNl1YtcYVwX2b+OGWDMlWHKuFa49DwNar88NUamR w5UP5/HmIGvCMZZLw09n7lci63uMZqSsy2kb+IKsKrxqs6cQAdhm9g7G1aUzRnLMAGCk CLnF5VTWbWfkiXTUaKxeTVAlfUxPXi9gOk2GbCkDLFwW7VL0rsiW7Rc9kJGYMzIsdgXT CRQeqDv7IBCIU2wbp/XWwKaDMgr7WW1pzNDprzYh5iJN1pesuCptmhq4E8b2uNWojsh8 hjFkxbkdN58GKbrwzaetd9jIcowhuU8mY6GbqqyPvqTu45QV/vE8S1jJdRYjvpZQ/Vi1 tFxg== X-Gm-Message-State: AOAM5323DuGcIqf84eybTgNwNaBmLFRIm1dBITe99fUyeedd7iS3eE0+ Lt1db7nMq6osf6jVG3wgk91GUOg5qgkXEON1FoI= X-Google-Smtp-Source: ABdhPJytjfrYLhR/YkIRZuga2HFIkk5p0tnp6ucfIOONQ64bELL5wKHf0owxAx88pXm4GHWD8xMr7Fd76mKXGf1kJLg= X-Received: by 2002:ab0:6f08:: with SMTP id r8mr19716818uah.111.1591639839935; Mon, 08 Jun 2020 11:10:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kumar G" Date: Mon, 8 Jun 2020 23:40:28 +0530 Message-ID: Subject: Re: [edk2-devel] Device and driver To: Tomas Pilar Cc: "devel@edk2.groups.io" , nd Content-Type: multipart/alternative; boundary="00000000000045114705a7968733" --00000000000045114705a7968733 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99s 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. The= re > are two important concepts in UEFI that you absolutely need to get > comfortable with. These two are Handles and Protocols. You can think o= f a > protocol as an implementation of a well defined API that allows you to d= o > something. For example, do you want to print a string to screen? There i= s a > SIMPLE_TEXT_OUT_PROTOCOL provided by the platform (hopefully) that allow= s > 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 the= re > 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 instal= led > on only one handle). A ControllerHandle is just a handle =E2=80=93 lets = you install > protocols on it. But importantly, the ControllerHandle contains those > protocols that pertain to a single device. You can=E2=80=99t really do m= uch 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. Handl= es > 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 device= s, > loading and executing files/code, and of course installing/using/removin= g > 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=E2=80=99ll have to get stuck in an= d 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 Lin= ux, > There is clear identification of device and driver, platform code adds t= he > device into system and later OS code binds driver for the same. With UEF= I > 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 examp= le, > 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 sp= i > 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,wher= e > are added spi flash as device in system ? Sorry for basic question, but > UEFI is complicated w.r.t originally i thought Thanks KumarG * > --00000000000045114705a7968733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Tom,
I really appreciate you= r reply,
I didn't get 100% but I went through ~3K pages of UEFI spe= cification.

I understand a bit of protocols and handles now.
Han= dle is an identifier on which some sort of function pointers (protocol in U= EFI world) are installed.

Thing which I am trying to understand, wher= e EFI Boot service's connect controller API says
'connect one or= more drivers to controller'
Basically at code level, where this dif= ferentiation is done, what is controller-handle and what is driver.

I= f 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 controlle= r-handle (C2) (which is a device, connected over this i/o).
And the driv= er needs to install *only* device binding protocol.
During binding , thi= s driver looks for controller (C2) and when found it happily says matched o= r supported.
If the above rule is true, then it=E2=80=99s easy to under= stand the device (aka controller-handle) and the driver.

But in a fe= w places, I am not able to understand what is a controller and what is a dr= iver really.
e.g=C2=A0 =C2=A0
at ArmPlatformPkg/Drivers/LcdGraphicsO= utputDxe/LcdGraphicsOutputDxe.c
By name this looks to be a driver for Lc= d gfx,=C2=A0 but if this is driver then what it has to do with device path.=
Is this driver and controller=C2=A0 managed by the same code ? no clea= r differentiation

For sure, this is new world for me, There will be d= ifferences w,r,t Linux

Thanks
KumarG
=


On Mon, 8 Jun 2020 at 17:04, Tomas Pilar <Tomas.Pilar@arm.com> wrote:

Hi,

=C2=A0

By no means a complete answer but some import= ant points below.

=C2=A0

There are two important concepts in UEFI that= you absolutely need to get comfortable with. These two are Handles and Pro= tocols.

=C2=A0

You can think of a protocol as an implementat= ion 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 p= rovided by the platform (hopefully) that allows you to do that. There might be mu= ltiple 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 cons= umer of the protocol must have access to the header file). You can navigate to MdePkg/Include/Protocol to look at some examples.=

=C2=A0

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 ControllerH= andle is just a handle =E2=80=93 lets you install protocols on it. But impo= rtantly, the ControllerHandle contains those protocols that pertain to a si= ngle device. You can=E2=80=99t 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 ar= e 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 th= e driver can talk to the device. Handles are tracked in an internal databas= e and you can search through them.

=C2=A0

Speaking of which. Most of the stuff you do i= n UEFI is done by protocols, with the main exception being the intrinsic se= rvices such as allocating memory, handling callbacks/events/locks, connecti= ng/disconnecting devices, loading and executing files/code, and of course installing/using= /removing protocols. These functionalities are provided by the BootServices= Table which you really need to read about in the UEFI Spec.

=C2=A0

There really are no quick answers here unfort= unately, you=E2=80=99ll 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 differe= nces.

=C2=A0

Cheers,
Tom

=C2=A0

From: deve= l@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

=

=C2=A0

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 controll= er then
driver for this controller (DXE_DRIVER) could be named as controller handl= e.
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 co= ntroller
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 devi= ce in system ?

Sorry for basic question, but UEFI is complicated w= .r.t originally i thought

Thanks
KumarG

=C2=A0

<= u>

<= /u>
--00000000000045114705a7968733--