[U-Boot] UEFI on u-boot

[Heinrich Schuchardt]

On 01/15/2018 10:32 AM, 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

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