[U-Boot] efi_loader: runtime services implementation broken?

[Alexander Graf]

On 07/03/2018 04:56 PM, Bin Meng wrote:
> Hi Alex,
>
> On Tue, Jul 3, 2018 at 10:32 PM, Alexander Graf <agraf at suse.de> wrote:
>> On 07/03/2018 04:24 PM, Bin Meng wrote:
>>> Hi Alex, Heinrich,
>>>
>>> At present not all interfaces in lib/efi_loader/efi_runtime.c are
>>> declared as __efi_runtime. But only declaring those as __efi_runtime
>>> is not enough. The data these interfaces use should be declared as
>>> __efi_runtime_data too. More worse, any U-Boot APIs called by these
>>> interfaces should be __efi_runtime and __efi_runtime_data
>>> respectively.
>>
>> Correct. This is done for everything right now, no?
> For example, efi_set_virtual_address_map() is not declared as __efi_runtime.

Is that called post exit boot services on x86?

>
>>> Eventually we need mark the RAM where the whole U-Boot image lives as
>>> runtime service code and data and end up leaving whole U-Boot image in
>>> the RAM after kernel boots?
>>
>> Why?
>>
> Unless we track down every APIs called by runtime services and mark
> them correctly as __efi_runtime code/data.

That's the idea, yes. The vector should be quite small as long as we 
don't actually implement / reuse drivers.

>
>>> Right now I am testing booting Linux on Intel Galileo with 'bootefi'
>>> and kernel just hangs during the boot. Initial debugging shows that
>>> kernel crashes when calling runtime service
>>> efi_set_virtual_address_map().
>>
>> Can you please try with my efi-next branch? I added a few patches that allow
>> gcc to put implicit data and code into the runtime section. Without those,
>> you may get constant propagation into a the common .rodata segment for
>> example.
>>
> Still the same.

Ok, maybe the x86 efi stub does things different from the ARM one then.


Alex