[PATCH 1/3] configs: stm32mp1: stm32mp1: Increase SPL malloc() size

[PATCH 1/3] configs: stm32mp1: stm32mp1: Increase SPL malloc() size

[Alexandru Gagniuc]

Since commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for
loading images"), FIT images must be malloc()'d before being loaded.
The old size of 1 MiB is suitable for FIT images with u-boot and an
FDT, but something containing a linux kernel is almost sure to fail.

It's safe to extend malloc all the way to 0xc2000000, but no further.
Linux likes to be loaded at 0xc2000000, so we use that as our cutoff
point. This gives us 29 MiB of malloc() space, which suited for more
complex FIT images including several DTBs, kernel, and OP-TEE images.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
---
 include/configs/stm32mp1.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index db2117a3d7..7fdb3ffce4 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -53,7 +53,7 @@
 #define CONFIG_SPL_BSS_START_ADDR	0xC0200000
 #define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
 #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
-#define CONFIG_SYS_SPL_MALLOC_SIZE	0x00100000
+#define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
 
 /* limit SYSRAM usage to first 128 KB */
 #define CONFIG_SPL_MAX_SIZE		0x00020000
-- 
2.26.2

[PATCH 2/3] configs: stm32mp1: Remove misleading CONFIG_SPL_BSS_START_ADDR

[Alexandru Gagniuc]

CONFIG_SPL_BSS_START_ADDR is only used on a few mach- linker scripts.
stm32mp1 uses the generic script under arch/arm/cpu/u-boot-spl.lds,
which does not make use of this definition.

The SPL BSS starts in SRAM, right after .text, .rodata, .data, and
.u_boot_list. A very short version of the STM32MP1 memory map is:
  * SYSRAM: 2ffc0000 - 30000000     <- all of SPL is here
  * DRAM:   c0000000+

0xC0200000 is a DRAM address, and has nothing to do with SPL. It is
just very misleading to have it next to CONFIG_SPL_BSS_MAX_SIZE, or to
have it at all.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
---
 include/configs/stm32mp1.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 7fdb3ffce4..56a70cb584 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -50,7 +50,6 @@
 /* SPL support */
 #ifdef CONFIG_SPL
 /* SPL use DDR */
-#define CONFIG_SPL_BSS_START_ADDR	0xC0200000
 #define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
 #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
 #define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
-- 
2.26.2

[PATCH 2/3] configs: stm32mp1: Remove misleading CONFIG_SPL_BSS_START_ADDR

[Patrice CHOTARD]

Hi Alexandru

On 3/22/21 2:20 PM, Alexandru Gagniuc wrote:
> CONFIG_SPL_BSS_START_ADDR is only used on a few mach- linker scripts.
> stm32mp1 uses the generic script under arch/arm/cpu/u-boot-spl.lds,
> which does not make use of this definition.
> 
> The SPL BSS starts in SRAM, right after .text, .rodata, .data, and
> .u_boot_list. A very short version of the STM32MP1 memory map is:
>   * SYSRAM: 2ffc0000 - 30000000     <- all of SPL is here
>   * DRAM:   c0000000+
> 
> 0xC0200000 is a DRAM address, and has nothing to do with SPL. It is
> just very misleading to have it next to CONFIG_SPL_BSS_MAX_SIZE, or to
> have it at all.
> 
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>  include/configs/stm32mp1.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index 7fdb3ffce4..56a70cb584 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -50,7 +50,6 @@
>  /* SPL support */
>  #ifdef CONFIG_SPL
>  /* SPL use DDR */
> -#define CONFIG_SPL_BSS_START_ADDR	0xC0200000
>  #define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>  #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
>  #define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
> 


Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

Thanks
Patrice

[PATCH 2/3] configs: stm32mp1: Remove misleading CONFIG_SPL_BSS_START_ADDR

[Patrick DELAUNAY]

Hi,

