On 6/21/19 3:49 AM, AKASHI, Takahiro wrote:
On Thu, Jun 20, 2019 at 11:59:12PM +0200, Heinrich Schuchardt wrote:
Hello Alex,
currently we have two code sections in U-Boot:
* __efi_runtime/__efi_runtime_data (mapped to EFI_RUNTIME_SERVICES_CODE)
* all other code (mapped to EFI_LOADER_DATA by add_u_boot_and_runtime())
All code and data that is not marked as __efi_runtime or
__efi_runtime_data lives in a memory area that the EFI application may
reuse after ExitBootServices().
Code that is marked as __efi_runtime is relocated at SetVirtualMemoryMap().
I wonder in which section the relocation code should live.
It cannot be __efi_runtime or it will mess up itself while relocating.
What's the matter?
I think that you can build relocation code as PIC
if you pass all the necessary global addresses as parameters.
The following routines are to consider: efi_runtime_relocate() and
efi_runtime_detach(). efi_runtime_detach() calls
efi_update_table_header_crc32() which in turn calls crc32(). crc32() is
rather complicated code that I would not like to touch.
We could change the sequence of the calls and call efi_runtime_detach()
before efi_runtime_relocate() and then pass the location of the runtime
table in as a parameter to follow your suggestion. (The runtime table
address is needed, because the pointers are not to be relocated.)
Best regards
Heinrich
-Takahiro Akashi
It cannot be in EFI_LOADER_DATA or it may be overwritten after
ExitBootServices().
If this reasoning is right wouldn't we need a third code section living
in EFI_RUNTIME_SERVICES_CODE but which is excluded from the relocation
during SetVirtualMemoryMap()?
Another option of cause would be to put the whole U-Boot code into
EFI_RUNTIME_SERVICES_CODE which will incur a loss of less than 1 MiB for
the operating system.
Best regards
Heinrich
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
