[U-Boot] UEFI on u-boot

[Heinrich Schuchardt]

On 01/16/2018 06:28 AM, Udit Kumar wrote:
> 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)
> 

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