On 18/10/2016 17:46, york sun wrote:
> On 10/17/2016 02:11 AM, Alexander Graf wrote:
>>
>>
>> On 15.10.16 18:58, york sun wrote:
>>> On 10/15/2016 03:03 AM, Alexander Graf wrote:
>>>> Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
>>>> reserve some memory that U-Boot is aware of as secure.
>>>>
>>>> For those systems, mask out that secure memory in the EFI memory map,
>>>> as it's not usable from EL2 or EL1.
>>>>
>>>> Signed-off-by: Alexander Graf <ag...@suse.de>
>>>>
>>>> ---
>>>>
>>>> v4 -> v5:
>>>>
>>>> - Use gd->arch.secure_ram
>>>> ---
>>>> lib/efi_loader/efi_memory.c | 15 +++++++++++++++
>>>> 1 file changed, 15 insertions(+)
>>>>
>>>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>>>> index 95aa590..4966e48 100644
>>>> --- a/lib/efi_loader/efi_memory.c
>>>> +++ b/lib/efi_loader/efi_memory.c
>>>> @@ -474,5 +474,20 @@ int efi_memory_init(void)
>>>> efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
>>>> #endif
>>>>
>>>> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
>>>> + /* Declare secure ram as reserved */
>>>> + if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
>>>> + uint64_t secure_start = gd->arch.secure_ram;
>>>> + uint64_t secure_pages = CONFIG_SYS_MEM_RESERVE_SECURE;
>>>> +
>>>> + secure_start &= MEM_RESERVE_SECURE_ADDR_MASK;
>>>> + secure_start &= ~EFI_PAGE_MASK;
>>>> + secure_pages = (secure_pages + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
>>>> +
>>>> + efi_add_memory_map(secure_start, secure_pages,
>>>> + EFI_RESERVED_MEMORY_TYPE, false);
>>>> + }
>>>> +#endif
>>>> +
>>>> return 0;
>>>> }
>>>>
>>>
>>> Alex,
>>>
>>> Do you see any issue without this patch? The secure memory is not
>>> visible to OS. gd->ram_size is reduced to hide the secure memory.
>>
>> We're building the memory map out of gd->bd->bi_dram rather than
>> ram_size, because it's perfectly reasonable for systems to have memory
>> holes.
>>
>> So even if we're adjusting gd->ram_size, the OS will still see secure
>> memory. In fact, doesn't bootm do that as well?
>>
>> arch/arm/lib/bootm-fdt.c: ret = fdt_fixup_memory_banks(blob,
>> start, size, CONFIG_NR_DRAM_BANKS);
>>
>> On armv7, arch_fixup_fdt() removes the secure memory region from the
>> edge of a memory bank. But on armv8 I don't see anything like it?
>>
>
> Alex,
>
> For ARMv8, our SoCs have several regions. Depends on the board
> implementation, the memory may end up in different banks. See
> board/freescale/ls2080ardb/ddr.c for example. The secure ram is already
> carved out.
Ok, I think you're right. I'll remove this patch. See below for
"lsefimmap" output from grub2 with and without the patch applied.
Alex
With patch:
Type Physical start - end #Pages Size Attributes
MMIO 0000000001e60000-0000000001e60fff 00000001 4KiB RT
conv-mem 0000000080000000-0000000087ffffff 00008000 128MiB WB
BS-data 0000000088000000-0000000088003fff 00000004 16KiB WB
conv-mem 0000000088006000-00000000fab33fff 00072b2e 1879224KiB WB
RT-data 00000000fab34000-00000000fab34fff 00000001 4KiB RT WB
ldr-data 00000000fab35000-00000000fad0dfff 000001d9 1892KiB WB
ldr-data 00000000fad0e000-00000000fed0dfff 00004000 64MiB WB
ldr-data 00000000fed0e000-00000000fff14fff 00001207 18460KiB WB
reserved 00000000fff156b0-00000000fff166af 00000001 4KiB WB
ldr-data 00000000fff166b0-00000000fffa46af 0000008e 568KiB WB
RT-code 00000000fffa5000-00000000fffa5fff 00000001 4KiB RT WB
ldr-data 00000000fffa6000-00000000ffffffff 0000005a 360KiB WB
reserved 0000006000000000-00000060ffffffff 00100000 4GiB WB
conv-mem 0000008080000000-000000835bff9fff 002dbffa 11993064KiB WB
ldr-data 000000835bffa000-00000083bfff9fff 00064000 1600MiB WB
conv-mem 00000083bfffa000-00000083bfffffff 00000006 24KiB WB
reserved 00000083ffe00000-00000083ffffffff 00000200 2MiB WB
Without patch:
Type Physical start - end #Pages Size Attributes
MMIO 0000000001e60000-0000000001e60fff 00000001 4KiB RT
conv-mem 0000000080000000-0000000087ffffff 00008000 128MiB WB
BS-data 0000000088000000-0000000088003fff 00000004 16KiB WB
conv-mem 0000000088006000-00000000fab34fff 00072b2f 1879228KiB WB
RT-data 00000000fab35000-00000000fab35fff 00000001 4KiB RT WB
ldr-data 00000000fab36000-00000000fad0efff 000001d9 1892KiB WB
ldr-data 00000000fad0f000-00000000fed0efff 00004000 64MiB WB
ldr-data 00000000fed0f000-00000000fff15fff 00001207 18460KiB WB
reserved 00000000fff166b0-00000000fff176af 00000001 4KiB WB
ldr-data 00000000fff176b0-00000000fffa46af 0000008d 564KiB WB
RT-code 00000000fffa5000-00000000fffa5fff 00000001 4KiB RT WB
ldr-data 00000000fffa6000-00000000ffffffff 0000005a 360KiB WB
reserved 0000006000000000-00000060ffffffff 00100000 4GiB WB
conv-mem 0000008080000000-000000835bff9fff 002dbffa 11993064KiB WB
ldr-data 000000835bffa000-00000083bfff9fff 00064000 1600MiB WB
conv-mem 00000083bfffa000-00000083bfffffff 00000006 24KiB WB
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
