[PATCH v2] stm32mp: Reserve OPTEE area in EFI memory map
Patrice CHOTARD
patrice.chotard at foss.st.com
Fri Jun 14 13:53:49 CEST 2024
On 6/14/24 10:43, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/22/24 17:06, Patrice Chotard wrote:
>> Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory")
>> memory region above ram_top is tagged in EFI memory map as
>> EFI_BOOT_SERVICES_DATA.
>> In case of STM32MP1/STM32MP13 platforms, above ram_top, there is one
>> reserved-memory region tagged "no-map" dedicated to OP-TEE :
>> _ addr=de000000 size=2000000 for stm32mp157x-dkx and stm32mp135f-dk
>> _ addr=fe000000 size=2000000 for stm32mp157c-ev1
>>
>> Before booting kernel, EFI memory map is first built, the OPTEE region is
>> tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE
>> is used.
>>
>> Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions()
>> which try to add again the same OPTEE region (addr=de000000 size=2000000
>> in case of stm32mp157x-dkx / stm32mp135f-dk or addr=fe000000 size=2000000
>> in case for stm2mp157c-ev1)
>> but now with LMB_NOMAP tag which produces the following error message :
>>
>> _ for stm32mp157x-dkx / stm32mp135f-dk :
>> "ERROR: reserving fdt memory region failed (addr=de000000 size=2000000 flags=4)"
>>
>> _ for stm32mp157c-ev1 :
>> "ERROR: reserving fdt memory region failed (addr=fe000000 size=2000000 flags=4)"
>>
>> To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark
>> it as reserved.
>>
>> Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
>>
>> ---
>>
>> Changes in v2:
>> _ update commit message by adding information about memory area
>> dedicated for OPTEE for various STM32MP1/STM32MP13 boards.
>>
>> arch/arm/mach-stm32mp/dram_init.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/mach-stm32mp/dram_init.c b/arch/arm/mach-stm32mp/dram_init.c
>> index fb1208fc5d5..f67f54f2ae0 100644
>> --- a/arch/arm/mach-stm32mp/dram_init.c
>> +++ b/arch/arm/mach-stm32mp/dram_init.c
>> @@ -7,6 +7,7 @@
>> #include <common.h>
>> #include <dm.h>
>> +#include <efi_loader.h>
>> #include <image.h>
>> #include <init.h>
>> #include <lmb.h>
>> @@ -75,3 +76,14 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
>> return reg + size;
>> }
>> +
>> +void efi_add_known_memory(void)
>> +{
>> + if (IS_ENABLED(CONFIG_EFI_LOADER))
>> + /*
>> + * Memory over ram_top is reserved to OPTEE.
>> + * Declare to EFI only memory area below ram_top
>> + */
>> + efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base,
>> + EFI_CONVENTIONAL_MEMORY);
>> +}
>
> It seen like a temporary workaround after commit 7b78d6438a2b3
> ("efi_loader: Reserve unaccessible memory") to avoid warnings.
>
> And it is working because in the default memory mapping
> OP-TEE base address == RAM_TOP and the rest of memory is
> used by OP-TEE tagged "no map" (protected by firewall)
>
>
> Reviewed-by: Patrick Delaunay <patrick.delaunay at foss.st.com>
>
> FYI: workaround because the memory above ram_top is
> "already occupied by firmware" =
> and it is OP-TEE for STM32MP2 platform.
>
> For me the LMB type used by EFI in not correct for OP-TEE usage region
> with "no-map" tag in device tree= see boot_fdt_add_mem_rsv_regions()
> for linux DT parsing
>
> and we have no way to indicated this LMB tag= LMB_NOMAP with EFI stack
> (with enum efi_memory_type ?)
>
>
> EFI_BOOT_SERVICES_DATA => doesn't means NOMAP flag for LMB....
> so something is missing in EFI side like EFI_BOOT_NOMAP to be used in board
> implementation of efi_add_known_memory() ?
>
>
> Thanks
> Patrick
>
>
>
>
>
Applied to u-boot-stm32/next
Thanks
Patrice
More information about the U-Boot
mailing list