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