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
