[U-Boot] UEFI on u-boot

[Alexander Graf]

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