On 07/03/2018 04:56 PM, Bin Meng wrote:
Hi Alex,
On Tue, Jul 3, 2018 at 10:32 PM, Alexander Graf <ag...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
