Re: [U-Boot] UEFI on u-boot

[Udit Kumar]

Thanks Alex and Heinrich

I guess function efi_add_memory_map will do, what I was looking for 

Regards
Udit 
> -Original Message-
> From: Udit Kumar
> Sent: Sunday, January 21, 2018 4:13 PM
> To: 'Alexander Graf' <ag...@suse.de>; Heinrich Schuchardt
> <xypron.g...@gmx.de>
> Cc: u-boot@lists.denx.de
> Subject: RE: UEFI on u-boot
> 
> Hi Alex
> 
> > -Original Message-
> > From: Alexander Graf [mailto:ag...@suse.de]
> > Sent: Tuesday, January 16, 2018 7:52 PM
> > To: Udit Kumar <udit.ku...@nxp.com>; Heinrich Schuchardt
> > <xypron.g...@gmx.de>
> > Cc: u-boot@lists.denx.de
> > Subject: Re: UEFI on u-boot
> >
> >
> >
> > On 16.01.18 09:35, Udit Kumar wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > >> Sent: Tuesday, January 16, 2018 12:39 PM
> > >> To: Udit Kumar <udit.ku...@nxp.com>; Alexander Graf
> <ag...@suse.de>
> > >> Cc: u-boot@lists.denx.de
> > >> Subject: Re: UEFI on u-boot
> > >>
> > >> On 01/16/2018 06:28 AM, Udit Kumar wrote:
> > >>> Hi Alex,
> > >>>
> > >>>> -Original Message-
> > >>>> From: Alexander Graf [mailto:ag...@suse.de]
> > >>>> Sent: Monday, January 15, 2018 5:02 PM
> > >>>> To: Udit Kumar <udit.ku...@nxp.com>
> > >>>> Cc: u-boot@lists.denx.de; Heinrich Schuchardt
> > >>>> <xypron.g...@gmx.de>
> > >>>> Subject: Re: UEFI on u-boot
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 15.01.18 10:32, Udit Kumar wrote:
> > >>>>> Hi Alex
> > >>>>>
> > >>>>>> -Original Message-
> > >>>>>> From: Alexander Graf [mailto:ag...@suse.de]
> > >>>>>> Sent: Monday, January 15, 2018 2:45 PM
> > >>>>>> To: Udit Kumar <udit.ku...@nxp.com>
> > >>>>>>
> > >>>>>> Hi Udit,
> > >>>>>>
> > >>>>>> On 15.01.18 10:09, Udit Kumar wrote:
> > >>>>>>> Hi Alex,
> > >>>>>>> Hope you are doing great,
> > >>>>>>>
> > >>>>>>> Could you help on UEFI over the u-boot.
> > >>>>>>> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have
> > >>>>>>> plan to add those
> > >>>>>>
> > >>>>>> Right now the model is that all device drivers are implemented
> > >>>>>> by U-Boot and that only exposes their interfaces to EFI
> applications.
> > >>>>>> Implementing DXE in U-Boot would open quite a big can of worms,
> > >>>>>> as it would really only be useful in compilation with PI which
> > >>>>>> is a terrible
> > >>>> interface :).
> > >>>>>
> > >>>>> Ok,
> > >>>>>
> > >>>>>>> 2- If I load  a driver (with bootefi) which install few
> > >>>>>>> protocols, is this ok to do with u-boot
> > >>>>>>
> > >>>>>> It depends on how much the driver does, but in general yes.
> > >>>>>> Heinrich is currently working on making the iPXE iSCSI driver
> > >>>>>> work, so his EFI payload would expose an EFI block device to
> > >>>>>> yet another payload running
> > >>>> after his.
> > >>>>>
> > >>>>> Thanks for this,
> > >>>>> Heinrich,  in  this driver, are you accessing underneath
> > >>>>> hardware register by UEFI-Driver and managing UEFI protocols or
> > >>>>> you are relying on some h/w access exposed by u-boot driver
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>> 3- if you say, 2 is ok then I hope these protocols are kept in
> > >>>>>>> some data base, and this new protocol can be opened by an
> > >>>>>>> application
> > >>>>>>
> > >>>>>> Yes, the protocol database is now global and persistent across
> > >>>>>> bootefi invocations.
> > >>>&

Re: [U-Boot] UEFI on u-boot

[Udit Kumar]

