From mboxrd@z Thu Jan  1 00:00:00 1970
From: AKASHI, Takahiro <takahiro.akashi@linaro.org>
Date: Fri, 21 Jun 2019 10:49:48 +0900
Subject: [U-Boot] efi_loader: detaching runtime
In-Reply-To: <74144bea-7b94-8245-d608-5d076cedddd7@gmx.de>
References: <74144bea-7b94-8245-d608-5d076cedddd7@gmx.de>
Message-ID: <20190621014947.GM6610@linaro.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

-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