* [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K @ 2018-03-31 14:13 Mark Kettenis 2018-04-03 7:34 ` Matwey V. Kornilov ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Mark Kettenis @ 2018-03-31 14:13 UTC (permalink / raw) To: u-boot Currently U-Boot doesn't make any effort to reserve the memory used by ARM Trusted Firmware on these platforms. The result is that the memory is listed as available in the EFI memory map. And as soon as a loaded kernel tries to use this memory things explode. I've seen this with the OpenBSD kernel. But I totally expect a Linux kernel to suffer the same fate. I'm currently using the diff below, but it is not entirely clear to me if arch_early_init_r() is the appropriate place to do this. I'm also wondering whether the block should also be marked as reserved in the FDT using fdt_add_mem_rsv(). If the latter is required this probably needs to be done by ft_board_setup() or ft_system_setup(). The address and size of the region have been taken from Marvell's ATF fork at https://github.com/MarvellEmbeddedProcessors/atf-marvell The memory layout is defined in plat/marvell/a8k/common/include/platform_def.h where there are lots of defines and a diagram that attempt to describe the memory. It is not entirely obvious to me what part needs to be reserved. But 0x0400000-0x04200000 works. diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c index 3c84043a2c..895cd2852f 100644 --- a/arch/arm/mach-mvebu/arm64-common.c +++ b/arch/arm/mach-mvebu/arm64-common.c @@ -95,5 +95,11 @@ int arch_early_init_r(void) pci_init(); #endif +#ifdef CONFIG_EFI_LOADER + /* Reserve trusted SRAM section */ + efi_add_memory_map(0x04000000, 0x00200000 >> EFI_PAGE_SHIFT, + EFI_RESERVED_MEMORY_TYPE, false); +#endif + return 0; } ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K 2018-03-31 14:13 [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K Mark Kettenis @ 2018-04-03 7:34 ` Matwey V. Kornilov 2018-04-06 10:04 ` Alexander Graf 2018-04-06 10:22 ` Alexander Graf 2 siblings, 0 replies; 12+ messages in thread From: Matwey V. Kornilov @ 2018-04-03 7:34 UTC (permalink / raw) To: u-boot Hello, I think I suffered from random kernel crashed due to this issue. Could you please also submit this patch to downstream Marvell u-boot at github PR? 31.03.2018 17:13, Mark Kettenis пишет: > Currently U-Boot doesn't make any effort to reserve the memory used by > ARM Trusted Firmware on these platforms. The result is that the > memory is listed as available in the EFI memory map. And as soon as a > loaded kernel tries to use this memory things explode. I've seen this > with the OpenBSD kernel. But I totally expect a Linux kernel to > suffer the same fate. > > I'm currently using the diff below, but it is not entirely clear to me > if arch_early_init_r() is the appropriate place to do this. I'm also > wondering whether the block should also be marked as reserved in the > FDT using fdt_add_mem_rsv(). If the latter is required this probably > needs to be done by ft_board_setup() or ft_system_setup(). > > The address and size of the region have been taken from Marvell's ATF > fork at > > https://github.com/MarvellEmbeddedProcessors/atf-marvell > > The memory layout is defined in > > plat/marvell/a8k/common/include/platform_def.h > > where there are lots of defines and a diagram that attempt to describe > the memory. It is not entirely obvious to me what part needs to be > reserved. But 0x0400000-0x04200000 works. > > > > > diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c > index 3c84043a2c..895cd2852f 100644 > --- a/arch/arm/mach-mvebu/arm64-common.c > +++ b/arch/arm/mach-mvebu/arm64-common.c > @@ -95,5 +95,11 @@ int arch_early_init_r(void) > pci_init(); > #endif > > +#ifdef CONFIG_EFI_LOADER > + /* Reserve trusted SRAM section */ > + efi_add_memory_map(0x04000000, 0x00200000 >> EFI_PAGE_SHIFT, > + EFI_RESERVED_MEMORY_TYPE, false); > +#endif > + > return 0; > } > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K 2018-03-31 14:13 [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K Mark Kettenis 2018-04-03 7:34 ` Matwey V. Kornilov @ 2018-04-06 10:04 ` Alexander Graf 2018-04-06 10:22 ` Alexander Graf 2 siblings, 0 replies; 12+ messages in thread From: Alexander Graf @ 2018-04-06 10:04 UTC (permalink / raw) To: u-boot On 31.03.18 16:13, Mark Kettenis wrote: > Currently U-Boot doesn't make any effort to reserve the memory used by > ARM Trusted Firmware on these platforms. The result is that the > memory is listed as available in the EFI memory map. And as soon as a > loaded kernel tries to use this memory things explode. I've seen this > with the OpenBSD kernel. But I totally expect a Linux kernel to > suffer the same fate. Please make sure to CC people you think would be interested. In this case, I believe Stefan certainly would care. Me too :). > I'm currently using the diff below, but it is not entirely clear to me > if arch_early_init_r() is the appropriate place to do this. I'm also > wondering whether the block should also be marked as reserved in the > FDT using fdt_add_mem_rsv(). If the latter is required this probably > needs to be done by ft_board_setup() or ft_system_setup(). > > The address and size of the region have been taken from Marvell's ATF > fork at > > https://github.com/MarvellEmbeddedProcessors/atf-marvell > > The memory layout is defined in > > plat/marvell/a8k/common/include/platform_def.h > > where there are lots of defines and a diagram that attempt to describe > the memory. It is not entirely obvious to me what part needs to be > reserved. But 0x0400000-0x04200000 works. Yeah, so ATF resides in RAM and U-Boot obviously needs to propagate that information. I actually think for mvebu it might make sense to completely override efi_add_known_memory(). If I read all the bdinfo logic correctly, they're going through great lengths to reduce the amount of address space they propagate in bi_dram: https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-mvebu/dram.c#L274 That of course means our memory map is completely bogus. So instead, what I would do is create an override for efi_add_known_memory() where you just walk the dram slots yourself and add all memory you find as BOOTTIME_DATA. That way the OS will know that it can use it for itself, but it won't be used during boot time. Then, go through bi_dram and force all those regions as free memory. And at last, reserve the ATF range as reserved. And yes, you want to do that in both - EFI map and as FDT fixup. Alex ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K 2018-03-31 14:13 [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K Mark Kettenis 2018-04-03 7:34 ` Matwey V. Kornilov 2018-04-06 10:04 ` Alexander Graf @ 2018-04-06 10:22 ` Alexander Graf 2019-02-04 16:51 ` Patrick Wildt 2 siblings, 1 reply; 12+ messages in thread From: Alexander Graf @ 2018-04-06 10:22 UTC (permalink / raw) To: u-boot On 31.03.18 16:13, Mark Kettenis wrote: > Currently U-Boot doesn't make any effort to reserve the memory used by > ARM Trusted Firmware on these platforms. The result is that the > memory is listed as available in the EFI memory map. And as soon as a > loaded kernel tries to use this memory things explode. I've seen this > with the OpenBSD kernel. But I totally expect a Linux kernel to > suffer the same fate. > > I'm currently using the diff below, but it is not entirely clear to me > if arch_early_init_r() is the appropriate place to do this. I'm also > wondering whether the block should also be marked as reserved in the > FDT using fdt_add_mem_rsv(). If the latter is required this probably > needs to be done by ft_board_setup() or ft_system_setup(). > > The address and size of the region have been taken from Marvell's ATF > fork at > > https://github.com/MarvellEmbeddedProcessors/atf-marvell > > The memory layout is defined in > > plat/marvell/a8k/common/include/platform_def.h > > where there are lots of defines and a diagram that attempt to describe > the memory. It is not entirely obvious to me what part needs to be > reserved. But 0x0400000-0x04200000 works. > > > > > diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c > index 3c84043a2c..895cd2852f 100644 > --- a/arch/arm/mach-mvebu/arm64-common.c > +++ b/arch/arm/mach-mvebu/arm64-common.c > @@ -95,5 +95,11 @@ int arch_early_init_r(void) > pci_init(); > #endif > > +#ifdef CONFIG_EFI_LOADER > + /* Reserve trusted SRAM section */ > + efi_add_memory_map(0x04000000, 0x00200000 >> EFI_PAGE_SHIFT, > + EFI_RESERVED_MEMORY_TYPE, false); I also forgot to comment here. 2MB is probably not enough: https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-armada-17.10/plat/marvell/a8k/common/include/platform_def.h#L110 That sounds more like it should span 65MB (PLAT_MARVELL_TRUSTED_ROM_SIZE plus 0x100000). Looking at what edk2 does, it seems to use the same range as you: https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/marvell-armada-wip/Platforms/Marvell/Armada/Armada.dsc.inc#L347 So let's also CC Marcin :). Maybe his range is too short! Alex ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K 2018-04-06 10:22 ` Alexander Graf @ 2019-02-04 16:51 ` Patrick Wildt 2019-02-12 9:38 ` Alexander Graf 0 siblings, 1 reply; 12+ messages in thread From: Patrick Wildt @ 2019-02-04 16:51 UTC (permalink / raw) To: u-boot On Fri, Apr 06, 2018 at 12:22:03PM +0200, Alexander Graf wrote: > On 31.03.18 16:13, Mark Kettenis wrote: > > Currently U-Boot doesn't make any effort to reserve the memory used by > > ARM Trusted Firmware on these platforms. The result is that the > > memory is listed as available in the EFI memory map. And as soon as a > > loaded kernel tries to use this memory things explode. I've seen this > > with the OpenBSD kernel. But I totally expect a Linux kernel to > > suffer the same fate. > > > > I'm currently using the diff below, but it is not entirely clear to me > > if arch_early_init_r() is the appropriate place to do this. I'm also > > wondering whether the block should also be marked as reserved in the > > FDT using fdt_add_mem_rsv(). If the latter is required this probably > > needs to be done by ft_board_setup() or ft_system_setup(). > > > > The address and size of the region have been taken from Marvell's ATF > > fork at > > > > https://github.com/MarvellEmbeddedProcessors/atf-marvell > > > > The memory layout is defined in > > > > plat/marvell/a8k/common/include/platform_def.h > > > > where there are lots of defines and a diagram that attempt to describe > > the memory. It is not entirely obvious to me what part needs to be > > reserved. But 0x0400000-0x04200000 works. > > > > > > > > > > diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c > > index 3c84043a2c..895cd2852f 100644 > > --- a/arch/arm/mach-mvebu/arm64-common.c > > +++ b/arch/arm/mach-mvebu/arm64-common.c > > @@ -95,5 +95,11 @@ int arch_early_init_r(void) > > pci_init(); > > #endif > > > > +#ifdef CONFIG_EFI_LOADER > > + /* Reserve trusted SRAM section */ > > + efi_add_memory_map(0x04000000, 0x00200000 >> EFI_PAGE_SHIFT, > > + EFI_RESERVED_MEMORY_TYPE, false); > > I also forgot to comment here. 2MB is probably not enough: > > > https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-armada-17.10/plat/marvell/a8k/common/include/platform_def.h#L110 > > That sounds more like it should span 65MB (PLAT_MARVELL_TRUSTED_ROM_SIZE > plus 0x100000). > > Looking at what edk2 does, it seems to use the same range as you: > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/marvell-armada-wip/Platforms/Marvell/Armada/Armada.dsc.inc#L347 > > So let's also CC Marcin :). Maybe his range is too short! > > > Alex > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot The current ATF and EDK2 branch from Marvell seem to reserve a bit more. I just had the same issue and am using this diff. This then creates the same map of usable memory as EDK2 does. Best regards, Patrick diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c index 47bbf69944..56c0d3f6b9 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 + return 0; } ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K 2019-02-04 16:51 ` Patrick Wildt @ 2019-02-12 9:38 ` Alexander Graf 2019-02-12 10:31 ` Marcin Wojtas 0 siblings, 1 reply; 12+ messages in thread From: Alexander Graf @ 2019-02-12 9:38 UTC (permalink / raw) To: u-boot On 02/04/2019 05:51 PM, Patrick Wildt wrote: > On Fri, Apr 06, 2018 at 12:22:03PM +0200, Alexander Graf wrote: >> On 31.03.18 16:13, Mark Kettenis wrote: >>> Currently U-Boot doesn't make any effort to reserve the memory used by >>> ARM Trusted Firmware on these platforms. The result is that the >>> memory is listed as available in the EFI memory map. And as soon as a >>> loaded kernel tries to use this memory things explode. I've seen this >>> with the OpenBSD kernel. But I totally expect a Linux kernel to >>> suffer the same fate. >>> >>> I'm currently using the diff below, but it is not entirely clear to me >>> if arch_early_init_r() is the appropriate place to do this. I'm also >>> wondering whether the block should also be marked as reserved in the >>> FDT using fdt_add_mem_rsv(). If the latter is required this probably >>> needs to be done by ft_board_setup() or ft_system_setup(). >>> >>> The address and size of the region have been taken from Marvell's ATF >>> fork at >>> >>> https://github.com/MarvellEmbeddedProcessors/atf-marvell >>> >>> The memory layout is defined in >>> >>> plat/marvell/a8k/common/include/platform_def.h >>> >>> where there are lots of defines and a diagram that attempt to describe >>> the memory. It is not entirely obvious to me what part needs to be >>> reserved. But 0x0400000-0x04200000 works. >>> >>> >>> >>> >>> diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c >>> index 3c84043a2c..895cd2852f 100644 >>> --- a/arch/arm/mach-mvebu/arm64-common.c >>> +++ b/arch/arm/mach-mvebu/arm64-common.c >>> @@ -95,5 +95,11 @@ int arch_early_init_r(void) >>> pci_init(); >>> #endif >>> >>> +#ifdef CONFIG_EFI_LOADER >>> + /* Reserve trusted SRAM section */ >>> + efi_add_memory_map(0x04000000, 0x00200000 >> EFI_PAGE_SHIFT, >>> + EFI_RESERVED_MEMORY_TYPE, false); >> I also forgot to comment here. 2MB is probably not enough: >> >> >> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-armada-17.10/plat/marvell/a8k/common/include/platform_def.h#L110 >> >> That sounds more like it should span 65MB (PLAT_MARVELL_TRUSTED_ROM_SIZE >> plus 0x100000). >> >> Looking at what edk2 does, it seems to use the same range as you: >> >> >> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/marvell-armada-wip/Platforms/Marvell/Armada/Armada.dsc.inc#L347 >> >> So let's also CC Marcin :). Maybe his range is too short! >> >> >> Alex >> _______________________________________________ >> U-Boot mailing list >> U-Boot at lists.denx.de >> https://lists.denx.de/listinfo/u-boot > The current ATF and EDK2 branch from Marvell seem to reserve a bit more. > I just had the same issue and am using this diff. This then creates the > same map of usable memory as EDK2 does. Could you please resend as proper patch (with SoB, separate email) with a reference to the edk2 code in the commit message? Thanks, Alex > > Best regards, > Patrick > > diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c > index 47bbf69944..56c0d3f6b9 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 > + > return 0; > } ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K 2019-02-12 9:38 ` Alexander Graf @ 2019-02-12 10:31 ` Marcin Wojtas 2019-06-11 11:00 ` [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K Patrick Wildt 0 siblings, 1 reply; 12+ messages in thread From: Marcin Wojtas @ 2019-02-12 10:31 UTC (permalink / raw) To: u-boot Hi Patrick, You can refer to the mainline edk2 patch: https://github.com/tianocore/edk2-platforms/commit/bf1c4a2cf8024669d1748e78c7e417433f85707e Best regards, Marcin wt., 12 lut 2019 o 10:38 Alexander Graf <agraf@suse.de> napisał(a): > On 02/04/2019 05:51 PM, Patrick Wildt wrote: > > On Fri, Apr 06, 2018 at 12:22:03PM +0200, Alexander Graf wrote: > >> On 31.03.18 16:13, Mark Kettenis wrote: > >>> Currently U-Boot doesn't make any effort to reserve the memory used by > >>> ARM Trusted Firmware on these platforms. The result is that the > >>> memory is listed as available in the EFI memory map. And as soon as a > >>> loaded kernel tries to use this memory things explode. I've seen this > >>> with the OpenBSD kernel. But I totally expect a Linux kernel to > >>> suffer the same fate. > >>> > >>> I'm currently using the diff below, but it is not entirely clear to me > >>> if arch_early_init_r() is the appropriate place to do this. I'm also > >>> wondering whether the block should also be marked as reserved in the > >>> FDT using fdt_add_mem_rsv(). If the latter is required this probably > >>> needs to be done by ft_board_setup() or ft_system_setup(). > >>> > >>> The address and size of the region have been taken from Marvell's ATF > >>> fork at > >>> > >>> https://github.com/MarvellEmbeddedProcessors/atf-marvell > >>> > >>> The memory layout is defined in > >>> > >>> plat/marvell/a8k/common/include/platform_def.h > >>> > >>> where there are lots of defines and a diagram that attempt to describe > >>> the memory. It is not entirely obvious to me what part needs to be > >>> reserved. But 0x0400000-0x04200000 works. > >>> > >>> > >>> > >>> > >>> diff --git a/arch/arm/mach-mvebu/arm64-common.c > b/arch/arm/mach-mvebu/arm64-common.c > >>> index 3c84043a2c..895cd2852f 100644 > >>> --- a/arch/arm/mach-mvebu/arm64-common.c > >>> +++ b/arch/arm/mach-mvebu/arm64-common.c > >>> @@ -95,5 +95,11 @@ int arch_early_init_r(void) > >>> pci_init(); > >>> #endif > >>> > >>> +#ifdef CONFIG_EFI_LOADER > >>> + /* Reserve trusted SRAM section */ > >>> + efi_add_memory_map(0x04000000, 0x00200000 >> EFI_PAGE_SHIFT, > >>> + EFI_RESERVED_MEMORY_TYPE, false); > >> I also forgot to comment here. 2MB is probably not enough: > >> > >> > >> > https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-armada-17.10/plat/marvell/a8k/common/include/platform_def.h#L110 > >> > >> That sounds more like it should span 65MB (PLAT_MARVELL_TRUSTED_ROM_SIZE > >> plus 0x100000). > >> > >> Looking at what edk2 does, it seems to use the same range as you: > >> > >> > >> > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/marvell-armada-wip/Platforms/Marvell/Armada/Armada.dsc.inc#L347 > >> > >> So let's also CC Marcin :). Maybe his range is too short! > >> > >> > >> Alex > >> _______________________________________________ > >> U-Boot mailing list > >> U-Boot at lists.denx.de > >> https://lists.denx.de/listinfo/u-boot > > The current ATF and EDK2 branch from Marvell seem to reserve a bit more. > > I just had the same issue and am using this diff. This then creates the > > same map of usable memory as EDK2 does. > > Could you please resend as proper patch (with SoB, separate email) with > a reference to the edk2 code in the commit message? > > > Thanks, > > Alex > > > > > Best regards, > > Patrick > > > > diff --git a/arch/arm/mach-mvebu/arm64-common.c > b/arch/arm/mach-mvebu/arm64-common.c > > index 47bbf69944..56c0d3f6b9 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 > > + > > return 0; > > } > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K 2019-02-12 10:31 ` Marcin Wojtas @ 2019-06-11 11:00 ` Patrick Wildt 2019-06-13 5:48 ` Stefan Roese 0 siblings, 1 reply; 12+ messages in thread From: Patrick Wildt @ 2019-06-11 11:00 UTC (permalink / raw) To: u-boot 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@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 + return 0; } ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K 2019-06-11 11:00 ` [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K Patrick Wildt @ 2019-06-13 5:48 ` Stefan Roese 2019-06-13 6:09 ` Heinrich Schuchardt 0 siblings, 1 reply; 12+ messages in thread From: Stefan Roese @ 2019-06-13 5:48 UTC (permalink / raw) To: u-boot 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@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 > + > return 0; > } > I would like to see some comments from the U-Boot "EFI guys", if this is the correct approach. I remember some discussions about using "reserved-memory" in the DT for this but I might be wrong here. Any comments? Thanks, Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K 2019-06-13 5:48 ` Stefan Roese @ 2019-06-13 6:09 ` Heinrich Schuchardt 2019-06-13 8:23 ` Mark Kettenis 0 siblings, 1 reply; 12+ messages in thread From: Heinrich Schuchardt @ 2019-06-13 6:09 UTC (permalink / raw) To: u-boot 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@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. Best regards Heinrich >> + >> return 0; >> } >> > > I would like to see some comments from the U-Boot "EFI guys", if > this is the correct approach. I remember some discussions about > using "reserved-memory" in the DT for this but I might be wrong > here. > > Any comments? > > Thanks, > Stefan > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K 2019-06-13 6:09 ` Heinrich Schuchardt @ 2019-06-13 8:23 ` Mark Kettenis 2019-06-13 9:11 ` Heinrich Schuchardt 0 siblings, 1 reply; 12+ messages in thread From: Mark Kettenis @ 2019-06-13 8:23 UTC (permalink / raw) To: u-boot > From: Heinrich Schuchardt <xypron.glpk@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@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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K 2019-06-13 8:23 ` Mark Kettenis @ 2019-06-13 9:11 ` Heinrich Schuchardt 0 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2019-06-13 9:11 UTC (permalink / raw) To: u-boot On 6/13/19 10:23 AM, Mark Kettenis wrote: >> From: Heinrich Schuchardt <xypron.glpk@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@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-06-13 9:11 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-31 14:13 [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K Mark Kettenis 2018-04-03 7:34 ` Matwey V. Kornilov 2018-04-06 10:04 ` Alexander Graf 2018-04-06 10:22 ` Alexander Graf 2019-02-04 16:51 ` Patrick Wildt 2019-02-12 9:38 ` Alexander Graf 2019-02-12 10:31 ` Marcin Wojtas 2019-06-11 11:00 ` [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K Patrick Wildt 2019-06-13 5:48 ` Stefan Roese 2019-06-13 6:09 ` Heinrich Schuchardt 2019-06-13 8:23 ` Mark Kettenis 2019-06-13 9:11 ` Heinrich Schuchardt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.