Hi Alex

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Tuesday, January 16, 2018 7:52 PM
> To: Udit Kumar <udit.ku...@nxp.com>; Heinrich Schuchardt
> <xypron.g...@gmx.de>
> Cc: u-boot@lists.denx.de
> Subject: Re: UEFI on u-boot
> 
> 
> 
> On 16.01.18 09:35, Udit Kumar wrote:
> >
> >
> >> -Original Message-
> >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> >> Sent: Tuesday, January 16, 2018 12:39 PM
> >> To: Udit Kumar <udit.ku...@nxp.com>; Alexander Graf <ag...@suse.de>
> >> Cc: u-boot@lists.denx.de
> >> Subject: Re: UEFI on u-boot
> >>
> >> On 01/16/2018 06:28 AM, Udit Kumar wrote:
> >>> Hi Alex,
> >>>
> >>>> -Original Message-
> >>>> From: Alexander Graf [mailto:ag...@suse.de]
> >>>> Sent: Monday, January 15, 2018 5:02 PM
> >>>> To: Udit Kumar <udit.ku...@nxp.com>
> >>>> Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.g...@gmx.de>
> >>>> Subject: Re: UEFI on u-boot
> >>>>
> >>>>
> >>>>
> >>>> On 15.01.18 10:32, Udit Kumar wrote:
> >>>>> Hi Alex
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Alexander Graf [mailto:ag...@suse.de]
> >>>>>> Sent: Monday, January 15, 2018 2:45 PM
> >>>>>> To: Udit Kumar <udit.ku...@nxp.com>
> >>>>>>
> >>>>>> Hi Udit,
> >>>>>>
> >>>>>> On 15.01.18 10:09, Udit Kumar wrote:
> >>>>>>> Hi Alex,
> >>>>>>> Hope you are doing great,
> >>>>>>>
> >>>>>>> Could you help on UEFI over the u-boot.
> >>>>>>> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have
> >>>>>>> plan to add those
> >>>>>>
> >>>>>> Right now the model is that all device drivers are implemented by
> >>>>>> U-Boot and that only exposes their interfaces to EFI applications.
> >>>>>> Implementing DXE in U-Boot would open quite a big can of worms,
> >>>>>> as it would really only be useful in compilation with PI which is
> >>>>>> a terrible
> >>>> interface :).
> >>>>>
> >>>>> Ok,
> >>>>>
> >>>>>>> 2- If I load  a driver (with bootefi) which install few
> >>>>>>> protocols, is this ok to do with u-boot
> >>>>>>
> >>>>>> It depends on how much the driver does, but in general yes.
> >>>>>> Heinrich is currently working on making the iPXE iSCSI driver
> >>>>>> work, so his EFI payload would expose an EFI block device to yet
> >>>>>> another payload running
> >>>> after his.
> >>>>>
> >>>>> Thanks for this,
> >>>>> Heinrich,  in  this driver, are you accessing underneath hardware
> >>>>> register by UEFI-Driver and managing UEFI protocols or you are
> >>>>> relying on some h/w access exposed by u-boot driver
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> 3- if you say, 2 is ok then I hope these protocols are kept in
> >>>>>>> some data base, and this new protocol can be opened by an
> >>>>>>> application
> >>>>>>
> >>>>>> Yes, the protocol database is now global and persistent across
> >>>>>> bootefi invocations.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>>>> 4- if there is some known limitation, like we cannot run
> >>>>>>> DXE_driver etc
> >>>>>>
> >>>>>> What exactly are you trying to do? With the U-Boot UEFI
> >>>>>> implementation we're trying to find a sweet spot between
> >>>>>> implementing as much as makes sense, but not the whole UEFI
> >>>>>> world, as that would just bloat the code needlessly.
> >>>>>
> >>>>> I am trying to add a driver (DXE by definition) which
> >>>>> a) Access the hardware registers. (I said DXE could due to
> >>>>> hardware
> >>>>> re

Re: [U-Boot] UEFI on u-boot

[Alexander Graf]

On 16.01.18 09:35, Udit Kumar wrote:
> 
> 
>> -Original Message-
>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
>> Sent: Tuesday, January 16, 2018 12:39 PM
>> To: Udit Kumar <udit.ku...@nxp.com>; Alexander Graf <ag...@suse.de>
>> Cc: u-boot@lists.denx.de
>> Subject: Re: UEFI on u-boot
>>
>> On 01/16/2018 06:28 AM, Udit Kumar wrote:
>>> Hi Alex,
>>>
>>>> -Original Message-
>>>> From: Alexander Graf [mailto:ag...@suse.de]
>>>> Sent: Monday, January 15, 2018 5:02 PM
>>>> To: Udit Kumar <udit.ku...@nxp.com>
>>>> Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.g...@gmx.de>
>>>> Subject: Re: UEFI on u-boot
>>>>
>>>>
>>>>
>>>> On 15.01.18 10:32, Udit Kumar wrote:
>>>>> Hi Alex
>>>>>
>>>>>> -Original Message-
>>>>>> From: Alexander Graf [mailto:ag...@suse.de]
>>>>>> Sent: Monday, January 15, 2018 2:45 PM
>>>>>> To: Udit Kumar <udit.ku...@nxp.com>
>>>>>>
>>>>>> Hi Udit,
>>>>>>
>>>>>> On 15.01.18 10:09, Udit Kumar wrote:
>>>>>>> Hi Alex,
>>>>>>> Hope you are doing great,
>>>>>>>
>>>>>>> Could you help on UEFI over the u-boot.
>>>>>>> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan
>>>>>>> to add those
>>>>>>
>>>>>> Right now the model is that all device drivers are implemented by
>>>>>> U-Boot and that only exposes their interfaces to EFI applications.
>>>>>> Implementing DXE in U-Boot would open quite a big can of worms, as
>>>>>> it would really only be useful in compilation with PI which is a
>>>>>> terrible
>>>> interface :).
>>>>>
>>>>> Ok,
>>>>>
>>>>>>> 2- If I load  a driver (with bootefi) which install few protocols,
>>>>>>> is this ok to do with u-boot
>>>>>>
>>>>>> It depends on how much the driver does, but in general yes.
>>>>>> Heinrich is currently working on making the iPXE iSCSI driver work,
>>>>>> so his EFI payload would expose an EFI block device to yet another
>>>>>> payload running
>>>> after his.
>>>>>
>>>>> Thanks for this,
>>>>> Heinrich,  in  this driver, are you accessing underneath hardware
>>>>> register by UEFI-Driver and managing UEFI protocols or you are
>>>>> relying on some h/w access exposed by u-boot driver
>>>>>
>>>>>
>>>>>
>>>>>>> 3- if you say, 2 is ok then I hope these protocols are kept in
>>>>>>> some data base, and this new protocol can be opened by an
>>>>>>> application
>>>>>>
>>>>>> Yes, the protocol database is now global and persistent across
>>>>>> bootefi invocations.
>>>>>
>>>>> Thanks
>>>>>
>>>>>>> 4- if there is some known limitation, like we cannot run
>>>>>>> DXE_driver etc
>>>>>>
>>>>>> What exactly are you trying to do? With the U-Boot UEFI
>>>>>> implementation we're trying to find a sweet spot between
>>>>>> implementing as much as makes sense, but not the whole UEFI world,
>>>>>> as that would just bloat the code needlessly.
>>>>>
>>>>> I am trying to add a driver (DXE by definition) which
>>>>> a) Access the hardware registers. (I said DXE could due to hardware
>>>>> registers)
>>>>> b) Update memory map as well (AddMemorySpace call)
>>>>> c) Finally it export a protocol, which could be used by its test
>> application.
>>>>>
>>>>> For b) I am not able to find function call,
>>>>
>>>> What exactly beyond efi_allocate_pages() do you need? The EFI memory
>>>> map is really only used as data source for EFI applications. The
>>>> actual 1:1 U- Boot map is not influenced by it.
>>>
>>> I am exploring possibility,  If a driver discover memory  and want to add
>> this in system.
>>> For example,  at build time 1Gb is reserved for a given driver but at
>>> run-time driver is told to use little less memory say 512Mb and this
>>> driver can return back 512Mb to system (In UEFI call is being
>>> AddMemorySpace under DXE services)
>>>
>>
>> The UEFI specification defines different memory types which can be used
>> when allocating memory. Whether a memory type can be used by an UEFI OS
>> loader or an OS determines on the boottime exit event. Many classes of
>> memory become generally available after exiting the boottime. This is
>> decribed in chapter "7.2 Memory Allocation Services" of UEFI spec 2.7.
> 
> For allocation this is perfectly fine. How a driver can update the memory 
> map. 

