On 07/03/2018 04:56 PM, Bin Meng wrote:
Hi Alex,
On Tue, Jul 3, 2018 at 10:32 PM, Alexander Graf agraf@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