On 01/15/2018 10:32 AM, Udit Kumar wrote:
Hi Alex
-----Original Message-----
From: Alexander Graf [mailto:[email protected]]
Sent: Monday, January 15, 2018 2:45 PM
To: Udit Kumar <[email protected]>
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
With the command bootefi you can load an executable that adds boottime
or runtime services.
Unfortunatly there are some missing points:
When loading the image the memory category reserved for the image is not
chosen in dependence of the image type. This will cause major trouble
for runtime drivers.
The exit() service does not call the unload function of the
driver/application.
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
U-Boot exposes the network interface as EFI simple network protocol.
iPXE provides TCP and iSCSI on top of the SNP.
It creates a handle and install the a block IO protocol on it.
When ConnectController is called the U-Boot EFI block driver creates the
partitions as children of aforementioned handle and installs the simple
file protocol on the child handles.
See patch
https://lists.denx.de/pipermail/u-boot/2018-January/316708.html
Regards
Heinrich
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,
For a), if I say driver is UEFI and accessing hardware register, will this be
acceptable ?
Alex
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