Any allocation simply overrides the memory map, so if you explicitly
allocate CONVENTIONAL_MEMORY at an address that was declared as MMIO
space before, the efi memory map will get updated accordingly.

> Let me ask this in other way, when we create UEFI memory map in u-boot 
> How we are creating this ? using memory node of device tree or some other 
> way.

It uses board specific knowledge of memory ranges.


Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UEFI on u-boot

[Udit Kumar]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, January 16, 2018 12:39 PM
> To: Udit Kumar <udit.ku...@nxp.com>; Alexander Graf <ag...@suse.de>
> Cc: u-boot@lists.denx.de
> Subject: Re: UEFI on u-boot
> 
> On 01/16/2018 06:28 AM, Udit Kumar wrote:
> > Hi Alex,
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Monday, January 15, 2018 5:02 PM
> >> To: Udit Kumar <udit.ku...@nxp.com>
> >> Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.g...@gmx.de>
> >> Subject: Re: UEFI on u-boot
> >>
> >>
> >>
> >> On 15.01.18 10:32, Udit Kumar wrote:
> >>> Hi Alex
> >>>
> >>>> -Original Message-
> >>>> From: Alexander Graf [mailto:ag...@suse.de]
> >>>> Sent: Monday, January 15, 2018 2:45 PM
> >>>> To: Udit Kumar <udit.ku...@nxp.com>
> >>>>
> >>>> Hi Udit,
> >>>>
> >>>> On 15.01.18 10:09, Udit Kumar wrote:
> >>>>> Hi Alex,
> >>>>> Hope you are doing great,
> >>>>>
> >>>>> Could you help on UEFI over the u-boot.
> >>>>> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan
> >>>>> to add those
> >>>>
> >>>> Right now the model is that all device drivers are implemented by
> >>>> U-Boot and that only exposes their interfaces to EFI applications.
> >>>> Implementing DXE in U-Boot would open quite a big can of worms, as
> >>>> it would really only be useful in compilation with PI which is a
> >>>> terrible
> >> interface :).
> >>>
> >>> Ok,
> >>>
> >>>>> 2- If I load  a driver (with bootefi) which install few protocols,
> >>>>> is this ok to do with u-boot
> >>>>
> >>>> It depends on how much the driver does, but in general yes.
> >>>> Heinrich is currently working on making the iPXE iSCSI driver work,
> >>>> so his EFI payload would expose an EFI block device to yet another
> >>>> payload running
> >> after his.
> >>>
> >>> Thanks for this,
> >>> Heinrich,  in  this driver, are you accessing underneath hardware
> >>> register by UEFI-Driver and managing UEFI protocols or you are
> >>> relying on some h/w access exposed by u-boot driver
> >>>
> >>>
> >>>
> >>>>> 3- if you say, 2 is ok then I hope these protocols are kept in
> >>>>> some data base, and this new protocol can be opened by an
> >>>>> application
> >>>>
> >>>> Yes, the protocol database is now global and persistent across
> >>>> bootefi invocations.
> >>>
> >>> Thanks
> >>>
> >>>>> 4- if there is some known limitation, like we cannot run
> >>>>> DXE_driver etc
> >>>>
> >>>> What exactly are you trying to do? With the U-Boot UEFI
> >>>> implementation we're trying to find a sweet spot between
> >>>> implementing as much as makes sense, but not the whole UEFI world,
> >>>> as that would just bloat the code needlessly.
> >>>
> >>> I am trying to add a driver (DXE by definition) which
> >>> a) Access the hardware registers. (I said DXE could due to hardware
> >>> registers)
> >>> b) Update memory map as well (AddMemorySpace call)
> >>> c) Finally it export a protocol, which could be used by its test
> application.
> >>>
> >>> For b) I am not able to find function call,
> >>
> >> What exactly beyond efi_allocate_pages() do you need? The EFI memory
> >> map is really only used as data source for EFI applications. The
> >> actual 1:1 U- Boot map is not influenced by it.
> >
> > I am exploring possibility,  If a driver discover memory  and want to add
> this in system.
> > For example,  at build time 1Gb is reserved for a given driver but at
> > run-time driver is told to use little less memory say 512Mb and this
> > driver can return back 512Mb to system (In UEFI call is being
> > AddMemorySpace under DXE services)
> >
> 
> The UEFI specification defines different memory types which can be used
> when allocating memory. Whether a memory type can be used by an UEFI OS
> loader or an OS determines on the boottime exit event. Many classes of
> memory become generally available after exiting the boottime. This is
> decribed in chapter "7.2 Memory Allocation Services" of UEFI spec 2.7.