On 3/22/21 2:20 PM, Alexandru Gagniuc wrote:
> CONFIG_SPL_BSS_START_ADDR is only used on a few mach- linker scripts.
> stm32mp1 uses the generic script under arch/arm/cpu/u-boot-spl.lds,
> which does not make use of this definition.
>
> The SPL BSS starts in SRAM, right after .text, .rodata, .data, and
> .u_boot_list. A very short version of the STM32MP1 memory map is:
>    * SYSRAM: 2ffc0000 - 30000000     <- all of SPL is here
>    * DRAM:   c0000000+
>
> 0xC0200000 is a DRAM address, and has nothing to do with SPL. It is
> just very misleading to have it next to CONFIG_SPL_BSS_MAX_SIZE, or to
> have it at all.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>   include/configs/stm32mp1.h | 1 -
>   1 file changed, 1 deletion(-)
>
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index 7fdb3ffce4..56a70cb584 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -50,7 +50,6 @@
>   /* SPL support */
>   #ifdef CONFIG_SPL
>   /* SPL use DDR */
> -#define CONFIG_SPL_BSS_START_ADDR	0xC0200000
>   #define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>   #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
>   #define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000


Strange but agree and CONFIG_SPL_BSS_MAX_SIZE

can be also removed with previous patch.


Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

Thanks
Patrick

[PATCH 2/3] configs: stm32mp1: Remove misleading CONFIG_SPL_BSS_START_ADDR

[Patrice CHOTARD]

Hi Alexandru

On 3/22/21 2:20 PM, Alexandru Gagniuc wrote:
> CONFIG_SPL_BSS_START_ADDR is only used on a few mach- linker scripts.
> stm32mp1 uses the generic script under arch/arm/cpu/u-boot-spl.lds,
> which does not make use of this definition.
> 
> The SPL BSS starts in SRAM, right after .text, .rodata, .data, and
> .u_boot_list. A very short version of the STM32MP1 memory map is:
>   * SYSRAM: 2ffc0000 - 30000000     <- all of SPL is here
>   * DRAM:   c0000000+
> 
> 0xC0200000 is a DRAM address, and has nothing to do with SPL. It is
> just very misleading to have it next to CONFIG_SPL_BSS_MAX_SIZE, or to
> have it at all.
> 
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>  include/configs/stm32mp1.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index 7fdb3ffce4..56a70cb584 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -50,7 +50,6 @@
>  /* SPL support */
>  #ifdef CONFIG_SPL
>  /* SPL use DDR */
> -#define CONFIG_SPL_BSS_START_ADDR	0xC0200000
>  #define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>  #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
>  #define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
> 
Applied to u-boot-stm/master

Thanks
Patrice

[PATCH 3/3] configs: stm32mp1: Fix misleading SPL size limitations

[Alexandru Gagniuc]

A now removed comment promises to "limit SYSRAM usage to first 128 KB".
This would imply that only SYSRAM from 0x2ffc0000 - 0x2ffe0000 would be
used. This is not what happens at all.

First, SPL_MAX_SIZE is referenced from SPL_TEXT_BASE, which on all
existing configs is set to 0x2ffc2500, not SYSRAM_BASE (0x2ffc0000).
Some of it is in the first 128 KiB and some of it is in the second
128 KiB chunk of SYSRAM.

Second, SPL_MAX_SIZE, does not restrict the BSS size. While a valiant
attempt is made via SPL_BSS_MAX_SIZE, the value of 0x00100000 is much
larger than SYSRAM, and doesn't account for the non-BSS sections.

Because we're putting the .text and .bss in the same boat, the correct
way to limit them together is via SPL_MAX_FOOTPRINT. With the current
SPL_TEXT_BASE, we couldn't limit even a very basic SPL to the first
128 KiB, and there is no technical reason to do so. Because of this,
simply allow the SPL to use all SYSRAM.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
---
 include/configs/stm32mp1.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 56a70cb584..440efa1a55 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -50,12 +50,12 @@
 /* SPL support */
 #ifdef CONFIG_SPL
 /* SPL use DDR */
