[U-Boot] UEFI on u-boot

[Udit Kumar]

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)

 
> > 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