For allocation this is perfectly fine. How a driver can update the memory 
map. 
Let me ask this in other way, when we create UEFI memory map in u-boot 
How we are creating this ? using memory node of device tree or some other 
way.

Thanks
Udit 



> Regards
> 
> Heinrich
> 
> >
> >>> For a), if I say driver is UEFI and accessing hardware register,
> >>> will this be
> >> acceptable ?
> >>
> >> Yes, definitely. All you'd need to do is set the efi application type
> >> to application, then register your protocols and access hardware
> >> registers using direct MMIO access to their respective regions.
> >
> > Thanks
> >
> >>
> >> Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UEFI on u-boot

[Udit Kumar]

Thanks Heinrich

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, January 16, 2018 2:55 AM
> To: Udit Kumar <udit.ku...@nxp.com>; Alexander Graf <ag...@suse.de>
> Cc: u-boot@lists.denx.de
> Subject: Re: UEFI on u-boot
> 
> 
> 
> On 01/15/2018 10:32 AM, Udit Kumar wrote:
> > Hi Alex
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Monday, January 15, 2018 2:45 PM
> >> To: Udit Kumar <udit.ku...@nxp.com>
> >>
> >> Hi Udit,
> >>
> >> On 15.01.18 10:09, Udit Kumar wrote:
> >>> Hi Alex,
> >>> Hope you are doing great,
> >>>
> >>> Could you help on UEFI over the u-boot.
> >>> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan to
> >>> add those
> >>
> >> Right now the model is that all device drivers are implemented by
> >> U-Boot and that only exposes their interfaces to EFI applications.
> >> Implementing DXE in U-Boot would open quite a big can of worms, as it
> >> would really only be useful in compilation with PI which is a terrible
> interface :).
> >
> > Ok,
> >
> >>> 2- If I load  a driver (with bootefi) which install few protocols,
> >>> is this ok to do with u-boot
> 
> With the command bootefi you can load an executable that adds boottime
> or runtime services.
> 
> Unfortunatly there are some missing points:
> 
> When loading the image the memory category reserved for the image is not
> chosen in dependence of the image type. This will cause major trouble for
> runtime drivers.
> The exit() service does not call the unload function of the 
> driver/application.