-#define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
 #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
 #define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
 
-/* limit SYSRAM usage to first 128 KB */
-#define CONFIG_SPL_MAX_SIZE		0x00020000
+/* Restrict SPL to fit within SYSRAM */
+#define STM32_SYSRAM_END		(STM32_SYSRAM_BASE + STM32_SYSRAM_SIZE)
+#define CONFIG_SPL_MAX_FOOTPRINT	(STM32_SYSRAM_END - CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SPL_STACK		(STM32_SYSRAM_BASE + \
 					 STM32_SYSRAM_SIZE)
 #endif /* #ifdef CONFIG_SPL */
-- 
2.26.2

[PATCH 3/3] configs: stm32mp1: Fix misleading SPL size limitations

[Patrice CHOTARD]

Hi Alexandru

On 3/22/21 2:20 PM, Alexandru Gagniuc wrote:
> A now removed comment promises to "limit SYSRAM usage to first 128 KB".
> This would imply that only SYSRAM from 0x2ffc0000 - 0x2ffe0000 would be
> used. This is not what happens at all.
> 
> First, SPL_MAX_SIZE is referenced from SPL_TEXT_BASE, which on all
> existing configs is set to 0x2ffc2500, not SYSRAM_BASE (0x2ffc0000).
> Some of it is in the first 128 KiB and some of it is in the second
> 128 KiB chunk of SYSRAM.
> 
> Second, SPL_MAX_SIZE, does not restrict the BSS size. While a valiant
> attempt is made via SPL_BSS_MAX_SIZE, the value of 0x00100000 is much
> larger than SYSRAM, and doesn't account for the non-BSS sections.
> 
> Because we're putting the .text and .bss in the same boat, the correct
> way to limit them together is via SPL_MAX_FOOTPRINT. With the current
> SPL_TEXT_BASE, we couldn't limit even a very basic SPL to the first
> 128 KiB, and there is no technical reason to do so. Because of this,
> simply allow the SPL to use all SYSRAM.
> 
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>  include/configs/stm32mp1.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index 56a70cb584..440efa1a55 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -50,12 +50,12 @@
>  /* SPL support */
>  #ifdef CONFIG_SPL
>  /* SPL use DDR */
> -#define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>  #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
>  #define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
>  
> -/* limit SYSRAM usage to first 128 KB */
> -#define CONFIG_SPL_MAX_SIZE		0x00020000
> +/* Restrict SPL to fit within SYSRAM */
> +#define STM32_SYSRAM_END		(STM32_SYSRAM_BASE + STM32_SYSRAM_SIZE)
> +#define CONFIG_SPL_MAX_FOOTPRINT	(STM32_SYSRAM_END - CONFIG_SPL_TEXT_BASE)
>  #define CONFIG_SPL_STACK		(STM32_SYSRAM_BASE + \
>  					 STM32_SYSRAM_SIZE)
>  #endif /* #ifdef CONFIG_SPL */
> 
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

Thanks
Patrice

[PATCH 3/3] configs: stm32mp1: Fix misleading SPL size limitations

[Patrick DELAUNAY]

Hi,

