[U-Boot] UEFI on u-boot

[Udit Kumar]

Hi Alex

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Tuesday, January 16, 2018 7:52 PM
> To: Udit Kumar <udit.kumar at nxp.com>; Heinrich Schuchardt
> <xypron.glpk at gmx.de>
> Cc: u-boot at 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.glpk at gmx.de]
> >> Sent: Tuesday, January 16, 2018 12:39 PM
> >> To: Udit Kumar <udit.kumar at nxp.com>; Alexander Graf <agraf at suse.de>
> >> Cc: u-boot at 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:agraf at suse.de]
> >>>> Sent: Monday, January 15, 2018 5:02 PM
> >>>> To: Udit Kumar <udit.kumar at nxp.com>
> >>>> Cc: u-boot at lists.denx.de; Heinrich Schuchardt <xypron.glpk at 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:agraf at suse.de]
> >>>>>> Sent: Monday, January 15, 2018 2:45 PM
> >>>>>> To: Udit Kumar <udit.kumar at 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.

Once UEFI memory map is created, then is this possible to
add new memory in this map , for the moment I am fine 
if using UEFI driver adding this memory into board specific 
ranges and this is reflected back to UEFI map.