Thanks for warning, for the moment I am ok with simple driver 
 
> >>
> >> It depends on how much the driver does, but in general yes. Heinrich
> >> is currently working on making the iPXE iSCSI driver work, so his EFI
> >> payload would expose an EFI block device to yet another payload running
> after his.
> >
> > Thanks for this,
> > Heinrich,  in  this driver, are you accessing underneath hardware
> > register by UEFI-Driver and managing UEFI protocols or you are relying
> > on some h/w access exposed by u-boot driver
> >
> 
> U-Boot exposes the network interface as EFI simple network protocol.
> iPXE provides TCP and iSCSI on top of the SNP.
> It creates a handle and install the a block IO protocol on it.
> When ConnectController is called the U-Boot EFI block driver creates the
> partitions as children of aforementioned handle and installs the simple file
> protocol on the child handles.
> 
> See patch
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> denx.de%2Fpipermail%2Fu-boot%2F2018-
> January%2F316708.html=02%7C01%7Cudit.kumar%40nxp.com%7Cc19b
> 8ec63abb4ee7ff1908d55c5e7be8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C636516483235326220=wUx1fErZM2G6xjB7Aq89ntqs5bRGt
> TXZKKcfLgWef4M%3D=0

Thanks, you rely on u-boot exports. Alex answered in previous post
as in UEFI driver MMIO read/write is allowed 
 
> Regards
> 
> Heinrich
> 
> >
> >
> >>> 3- if you say, 2 is ok then I hope these protocols are kept in some
> >>> data base, and this new protocol can be opened by an application
> >>
> >> Yes, the protocol database is now global and persistent across
> >> bootefi invocations.
> >
> > Thanks
> >
> >>> 4- if there is some known limitation, like we cannot run DXE_driver
> >>> etc
> >>
> >> What exactly are you trying to do? With the U-Boot UEFI
> >> implementation we're trying to find a sweet spot between implementing
> >> as much as makes sense, but not the whole UEFI world, as that would
> >> just bloat the code needlessly.
> >
> > I am trying to add a driver (DXE by definition) which
> > a) Access the hardware registers. (I said DXE could due to hardware
> > registers)
> > b) Update memory map as well (AddMemorySpace call)
> > c) Finally it export a protocol, which could be used by its test 
> > application.
> >
> > For b) I am not able to find function call, For a), if I say driver is
> > UEFI and accessing hardware register, will this be acceptable ?
> >
> >>
> >> Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UEFI on u-boot

[Udit Kumar]

