Hi Atish,
diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c index 7a2dba7dc263..fd97d5b56300 100644 --- a/lib/efi_loader/efi_var_mem.c +++ b/lib/efi_loader/efi_var_mem.c @@ -10,7 +10,7 @@ #include <efi_variable.h> #include <u-boot/crc.h>
-static struct efi_var_file __efi_runtime_data *efi_var_buf; +struct efi_var_file __efi_runtime_data *efi_var_buf;
I am a bit confused how this will work. This means it will reside in GOT which is not mapped in virtual address for Linux. Whenever we try to invoke get_variable service, it will panic. Did we miss a trick in RISC-V ?
Here are the details of the issue we are seeing.
http://lists.infradead.org/pipermail/linux-riscv/2021-January/004200.html
Thanks for reporting this. I can't make too much from the dump itself. Since there's a qemu config for riscv I'll reproduce it.
Long shot but, during LTO, the whole executable is compiled in one go. I think that if in that phase it observes that GOT entries never change it converts them to relative references. I think we are either looking into some compiler differences here or maybe a linker script trick. In any case that's not the right way to go. FWIW I just tested on arm64 and my .got table is empty.
Since this will work if we switch it back to a static pointer, that should be easy to fix and the correct way to do it since we'll be unaffected by compiler/linker changes.
In U-Boot we support 2 ways for runtime variables. One is generic, by using a piece of runtime data memory for the variables and the other one is very arm specific. In both cases though the runtime memory backend is used to expose the variables to the kernel. So that variable can remain static and instead code a function internally to efi_var_mem.c and do the memcpy we need.
I've never tested it on risc-v but apparently I should up more tests for cases like that. I'll send a patch tomorrow once I gather all the objdump info to make sure we aren't missing anything.
Regards
/Ilias