Re: EFI memory allocation
Hi Ilias, On Mon, 4 Dec 2023 at 05:05, Ilias Apalodimas wrote: > > Hi Simon > > On Sun, 3 Dec 2023 at 19:44, Simon Glass wrote: > > > > Hi Heinrich, Ilias, > > > > I had a bit of a look at how memory is allocated in EFI. > > > > I see that efi_memory_init() is called quite early in U-Boot. It > > sometimes allocates memory for a bounce buffer, placing it somewhere > > in memory. How do we know that that memory is free and not being used > > by U-Boot? > > > > To answer my own question, it excludes U-Boot's malloc() region from > > the map, so that it cannot overwrite that. > > > > But then, what if we use lmb and start loading images into memory. > > Won't that conflict with EFI? > > Yes, Heinrich tried to fix parts of this with commit 06d514d77c37 and OK, that looks very odd to me. > we have a 'todo' in the efi subsystem for a few years now [0] > Michal (+cc'ed) has also pinged me for similar issues in the past. > > > > > I also see that efi_allocate_pages() is called to allocate memory in > > the EFI code. But this just grabs memory from 'anywhere'...it doesn't > > respect the U-Boot malloc region. > > > > It seems to me that most of the memory allocation in EFI should be > > done using malloc(). Of course the boot services need to > > efi_allocate_pages(), etc., but I am not sure that the internal tables > > should be skipping malloc()? > > > > What do you think? > > I think that LMB, EFI and the whole memory reservations is a bit of a > mess. Tom and I discussed this a bit in the past but I'll start > working on it. > It needs fixing, but without looking at the code first, I can't > provide any useful feedback > > [0] https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/2 OK I mad a comment there. We should figure out a design before going ahead. Regards, Simon
Re: EFI memory allocation
Hi Simon On Sun, 3 Dec 2023 at 19:44, Simon Glass wrote: > > Hi Heinrich, Ilias, > > I had a bit of a look at how memory is allocated in EFI. > > I see that efi_memory_init() is called quite early in U-Boot. It > sometimes allocates memory for a bounce buffer, placing it somewhere > in memory. How do we know that that memory is free and not being used > by U-Boot? > > To answer my own question, it excludes U-Boot's malloc() region from > the map, so that it cannot overwrite that. > > But then, what if we use lmb and start loading images into memory. > Won't that conflict with EFI? Yes, Heinrich tried to fix parts of this with commit 06d514d77c37 and we have a 'todo' in the efi subsystem for a few years now [0] Michal (+cc'ed) has also pinged me for similar issues in the past. > > I also see that efi_allocate_pages() is called to allocate memory in > the EFI code. But this just grabs memory from 'anywhere'...it doesn't > respect the U-Boot malloc region. > > It seems to me that most of the memory allocation in EFI should be > done using malloc(). Of course the boot services need to > efi_allocate_pages(), etc., but I am not sure that the internal tables > should be skipping malloc()? > > What do you think? I think that LMB, EFI and the whole memory reservations is a bit of a mess. Tom and I discussed this a bit in the past but I'll start working on it. It needs fixing, but without looking at the code first, I can't provide any useful feedback [0] https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/2 Thanks /Ilias > > Regards, > Simon
EFI memory allocation
Hi Heinrich, Ilias, I had a bit of a look at how memory is allocated in EFI. I see that efi_memory_init() is called quite early in U-Boot. It sometimes allocates memory for a bounce buffer, placing it somewhere in memory. How do we know that that memory is free and not being used by U-Boot? To answer my own question, it excludes U-Boot's malloc() region from the map, so that it cannot overwrite that. But then, what if we use lmb and start loading images into memory. Won't that conflict with EFI? I also see that efi_allocate_pages() is called to allocate memory in the EFI code. But this just grabs memory from 'anywhere'...it doesn't respect the U-Boot malloc region. It seems to me that most of the memory allocation in EFI should be done using malloc(). Of course the boot services need to efi_allocate_pages(), etc., but I am not sure that the internal tables should be skipping malloc()? What do you think? Regards, Simon
Re: [U-Boot] [PATCH] arm64: mvebu: fix crash in EFI memory allocation
On 29.11.18 19:54, Baruch Siach wrote:
> Hi Stephen,
>
> Adding Heinrich Schuchardt.
>
> Stephen Warren writes:
>> On 11/22/18 8:19 AM, Baruch Siach wrote:
>>> Adding Stephen Warren to Cc.
>>>
>>> On Thu, Nov 22, 2018 at 02:30:34PM +, Alexander Graf wrote:
>>>>> Am 22.11.2018 um 11:42 schrieb Baruch Siach :
>>>>>
>>>>> EFI memory allocation code return values that are not mapped by U-Boot
>>>>> MMU. This causes a crash when tftp calls efi_set_bootdev(). Fix this
>>>>> similarly to commit 0797f7f0b7e1 ("ARM: tegra: reserve unmapped RAM so
>>>>> EFI doesn't use it").
>>>>>
>>>>> Signed-off-by: Baruch Siach
>>>>
>>>> Hm, how about we fox this up in the common memory registration function and
>>>> add addresses > board_get_usable_ram_top() as boot time data?
>>>
>>> That would be much nicer indeed. Where should I look in lib/efi_loader/ to
>>> implement that?
>>>
>>> With that in place we can revert commit 0797f7f0b7e1, right? Stephen, do you
>>> concur?
>>
>> I believe so, yes. I'm not sure why it's acceptable to fix the EFI allocator
>> to solve this now, when it wasn't acceptable before though.
>
> I read the previous discussion[1] from July/August. If I understand the
> conclusion correctly, efi_add_memory_map() provides information that is
> vital to the correctness of the EFI memory map, and is platform
> specific. Is that correct?
>
> If so, then this patch (actually, its v2) is the correct solution for
> Armada 8K. A possible improvement to the EFI memory allocation code
> would be a warning instead of crash. Would that be acceptable?
So the problem is that the EFI memory map needs to describe all memory.
We can't just leave out chunks because U-Boot doesn't map them, as then
Linux wouldn't get to see them either.
What we can do however, is mark regions that should not be used during
boot time as "allocated by firmware". That way the memory map still
exposes the full map, but we make sure no payload makes use of high
addresses when they're not mapped.
I honestly don't remember why exactly I didn't want to put in support
for board_get_usable_ram_top() in the generic code. It's a reasonable
interface to influence the allocation code. I must've thought it's
nvidia specific, so a one-off and thus made more sense in their board file.
Let me quickly write up a patch of what I have in mind.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: mvebu: fix crash in EFI memory allocation
Hi Stephen,
Adding Heinrich Schuchardt.
Stephen Warren writes:
> On 11/22/18 8:19 AM, Baruch Siach wrote:
>> Adding Stephen Warren to Cc.
>>
>> On Thu, Nov 22, 2018 at 02:30:34PM +, Alexander Graf wrote:
>>>> Am 22.11.2018 um 11:42 schrieb Baruch Siach :
>>>>
>>>> EFI memory allocation code return values that are not mapped by U-Boot
>>>> MMU. This causes a crash when tftp calls efi_set_bootdev(). Fix this
>>>> similarly to commit 0797f7f0b7e1 ("ARM: tegra: reserve unmapped RAM so
>>>> EFI doesn't use it").
>>>>
>>>> Signed-off-by: Baruch Siach
>>>
>>> Hm, how about we fox this up in the common memory registration function and
>>> add addresses > board_get_usable_ram_top() as boot time data?
>>
>> That would be much nicer indeed. Where should I look in lib/efi_loader/ to
>> implement that?
>>
>> With that in place we can revert commit 0797f7f0b7e1, right? Stephen, do you
>> concur?
>
> I believe so, yes. I'm not sure why it's acceptable to fix the EFI allocator
> to solve this now, when it wasn't acceptable before though.
I read the previous discussion[1] from July/August. If I understand the
conclusion correctly, efi_add_memory_map() provides information that is
vital to the correctness of the EFI memory map, and is platform
specific. Is that correct?
If so, then this patch (actually, its v2) is the correct solution for
Armada 8K. A possible improvement to the EFI memory allocation code
would be a warning instead of crash. Would that be acceptable?
Thanks,
baruch
[1] https://lists.denx.de/pipermail/u-boot/2018-July/336726.html
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: mvebu: fix crash in EFI memory allocation
On 11/22/18 8:19 AM, Baruch Siach wrote:
Hi Alex,
Adding Stephen Warren to Cc.
On Thu, Nov 22, 2018 at 02:30:34PM +, Alexander Graf wrote:
Am 22.11.2018 um 11:42 schrieb Baruch Siach :
EFI memory allocation code return values that are not mapped by U-Boot
MMU. This causes a crash when tftp calls efi_set_bootdev(). Fix this
similarly to commit 0797f7f0b7e1 ("ARM: tegra: reserve unmapped RAM so
EFI doesn't use it").
Signed-off-by: Baruch Siach
Hm, how about we fox this up in the common memory registration function and
add addresses > board_get_usable_ram_top() as boot time data?
That would be much nicer indeed. Where should I look in lib/efi_loader/ to
implement that?
With that in place we can revert commit 0797f7f0b7e1, right? Stephen, do you
concur?
I believe so, yes. I'm not sure why it's acceptable to fix the EFI
allocator to solve this now, when it wasn't acceptable before though.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: mvebu: fix crash in EFI memory allocation
Hi Alex,
Adding Stephen Warren to Cc.
On Thu, Nov 22, 2018 at 02:30:34PM +, Alexander Graf wrote:
> > Am 22.11.2018 um 11:42 schrieb Baruch Siach :
> >
> > EFI memory allocation code return values that are not mapped by U-Boot
> > MMU. This causes a crash when tftp calls efi_set_bootdev(). Fix this
> > similarly to commit 0797f7f0b7e1 ("ARM: tegra: reserve unmapped RAM so
> > EFI doesn't use it").
> >
> > Signed-off-by: Baruch Siach
>
> Hm, how about we fox this up in the common memory registration function and
> add addresses > board_get_usable_ram_top() as boot time data?
That would be much nicer indeed. Where should I look in lib/efi_loader/ to
implement that?
With that in place we can revert commit 0797f7f0b7e1, right? Stephen, do you
concur?
> As a side note, why do we not map everything in the first place? Is it just
> to prevent 32bit DMAs from failing?
baruch
> > ---
> > arch/arm/mach-mvebu/arm64-common.c | 13 ++---
> > arch/arm/mach-mvebu/include/mach/cpu.h | 9 +
> > board/Marvell/mvebu_armada-8k/board.c | 17 +
> > 3 files changed, 28 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/arm64-common.c
> > b/arch/arm/mach-mvebu/arm64-common.c
> > index 47bbf69944ec..b82f33093a2c 100644
> > --- a/arch/arm/mach-mvebu/arm64-common.c
> > +++ b/arch/arm/mach-mvebu/arm64-common.c
> > @@ -17,19 +17,10 @@
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > -/*
> > - * Not all memory is mapped in the MMU. So we need to restrict the
> > - * memory size so that U-Boot does not try to access it. Also, the
> > - * internal registers are located at 0xf000. - 0x..
> > - * Currently only 2GiB are mapped for system memory. This is what
> > - * we pass to the U-Boot subsystem here.
> > - */
> > -#define USABLE_RAM_SIZE0x8000
> > -
> > ulong board_get_usable_ram_top(ulong total_size)
> > {
> > -if (gd->ram_size > USABLE_RAM_SIZE)
> > -return USABLE_RAM_SIZE;
> > +if (gd->ram_size > MVEBU_ARM64_USABLE_RAM_SIZE)
> > +return MVEBU_ARM64_USABLE_RAM_SIZE;
> >
> >return gd->ram_size;
> > }
> > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > index 85d7dd1610a8..e22a14977859 100644
> > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > @@ -177,5 +177,14 @@ int mvebu_lcd_register_init(struct mvebu_lcd_info
> > *lcd_info);
> > */
> > u32 get_ref_clk(void);
> >
> > +/*
> > + * Not all memory is mapped in the MMU. So we need to restrict the
> > + * memory size so that U-Boot does not try to access it. Also, the
> > + * internal registers are located at 0xf000. - 0x..
> > + * Currently only 2GiB are mapped for system memory. This is what
> > + * we pass to the U-Boot subsystem in board_get_usable_ram_top().
> > + */
> > +#define MVEBU_ARM64_USABLE_RAM_SIZE0x8000
> > +
> > #endif /* __ASSEMBLY__ */
> > #endif /* _MVEBU_CPU_H */
> > diff --git a/board/Marvell/mvebu_armada-8k/board.c
> > b/board/Marvell/mvebu_armada-8k/board.c
> > index e927e338ea6e..2fffe05c4958 100644
> > --- a/board/Marvell/mvebu_armada-8k/board.c
> > +++ b/board/Marvell/mvebu_armada-8k/board.c
> > @@ -6,6 +6,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -154,6 +155,22 @@ int board_init(void)
> >
> > int board_late_init(void)
> > {
> > +uint64_t unmapped_ram_start = gd->bd->bi_dram[0].start
> > ++ MVEBU_ARM64_USABLE_RAM_SIZE;
> > +uint64_t unmapped_ram_size = gd->bd->bi_dram[0].size
> > +- MVEBU_ARM64_USABLE_RAM_SIZE;
> > +
> > +#if CONFIG_IS_ENABLED(EFI_LOADER)
> > +if (gd->bd->bi_dram[0].size > MVEBU_ARM64_USABLE_RAM_SIZE)
> > +efi_add_memory_map(unmapped_ram_start,
> > +unmapped_ram_size >> EFI_PAGE_SHIFT,
> > +EFI_BOOT_SERVICES_DATA, false);
> > +if (gd->bd->bi_dram[1].start)
> > +efi_add_memory_map(gd->bd->bi_dram[1].start,
> > +gd->bd->bi_dram[1].size >> EFI_PAGE_SHIFT,
> > +EFI_BOOT_SERVICES_DATA, false);
> > +#endif
> > +
> >/* Pre-configure the USB ports (overcurrent, VBus) */
> >board_xhci_config();
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: mvebu: fix crash in EFI memory allocation
> Am 22.11.2018 um 11:42 schrieb Baruch Siach :
>
> EFI memory allocation code return values that are not mapped by U-Boot
> MMU. This causes a crash when tftp calls efi_set_bootdev(). Fix this
> similarly to commit 0797f7f0b7e1 ("ARM: tegra: reserve unmapped RAM so
> EFI doesn't use it").
>
> Signed-off-by: Baruch Siach
Hm, how about we fox this up in the common memory registration function and add
addresses > board_get_usable_ram_top() as boot time data?
As a side note, why do we not map everything in the first place? Is it just to
prevent 32bit DMAs from failing?
Alex
> ---
> arch/arm/mach-mvebu/arm64-common.c | 13 ++---
> arch/arm/mach-mvebu/include/mach/cpu.h | 9 +
> board/Marvell/mvebu_armada-8k/board.c | 17 +
> 3 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/arm64-common.c
> b/arch/arm/mach-mvebu/arm64-common.c
> index 47bbf69944ec..b82f33093a2c 100644
> --- a/arch/arm/mach-mvebu/arm64-common.c
> +++ b/arch/arm/mach-mvebu/arm64-common.c
> @@ -17,19 +17,10 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -/*
> - * Not all memory is mapped in the MMU. So we need to restrict the
> - * memory size so that U-Boot does not try to access it. Also, the
> - * internal registers are located at 0xf000. - 0x..
> - * Currently only 2GiB are mapped for system memory. This is what
> - * we pass to the U-Boot subsystem here.
> - */
> -#define USABLE_RAM_SIZE0x8000
> -
> ulong board_get_usable_ram_top(ulong total_size)
> {
> -if (gd->ram_size > USABLE_RAM_SIZE)
> -return USABLE_RAM_SIZE;
> +if (gd->ram_size > MVEBU_ARM64_USABLE_RAM_SIZE)
> +return MVEBU_ARM64_USABLE_RAM_SIZE;
>
>return gd->ram_size;
> }
> diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> b/arch/arm/mach-mvebu/include/mach/cpu.h
> index 85d7dd1610a8..e22a14977859 100644
> --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> @@ -177,5 +177,14 @@ int mvebu_lcd_register_init(struct mvebu_lcd_info
> *lcd_info);
> */
> u32 get_ref_clk(void);
>
> +/*
> + * Not all memory is mapped in the MMU. So we need to restrict the
> + * memory size so that U-Boot does not try to access it. Also, the
> + * internal registers are located at 0xf000. - 0x..
> + * Currently only 2GiB are mapped for system memory. This is what
> + * we pass to the U-Boot subsystem in board_get_usable_ram_top().
> + */
> +#define MVEBU_ARM64_USABLE_RAM_SIZE0x8000
> +
> #endif /* __ASSEMBLY__ */
> #endif /* _MVEBU_CPU_H */
> diff --git a/board/Marvell/mvebu_armada-8k/board.c
> b/board/Marvell/mvebu_armada-8k/board.c
> index e927e338ea6e..2fffe05c4958 100644
> --- a/board/Marvell/mvebu_armada-8k/board.c
> +++ b/board/Marvell/mvebu_armada-8k/board.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -154,6 +155,22 @@ int board_init(void)
>
> int board_late_init(void)
> {
> +uint64_t unmapped_ram_start = gd->bd->bi_dram[0].start
> ++ MVEBU_ARM64_USABLE_RAM_SIZE;
> +uint64_t unmapped_ram_size = gd->bd->bi_dram[0].size
> +- MVEBU_ARM64_USABLE_RAM_SIZE;
> +
> +#if CONFIG_IS_ENABLED(EFI_LOADER)
> +if (gd->bd->bi_dram[0].size > MVEBU_ARM64_USABLE_RAM_SIZE)
> +efi_add_memory_map(unmapped_ram_start,
> +unmapped_ram_size >> EFI_PAGE_SHIFT,
> +EFI_BOOT_SERVICES_DATA, false);
> +if (gd->bd->bi_dram[1].start)
> +efi_add_memory_map(gd->bd->bi_dram[1].start,
> +gd->bd->bi_dram[1].size >> EFI_PAGE_SHIFT,
> +EFI_BOOT_SERVICES_DATA, false);
> +#endif
> +
>/* Pre-configure the USB ports (overcurrent, VBus) */
>board_xhci_config();
>
> --
> 2.19.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] arm64: mvebu: fix crash in EFI memory allocation
EFI memory allocation code return values that are not mapped by U-Boot
MMU. This causes a crash when tftp calls efi_set_bootdev(). Fix this
similarly to commit 0797f7f0b7e1 ("ARM: tegra: reserve unmapped RAM so
EFI doesn't use it").
Signed-off-by: Baruch Siach
---
v2: Fix the CONFIG_NR_DRAM_BANKS=1 case
---
arch/arm/mach-mvebu/arm64-common.c | 13 ++---
arch/arm/mach-mvebu/include/mach/cpu.h | 9 +
board/Marvell/mvebu_armada-8k/board.c | 17 +
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-mvebu/arm64-common.c
b/arch/arm/mach-mvebu/arm64-common.c
index 47bbf69944ec..b82f33093a2c 100644
--- a/arch/arm/mach-mvebu/arm64-common.c
+++ b/arch/arm/mach-mvebu/arm64-common.c
@@ -17,19 +17,10 @@
DECLARE_GLOBAL_DATA_PTR;
-/*
- * Not all memory is mapped in the MMU. So we need to restrict the
- * memory size so that U-Boot does not try to access it. Also, the
- * internal registers are located at 0xf000. - 0x..
- * Currently only 2GiB are mapped for system memory. This is what
- * we pass to the U-Boot subsystem here.
- */
-#define USABLE_RAM_SIZE0x8000
-
ulong board_get_usable_ram_top(ulong total_size)
{
- if (gd->ram_size > USABLE_RAM_SIZE)
- return USABLE_RAM_SIZE;
+ if (gd->ram_size > MVEBU_ARM64_USABLE_RAM_SIZE)
+ return MVEBU_ARM64_USABLE_RAM_SIZE;
return gd->ram_size;
}
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 85d7dd1610a8..e22a14977859 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -177,5 +177,14 @@ int mvebu_lcd_register_init(struct mvebu_lcd_info
*lcd_info);
*/
u32 get_ref_clk(void);
+/*
+ * Not all memory is mapped in the MMU. So we need to restrict the
+ * memory size so that U-Boot does not try to access it. Also, the
+ * internal registers are located at 0xf000. - 0x..
+ * Currently only 2GiB are mapped for system memory. This is what
+ * we pass to the U-Boot subsystem in board_get_usable_ram_top().
+ */
+#define MVEBU_ARM64_USABLE_RAM_SIZE0x8000
+
#endif /* __ASSEMBLY__ */
#endif /* _MVEBU_CPU_H */
diff --git a/board/Marvell/mvebu_armada-8k/board.c
b/board/Marvell/mvebu_armada-8k/board.c
index e927e338ea6e..86f9d8a4a424 100644
--- a/board/Marvell/mvebu_armada-8k/board.c
+++ b/board/Marvell/mvebu_armada-8k/board.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -154,6 +155,22 @@ int board_init(void)
int board_late_init(void)
{
+ uint64_t unmapped_ram_start = gd->bd->bi_dram[0].start
+ + MVEBU_ARM64_USABLE_RAM_SIZE;
+ uint64_t unmapped_ram_size = gd->bd->bi_dram[0].size
+ - MVEBU_ARM64_USABLE_RAM_SIZE;
+
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+ if (gd->bd->bi_dram[0].size > MVEBU_ARM64_USABLE_RAM_SIZE)
+ efi_add_memory_map(unmapped_ram_start,
+ unmapped_ram_size >> EFI_PAGE_SHIFT,
+ EFI_BOOT_SERVICES_DATA, false);
+ if (CONFIG_NR_DRAM_BANKS > 1 && gd->bd->bi_dram[1].start)
+ efi_add_memory_map(gd->bd->bi_dram[1].start,
+ gd->bd->bi_dram[1].size >> EFI_PAGE_SHIFT,
+ EFI_BOOT_SERVICES_DATA, false);
+#endif
+
/* Pre-configure the USB ports (overcurrent, VBus) */
board_xhci_config();
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: mvebu: fix crash in EFI memory allocation
EFI memory allocation code return values that are not mapped by U-Boot
MMU. This causes a crash when tftp calls efi_set_bootdev(). Fix this
similarly to commit 0797f7f0b7e1 ("ARM: tegra: reserve unmapped RAM so
EFI doesn't use it").
Signed-off-by: Baruch Siach
---
arch/arm/mach-mvebu/arm64-common.c | 13 ++---
arch/arm/mach-mvebu/include/mach/cpu.h | 9 +
board/Marvell/mvebu_armada-8k/board.c | 17 +
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-mvebu/arm64-common.c
b/arch/arm/mach-mvebu/arm64-common.c
index 47bbf69944ec..b82f33093a2c 100644
--- a/arch/arm/mach-mvebu/arm64-common.c
+++ b/arch/arm/mach-mvebu/arm64-common.c
@@ -17,19 +17,10 @@
DECLARE_GLOBAL_DATA_PTR;
-/*
- * Not all memory is mapped in the MMU. So we need to restrict the
- * memory size so that U-Boot does not try to access it. Also, the
- * internal registers are located at 0xf000. - 0x..
- * Currently only 2GiB are mapped for system memory. This is what
- * we pass to the U-Boot subsystem here.
- */
-#define USABLE_RAM_SIZE0x8000
-
ulong board_get_usable_ram_top(ulong total_size)
{
- if (gd->ram_size > USABLE_RAM_SIZE)
- return USABLE_RAM_SIZE;
+ if (gd->ram_size > MVEBU_ARM64_USABLE_RAM_SIZE)
+ return MVEBU_ARM64_USABLE_RAM_SIZE;
return gd->ram_size;
}
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 85d7dd1610a8..e22a14977859 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -177,5 +177,14 @@ int mvebu_lcd_register_init(struct mvebu_lcd_info
*lcd_info);
*/
u32 get_ref_clk(void);
+/*
+ * Not all memory is mapped in the MMU. So we need to restrict the
+ * memory size so that U-Boot does not try to access it. Also, the
+ * internal registers are located at 0xf000. - 0x..
+ * Currently only 2GiB are mapped for system memory. This is what
+ * we pass to the U-Boot subsystem in board_get_usable_ram_top().
+ */
+#define MVEBU_ARM64_USABLE_RAM_SIZE0x8000
+
#endif /* __ASSEMBLY__ */
#endif /* _MVEBU_CPU_H */
diff --git a/board/Marvell/mvebu_armada-8k/board.c
b/board/Marvell/mvebu_armada-8k/board.c
index e927e338ea6e..2fffe05c4958 100644
--- a/board/Marvell/mvebu_armada-8k/board.c
+++ b/board/Marvell/mvebu_armada-8k/board.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -154,6 +155,22 @@ int board_init(void)
int board_late_init(void)
{
+ uint64_t unmapped_ram_start = gd->bd->bi_dram[0].start
+ + MVEBU_ARM64_USABLE_RAM_SIZE;
+ uint64_t unmapped_ram_size = gd->bd->bi_dram[0].size
+ - MVEBU_ARM64_USABLE_RAM_SIZE;
+
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+ if (gd->bd->bi_dram[0].size > MVEBU_ARM64_USABLE_RAM_SIZE)
+ efi_add_memory_map(unmapped_ram_start,
+ unmapped_ram_size >> EFI_PAGE_SHIFT,
+ EFI_BOOT_SERVICES_DATA, false);
+ if (gd->bd->bi_dram[1].start)
+ efi_add_memory_map(gd->bd->bi_dram[1].start,
+ gd->bd->bi_dram[1].size >> EFI_PAGE_SHIFT,
+ EFI_BOOT_SERVICES_DATA, false);
+#endif
+
/* Pre-configure the USB ports (overcurrent, VBus) */
board_xhci_config();
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
