[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' <agraf at suse.de>; Heinrich Schuchardt
> <xypron.glpk at gmx.de>
> Cc: u-boot at lists.denx.de
> Subject: RE: UEFI on u-boot
> 
> 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.
>