On 3/22/21 2:20 PM, Alexandru Gagniuc wrote:
> A now removed comment promises to "limit SYSRAM usage to first 128 KB".
> This would imply that only SYSRAM from 0x2ffc0000 - 0x2ffe0000 would be
> used. This is not what happens at all.
>
> First, SPL_MAX_SIZE is referenced from SPL_TEXT_BASE, which on all
> existing configs is set to 0x2ffc2500, not SYSRAM_BASE (0x2ffc0000).
> Some of it is in the first 128 KiB and some of it is in the second
> 128 KiB chunk of SYSRAM.
>
> Second, SPL_MAX_SIZE, does not restrict the BSS size. While a valiant
> attempt is made via SPL_BSS_MAX_SIZE, the value of 0x00100000 is much
> larger than SYSRAM, and doesn't account for the non-BSS sections.
>
> Because we're putting the .text and .bss in the same boat, the correct
> way to limit them together is via SPL_MAX_FOOTPRINT. With the current
> SPL_TEXT_BASE, we couldn't limit even a very basic SPL to the first
> 128 KiB, and there is no technical reason to do so. Because of this,
> simply allow the SPL to use all SYSRAM.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>   include/configs/stm32mp1.h | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index 56a70cb584..440efa1a55 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -50,12 +50,12 @@
>   /* SPL support */
>   #ifdef CONFIG_SPL
>   /* SPL use DDR */
> -#define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>   #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
>   #define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
>   
> -/* limit SYSRAM usage to first 128 KB */
> -#define CONFIG_SPL_MAX_SIZE		0x00020000
> +/* Restrict SPL to fit within SYSRAM */
> +#define STM32_SYSRAM_END		(STM32_SYSRAM_BASE + STM32_SYSRAM_SIZE)
> +#define CONFIG_SPL_MAX_FOOTPRINT	(STM32_SYSRAM_END - CONFIG_SPL_TEXT_BASE)
>   #define CONFIG_SPL_STACK		(STM32_SYSRAM_BASE + \
>   					 STM32_SYSRAM_SIZE)
>   #endif /* #ifdef CONFIG_SPL */


Thanks for the analysis.


We don't revisit this part this the first STM32MP port on U-Boot

and CONFIG_SPL_MAX_FOOTPRINT is the correct way to limit the SPL size.


If I remember correctly, the 128KB limitation was only a attempt to reserved

enough SYSRAM for BSS + SPL stack located at CONFIG_SPL_STACK = end of 
sysram.



Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

Thanks


Patrick

[PATCH 3/3] configs: stm32mp1: Fix misleading SPL size limitations

[Patrice CHOTARD]

Hi Alexandru

On 3/22/21 2:20 PM, Alexandru Gagniuc wrote:
> A now removed comment promises to "limit SYSRAM usage to first 128 KB".
> This would imply that only SYSRAM from 0x2ffc0000 - 0x2ffe0000 would be
> used. This is not what happens at all.
> 
> First, SPL_MAX_SIZE is referenced from SPL_TEXT_BASE, which on all
> existing configs is set to 0x2ffc2500, not SYSRAM_BASE (0x2ffc0000).
> Some of it is in the first 128 KiB and some of it is in the second
> 128 KiB chunk of SYSRAM.
> 
> Second, SPL_MAX_SIZE, does not restrict the BSS size. While a valiant
> attempt is made via SPL_BSS_MAX_SIZE, the value of 0x00100000 is much
> larger than SYSRAM, and doesn't account for the non-BSS sections.
> 
> Because we're putting the .text and .bss in the same boat, the correct
> way to limit them together is via SPL_MAX_FOOTPRINT. With the current
> SPL_TEXT_BASE, we couldn't limit even a very basic SPL to the first
> 128 KiB, and there is no technical reason to do so. Because of this,
> simply allow the SPL to use all SYSRAM.
> 
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>  include/configs/stm32mp1.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index 56a70cb584..440efa1a55 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -50,12 +50,12 @@
>  /* SPL support */
>  #ifdef CONFIG_SPL
>  /* SPL use DDR */
> -#define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>  #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
>  #define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
>  
> -/* limit SYSRAM usage to first 128 KB */
> -#define CONFIG_SPL_MAX_SIZE		0x00020000
> +/* Restrict SPL to fit within SYSRAM */
> +#define STM32_SYSRAM_END		(STM32_SYSRAM_BASE + STM32_SYSRAM_SIZE)
> +#define CONFIG_SPL_MAX_FOOTPRINT	(STM32_SYSRAM_END - CONFIG_SPL_TEXT_BASE)
>  #define CONFIG_SPL_STACK		(STM32_SYSRAM_BASE + \
>  					 STM32_SYSRAM_SIZE)
>  #endif /* #ifdef CONFIG_SPL */
> 
Applied to u-boot-stm/master