Hi Alex,

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, January 15, 2018 5:02 PM
> To: Udit Kumar <udit.ku...@nxp.com>
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.g...@gmx.de>
> Subject: Re: UEFI on u-boot
> 
> 
> 
> On 15.01.18 10:32, Udit Kumar wrote:
> > Hi Alex
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Monday, January 15, 2018 2:45 PM
> >> To: Udit Kumar <udit.ku...@nxp.com>
> >>
> >> Hi Udit,
> >>
> >> On 15.01.18 10:09, Udit Kumar wrote:
> >>> Hi Alex,
> >>> Hope you are doing great,
> >>>
> >>> Could you help on UEFI over the u-boot.
> >>> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan to
> >>> add those
> >>
> >> Right now the model is that all device drivers are implemented by
> >> U-Boot and that only exposes their interfaces to EFI applications.
> >> Implementing DXE in U-Boot would open quite a big can of worms, as it
> >> would really only be useful in compilation with PI which is a terrible
> interface :).
> >
> > Ok,
> >
> >>> 2- If I load  a driver (with bootefi) which install few protocols,
> >>> is this ok to do with u-boot
> >>
> >> It depends on how much the driver does, but in general yes. Heinrich
> >> is currently working on making the iPXE iSCSI driver work, so his EFI
> >> payload would expose an EFI block device to yet another payload running
> after his.
> >
> > Thanks for this,
> > Heinrich,  in  this driver, are you accessing underneath hardware
> > register by UEFI-Driver and managing UEFI protocols or you are relying
> > on some h/w access exposed by u-boot driver
> >
> >
> >
> >>> 3- if you say, 2 is ok then I hope these protocols are kept in some
> >>> data base, and this new protocol can be opened by an application
> >>
> >> Yes, the protocol database is now global and persistent across
> >> bootefi invocations.
> >
> > Thanks
> >
> >>> 4- if there is some known limitation, like we cannot run DXE_driver
> >>> etc
> >>
> >> What exactly are you trying to do? With the U-Boot UEFI
> >> implementation we're trying to find a sweet spot between implementing
> >> as much as makes sense, but not the whole UEFI world, as that would
> >> just bloat the code needlessly.
> >
> > I am trying to add a driver (DXE by definition) which
> > a) Access the hardware registers. (I said DXE could due to hardware
> > registers)
> > b) Update memory map as well (AddMemorySpace call)
> > c) Finally it export a protocol, which could be used by its test 
> > application.
> >
> > For b) I am not able to find function call,
> 
> What exactly beyond efi_allocate_pages() do you need? The EFI memory
> map is really only used as data source for EFI applications. The actual 1:1 U-
> Boot map is not influenced by it.

I am exploring possibility,  If a driver discover memory  and want to add this 
in system. 
For example,  at build time 1Gb is reserved for a given driver but at run-time 
driver is told to use little less memory say 512Mb and this driver can return 
back
512Mb to system (In UEFI call is being AddMemorySpace under DXE services)

 
> > For a), if I say driver is UEFI and accessing hardware register, will this 
> > be
> acceptable ?
> 
> Yes, definitely. All you'd need to do is set the efi application type to
> application, then register your protocols and access hardware registers using
> direct MMIO access to their respective regions.

Thanks
 
> 
> Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UEFI on u-boot

[Heinrich Schuchardt]

On 01/16/2018 06:28 AM, Udit Kumar wrote:

Hi Alex,


-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, January 15, 2018 5:02 PM
To: Udit Kumar <udit.ku...@nxp.com>
Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.g...@gmx.de>
Subject: Re: UEFI on u-boot



On 15.01.18 10:32, Udit Kumar wrote:

Hi Alex


-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, January 15, 2018 2:45 PM
To: Udit Kumar <udit.ku...@nxp.com>

Hi Udit,

On 15.01.18 10:09, Udit Kumar wrote:

Hi Alex,
Hope you are doing great,

Could you help on UEFI over the u-boot.
1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan to
add those


Right now the model is that all device drivers are implemented by
U-Boot and that only exposes their interfaces to EFI applications.
Implementing DXE in U-Boot would open quite a big can of worms, as it
would really only be useful in compilation with PI which is a terrible

interface :).


Ok,


2- If I load  a driver (with bootefi) which install few protocols,
is this ok to do with u-boot


It depends on how much the driver does, but in general yes. Heinrich
is currently working on making the iPXE iSCSI driver work, so his EFI
payload would expose an EFI block device to yet another payload running

after his.


Thanks for this,
Heinrich,  in  this driver, are you accessing underneath hardware
register by UEFI-Driver and managing UEFI protocols or you are relying
on some h/w access exposed by u-boot driver




3- if you say, 2 is ok then I hope these protocols are kept in some
data base, and this new protocol can be opened by an application


Yes, the protocol database is now global and persistent across
bootefi invocations.


Thanks


4- if there is some known limitation, like we cannot run DXE_driver
etc


What exactly are you trying to do? With the U-Boot UEFI
implementation we're trying to find a sweet spot between implementing
as much as makes sense, but not the whole UEFI world, as that would
just bloat the code needlessly.


I am trying to add a driver (DXE by definition) which
a) Access the hardware registers. (I said DXE could due to hardware
registers)
b) Update memory map as well (AddMemorySpace call)
c) Finally it export a protocol, which could be used by its test application.

For b) I am not able to find function call,


What exactly beyond efi_allocate_pages() do you need? The EFI memory
map is really only used as data source for EFI applications. The actual 1:1 U-
Boot map is not influenced by it.


