[U-Boot] [PATCH v3] board_init: Change the logic to setup malloc_base

[U-Boot] [PATCH v3] board_init: Change the logic to setup malloc_base

[Fabio Estevam]

Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
global_data setup") we used to have assembly code that configured the
malloc_base address.

Since this commit we use the board_init_f_mem() function in C to setup
malloc_base address.

In board_init_f_mem() there was a deliberate choice to support only 
early malloc() or full malloc() in SPL, but not both. 

Adapt this logic to allow both to be used, one after the other, in SPL.

This issue has been observed in a Congatec board, where we need to
retrieve the manufacturing information from the SPI NOR (the SPI API 
calls malloc) prior to configuring the DRAM. In this case as malloc_base
was not configured we always see malloc to fail.

With this change we are able to use malloc in SPL prior to DRAM gets 
initialized.

Also update the CONFIG_SYS_SPL_MALLOC_START entry in the README file.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v2:
- Combine two patches into one (Albert)

 README                   | 3 +++
 common/init/board_init.c | 3 +--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/README b/README
index ef8d437..92d36e6 100644
--- a/README
+++ b/README
@@ -3568,6 +3568,9 @@ FIT uImage format:
 
 		CONFIG_SYS_SPL_MALLOC_START
 		Starting address of the malloc pool used in SPL.
+		When this option is set the full malloc is used in SPL and
+		it is set up by spl_init() and before that, the simple malloc()
+		can be used if CONFIG_SYS_MALLOC_F is defined.
 
 		CONFIG_SYS_SPL_MALLOC_SIZE
 		The size of the malloc pool used in SPL.
diff --git a/common/init/board_init.c b/common/init/board_init.c
index e74b63b..1c6126d 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -50,8 +50,7 @@ ulong board_init_f_mem(ulong top)
 #endif
 	arch_setup_gd(gd_ptr);
 
-#if defined(CONFIG_SYS_MALLOC_F) && \
-	(!defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYS_SPL_MALLOC_START))
+#if defined(CONFIG_SYS_MALLOC_F)
 	top -= CONFIG_SYS_MALLOC_F_LEN;
 	gd->malloc_base = top;
 #endif
-- 
1.9.1

[U-Boot] [PATCH v3] board_init: Change the logic to setup malloc_base

[Simon Glass]

On 12 November 2015 at 07:30, Fabio Estevam <fabio.estevam@freescale.com> wrote:
> Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
> global_data setup") we used to have assembly code that configured the
> malloc_base address.
>
> Since this commit we use the board_init_f_mem() function in C to setup
> malloc_base address.
>
> In board_init_f_mem() there was a deliberate choice to support only
> early malloc() or full malloc() in SPL, but not both.
>
> Adapt this logic to allow both to be used, one after the other, in SPL.
>
> This issue has been observed in a Congatec board, where we need to
> retrieve the manufacturing information from the SPI NOR (the SPI API
> calls malloc) prior to configuring the DRAM. In this case as malloc_base
> was not configured we always see malloc to fail.
>
> With this change we are able to use malloc in SPL prior to DRAM gets
> initialized.
>
> Also update the CONFIG_SYS_SPL_MALLOC_START entry in the README file.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v2:
> - Combine two patches into one (Albert)
>
>  README                   | 3 +++
>  common/init/board_init.c | 3 +--
>  2 files changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Thanks!

- Simon

[U-Boot] [U-Boot, v3] board_init: Change the logic to setup malloc_base

[Tom Rini]

On Thu, Nov 12, 2015 at 12:30:19PM -0200, Fabio Estevam wrote:

> Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
> global_data setup") we used to have assembly code that configured the
> malloc_base address.
> 
> Since this commit we use the board_init_f_mem() function in C to setup
> malloc_base address.
> 
> In board_init_f_mem() there was a deliberate choice to support only 
> early malloc() or full malloc() in SPL, but not both. 
> 
> Adapt this logic to allow both to be used, one after the other, in SPL.
> 
> This issue has been observed in a Congatec board, where we need to
> retrieve the manufacturing information from the SPI NOR (the SPI API 
> calls malloc) prior to configuring the DRAM. In this case as malloc_base
> was not configured we always see malloc to fail.
> 
> With this change we are able to use malloc in SPL prior to DRAM gets 
> initialized.
> 
> Also update the CONFIG_SYS_SPL_MALLOC_START entry in the README file.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151112/5506c589/attachment.sig>

[U-Boot] [U-Boot, v3] board_init: Change the logic to setup malloc_base

[Tom Rini]

On Thu, Nov 12, 2015 at 12:30:19PM -0200, Fabio Estevam wrote:

> Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
> global_data setup") we used to have assembly code that configured the
> malloc_base address.
> 
> Since this commit we use the board_init_f_mem() function in C to setup
> malloc_base address.
> 
> In board_init_f_mem() there was a deliberate choice to support only 
> early malloc() or full malloc() in SPL, but not both. 
> 
> Adapt this logic to allow both to be used, one after the other, in SPL.
> 
> This issue has been observed in a Congatec board, where we need to
> retrieve the manufacturing information from the SPI NOR (the SPI API 
> calls malloc) prior to configuring the DRAM. In this case as malloc_base
> was not configured we always see malloc to fail.
> 
> With this change we are able to use malloc in SPL prior to DRAM gets 
> initialized.
> 
> Also update the CONFIG_SYS_SPL_MALLOC_START entry in the README file.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151118/d377720e/attachment.sig>