Thanks
Patrice

[PATCH 1/3] configs: stm32mp1: stm32mp1: Increase SPL malloc() size

[Patrice CHOTARD]

Hi Alexandru

On 3/22/21 2:19 PM, Alexandru Gagniuc wrote:
> Since commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for
> loading images"), FIT images must be malloc()'d before being loaded.
> The old size of 1 MiB is suitable for FIT images with u-boot and an
> FDT, but something containing a linux kernel is almost sure to fail.
> 
> It's safe to extend malloc all the way to 0xc2000000, but no further.
> Linux likes to be loaded at 0xc2000000, so we use that as our cutoff
> point. This gives us 29 MiB of malloc() space, which suited for more
> complex FIT images including several DTBs, kernel, and OP-TEE images.
> 
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>  include/configs/stm32mp1.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index db2117a3d7..7fdb3ffce4 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -53,7 +53,7 @@
>  #define CONFIG_SPL_BSS_START_ADDR	0xC0200000
>  #define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>  #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
> -#define CONFIG_SYS_SPL_MALLOC_SIZE	0x00100000
> +#define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
>  
>  /* limit SYSRAM usage to first 128 KB */
>  #define CONFIG_SPL_MAX_SIZE		0x00020000
> 

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

Thanks
Patrice

[PATCH 1/3] configs: stm32mp1: stm32mp1: Increase SPL malloc() size

[Patrick DELAUNAY]

Hi,

On 3/22/21 2:19 PM, Alexandru Gagniuc wrote:
> Since commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for
> loading images"), FIT images must be malloc()'d before being loaded.
> The old size of 1 MiB is suitable for FIT images with u-boot and an
> FDT, but something containing a linux kernel is almost sure to fail.
>
> It's safe to extend malloc all the way to 0xc2000000, but no further.
> Linux likes to be loaded at 0xc2000000, so we use that as our cutoff
> point. This gives us 29 MiB of malloc() space, which suited for more
> complex FIT images including several DTBs, kernel, and OP-TEE images.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>   include/configs/stm32mp1.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index db2117a3d7..7fdb3ffce4 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -53,7 +53,7 @@
>   #define CONFIG_SPL_BSS_START_ADDR	0xC0200000
>   #define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>   #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
> -#define CONFIG_SYS_SPL_MALLOC_SIZE	0x00100000
> +#define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
>   
>   /* limit SYSRAM usage to first 128 KB */
>   #define CONFIG_SPL_MAX_SIZE		0x00020000


Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

Thanks
Patrick

[PATCH 1/3] configs: stm32mp1: stm32mp1: Increase SPL malloc() size

[Patrice CHOTARD]

Hi Alexandru

On 3/22/21 2:19 PM, Alexandru Gagniuc wrote:
> Since commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for
> loading images"), FIT images must be malloc()'d before being loaded.
> The old size of 1 MiB is suitable for FIT images with u-boot and an
> FDT, but something containing a linux kernel is almost sure to fail.
> 
> It's safe to extend malloc all the way to 0xc2000000, but no further.
> Linux likes to be loaded at 0xc2000000, so we use that as our cutoff
> point. This gives us 29 MiB of malloc() space, which suited for more
> complex FIT images including several DTBs, kernel, and OP-TEE images.
> 
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> ---
>  include/configs/stm32mp1.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index db2117a3d7..7fdb3ffce4 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -53,7 +53,7 @@
>  #define CONFIG_SPL_BSS_START_ADDR	0xC0200000
>  #define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
>  #define CONFIG_SYS_SPL_MALLOC_START	0xC0300000
> -#define CONFIG_SYS_SPL_MALLOC_SIZE	0x00100000
> +#define CONFIG_SYS_SPL_MALLOC_SIZE	0x01D00000
>  
>  /* limit SYSRAM usage to first 128 KB */
>  #define CONFIG_SPL_MAX_SIZE		0x00020000
> 

Applied to u-boot-stm/master

Thanks
Patrice