I am exploring possibility,  If a driver discover memory  and want to add this 
in system.
For example,  at build time 1Gb is reserved for a given driver but at run-time
driver is told to use little less memory say 512Mb and this driver can return 
back
512Mb to system (In UEFI call is being AddMemorySpace under DXE services)



The UEFI specification defines different memory types which can be used 
when allocating memory. Whether a memory type can be used by an UEFI OS 
loader or an OS determines on the boottime exit event. Many classes of 
memory become generally available after exiting the boottime. This is 
decribed in chapter "7.2 Memory Allocation Services" of UEFI spec 2.7.


Regards

Heinrich

  

For a), if I say driver is UEFI and accessing hardware register, will this be

acceptable ?

Yes, definitely. All you'd need to do is set the efi application type to
application, then register your protocols and access hardware registers using
direct MMIO access to their respective regions.


Thanks
  


Alex


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UEFI on u-boot

[Udit Kumar]

Hi Alex

> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, January 15, 2018 2:45 PM
> To: Udit Kumar 
> 
> Hi Udit,
> 
> On 15.01.18 10:09, Udit Kumar wrote:
> > Hi Alex,
> > Hope you are doing great,
> >
> > Could you help on UEFI over the u-boot.
> > 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan to
> > add those
> 
> Right now the model is that all device drivers are implemented by U-Boot
> and that only exposes their interfaces to EFI applications. Implementing DXE
> in U-Boot would open quite a big can of worms, as it would really only be
> useful in compilation with PI which is a terrible interface :).

Ok, 
 
> > 2- If I load  a driver (with bootefi) which install few protocols,  is
> > this ok to do with u-boot
> 
> It depends on how much the driver does, but in general yes. Heinrich is
> currently working on making the iPXE iSCSI driver work, so his EFI payload
> would expose an EFI block device to yet another payload running after his.

Thanks for this, 
Heinrich,  in  this driver, are you accessing underneath hardware register 
by UEFI-Driver and managing UEFI protocols
or you are relying on some h/w access exposed by u-boot driver


 
> > 3- if you say, 2 is ok then I hope these protocols are kept in some
> > data base, and this new protocol can be opened by an application
> 
> Yes, the protocol database is now global and persistent across bootefi
> invocations.

Thanks 
 
> > 4- if there is some known limitation, like we cannot run DXE_driver
> > etc
> 
> What exactly are you trying to do? With the U-Boot UEFI implementation
> we're trying to find a sweet spot between implementing as much as makes
> sense, but not the whole UEFI world, as that would just bloat the code
> needlessly.

I am trying to add a driver (DXE by definition) which 
a) Access the hardware registers. (I said DXE could due to hardware registers)
b) Update memory map as well (AddMemorySpace call)
c) Finally it export a protocol, which could be used by its test application. 

For b) I am not able to find function call, 
For a), if I say driver is UEFI and accessing hardware register, will this be 
acceptable ?  
 
> 
> Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UEFI on u-boot

[Heinrich Schuchardt]

On 01/15/2018 10:32 AM, Udit Kumar wrote:

Hi Alex


-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, January 15, 2018 2:45 PM
To: Udit Kumar 

Hi Udit,

On 15.01.18 10:09, Udit Kumar wrote:

Hi Alex,
Hope you are doing great,

Could you help on UEFI over the u-boot.
1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan to
add those


Right now the model is that all device drivers are implemented by U-Boot
and that only exposes their interfaces to EFI applications. Implementing DXE
in U-Boot would open quite a big can of worms, as it would really only be
useful in compilation with PI which is a terrible interface :).


Ok,
  

2- If I load  a driver (with bootefi) which install few protocols,  is
this ok to do with u-boot


With the command bootefi you can load an executable that adds boottime 
or runtime services.


Unfortunatly there are some missing points:

When loading the image the memory category reserved for the image is not 
chosen in dependence of the image type. This will cause major trouble 
for runtime drivers.


The exit() service does not call the unload function of the 
driver/application.




It depends on how much the driver does, but in general yes. Heinrich is
currently working on making the iPXE iSCSI driver work, so his EFI payload
would expose an EFI block device to yet another payload running after his.


Thanks for this,
Heinrich,  in  this driver, are you accessing underneath hardware register
by UEFI-Driver and managing UEFI protocols
or you are relying on some h/w access exposed by u-boot driver



U-Boot exposes the network interface as EFI simple network protocol.
iPXE provides TCP and iSCSI on top of the SNP.
It creates a handle and install the a block IO protocol on it.
When ConnectController is called the U-Boot EFI block driver creates the 
partitions as children of aforementioned handle and installs the simple 
file protocol on the child handles.


See patch
https://lists.denx.de/pipermail/u-boot/2018-January/316708.html

Regards

