[U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K

[Heinrich Schuchardt]

On 6/13/19 10:23 AM, Mark Kettenis wrote:
>> From: Heinrich Schuchardt <xypron.glpk at gmx.de>
>> Date: Thu, 13 Jun 2019 08:09:17 +0200
>>
>> On 6/13/19 7:48 AM, Stefan Roese wrote:
>>> Added Heinrich to Cc (and use Alex's new address)
>>>
>>> On 11.06.19 13:00, Patrick Wildt wrote:
>>>> The ARM-TF and the optional OP-TEE use the memory region 0x4000000
>>>> to 0x5400000 and should be reserved in the memory map, otherwise the
>>>> OS might wrongly assume that it can use that memory area for itself.
>>>> This has also been done in EDK2 [0].
>>>>
>>>> [0]
>>>> https://github.com/tianocore/edk2-platforms/commit/bf1c4a2cf8024669d1748e78c7e417433f85707e
>>>>
>>>>
>>>> Signed-off-by: Patrick Wildt <patrick at blueri.se>
>>>>
>>>> diff --git a/arch/arm/mach-mvebu/arm64-common.c
>>>> b/arch/arm/mach-mvebu/arm64-common.c
>>>> index aaf7b7c447..7572aad8c9 100644
>>>> --- a/arch/arm/mach-mvebu/arm64-common.c
>>>> +++ b/arch/arm/mach-mvebu/arm64-common.c
>>>> @@ -14,6 +14,7 @@
>>>>   #include <asm/arch/cpu.h>
>>>>   #include <asm/arch/soc.h>
>>>>   #include <asm/armv8/mmu.h>
>>>> +#include <efi_loader.h>
>>>>     DECLARE_GLOBAL_DATA_PTR;
>>>>   @@ -142,5 +143,11 @@ int arch_early_init_r(void)
>>>>       pci_init();
>>>>   #endif
>>>>   +#ifdef CONFIG_EFI_LOADER
>>>> +    /* Reserve trusted SRAM section */
>>>> +    efi_add_memory_map(0x04000000, 0x01400000 >> EFI_PAGE_SHIFT,
>>>> +               EFI_RESERVED_MEMORY_TYPE, false);
>>>> +#endif
>>
>> We already have a reservation via the device tree for a part of this
>> area [0x4000000-0x4200000[ in U-Boot and Linux:
>>
>> cf63dad014bae080445bccbf9cecbe05f2cbed45
>> arm64: dts: marvell: armada-ap806: reserve PSCI area
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc4&id=132ac39cffbcfed80ada38ef0fc6d34d95da7be6
>>
>> As the concerned boards can be booted not only via bootefi but also via
>> booti I suggest to update the device trees in Linux and U-Boot.
>
> But surely the EFI memory map should be correct and not include these
> reserved regions as "free".  Otherwise EFI boot services might hand
> out memory that will crash the system when accessed once we've
> switched out of EL3.  And I don't think the current code adjusts the
> EFI memory based on reservations in the device tree does it?
>

Function efi_carve_out_dt_rsv() in cmd/bootefi.c takes care of adding
reserved regions to the memory map.

Typically U-Boot is running at EL2. Should this not be the case the
bootefi command does the switch.

Best regards

Heinrich