Heinrich



  

3- if you say, 2 is ok then I hope these protocols are kept in some
data base, and this new protocol can be opened by an application


Yes, the protocol database is now global and persistent across bootefi
invocations.


Thanks
  

4- if there is some known limitation, like we cannot run DXE_driver
etc


What exactly are you trying to do? With the U-Boot UEFI implementation
we're trying to find a sweet spot between implementing as much as makes
sense, but not the whole UEFI world, as that would just bloat the code
needlessly.


I am trying to add a driver (DXE by definition) which
a) Access the hardware registers. (I said DXE could due to hardware registers)
b) Update memory map as well (AddMemorySpace call)
c) Finally it export a protocol, which could be used by its test application.

For b) I am not able to find function call,
For a), if I say driver is UEFI and accessing hardware register, will this be 
acceptable ?
  


Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UEFI on u-boot

[Alexander Graf]

On 15.01.18 10:32, Udit Kumar wrote:
> Hi Alex
> 
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Monday, January 15, 2018 2:45 PM
>> To: Udit Kumar 
>>
>> Hi Udit,
>>
>> On 15.01.18 10:09, Udit Kumar wrote:
>>> Hi Alex,
>>> Hope you are doing great,
>>>
>>> Could you help on UEFI over the u-boot.
>>> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan to
>>> add those
>>
>> Right now the model is that all device drivers are implemented by U-Boot
>> and that only exposes their interfaces to EFI applications. Implementing DXE
>> in U-Boot would open quite a big can of worms, as it would really only be
>> useful in compilation with PI which is a terrible interface :).
> 
> Ok, 
>  
>>> 2- If I load  a driver (with bootefi) which install few protocols,  is
>>> this ok to do with u-boot
>>
>> It depends on how much the driver does, but in general yes. Heinrich is
>> currently working on making the iPXE iSCSI driver work, so his EFI payload
>> would expose an EFI block device to yet another payload running after his.
> 
> Thanks for this, 
> Heinrich,  in  this driver, are you accessing underneath hardware register 
> by UEFI-Driver and managing UEFI protocols
> or you are relying on some h/w access exposed by u-boot driver
> 
> 
>  
>>> 3- if you say, 2 is ok then I hope these protocols are kept in some
>>> data base, and this new protocol can be opened by an application
>>
>> Yes, the protocol database is now global and persistent across bootefi
>> invocations.
> 
> Thanks 
>  
>>> 4- if there is some known limitation, like we cannot run DXE_driver
>>> etc
>>
>> What exactly are you trying to do? With the U-Boot UEFI implementation
>> we're trying to find a sweet spot between implementing as much as makes
>> sense, but not the whole UEFI world, as that would just bloat the code
>> needlessly.
> 
> I am trying to add a driver (DXE by definition) which 
> a) Access the hardware registers. (I said DXE could due to hardware registers)
> b) Update memory map as well (AddMemorySpace call)
> c) Finally it export a protocol, which could be used by its test application. 
> 
> For b) I am not able to find function call, 

What exactly beyond efi_allocate_pages() do you need? The EFI memory map
is really only used as data source for EFI applications. The actual 1:1
U-Boot map is not influenced by it.

> For a), if I say driver is UEFI and accessing hardware register, will this be 
> acceptable ?  

Yes, definitely. All you'd need to do is set the efi application type to
application, then register your protocols and access hardware registers
using direct MMIO access to their respective regions.


Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] UEFI on u-boot

[Alexander Graf]

Hi Udit,

On 15.01.18 10:09, Udit Kumar wrote:
> Hi Alex, 
> Hope you are doing great, 
> 
> Could you help on UEFI over the u-boot.
> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have plan to add 
> those 

Right now the model is that all device drivers are implemented by U-Boot
and that only exposes their interfaces to EFI applications. Implementing
DXE in U-Boot would open quite a big can of worms, as it would really
only be useful in compilation with PI which is a terrible interface :).

> 2- If I load  a driver (with bootefi) which install few protocols,  is this 
> ok to do with u-boot

It depends on how much the driver does, but in general yes. Heinrich is
currently working on making the iPXE iSCSI driver work, so his EFI
payload would expose an EFI block device to yet another payload running
after his.

> 3- if you say, 2 is ok then I hope these protocols are kept in some data 
> base, and this new protocol can be opened by an application 

Yes, the protocol database is now global and persistent across bootefi
invocations.

> 4- if there is some known limitation, like we cannot run DXE_driver  etc

What exactly are you trying to do? With the U-Boot UEFI implementation
we're trying to find a sweet spot between implementing as much as makes
sense, but not the whole UEFI world, as that would just bloat the code
needlessly.


Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot