[PATCH 1/2] spl: make SYS_SPL_MALLOC depend on !(SPL_STACK_R && SPL_SYS_MALLOC_SIMPLE)

Tom Rini trini at konsulko.com
Tue Sep 19 23:25:42 CEST 2023


On Fri, Sep 15, 2023 at 07:50:49PM +0200, Rasmus Villemoes wrote:

> Currently, one can have both SYS_SPL_MALLOC=y and
> SPL_SYS_MALLOC_SIMPLE=y.
> 
> However, while the former does make board_init_r() in spl.c call
> mem_malloc_init(), that has no effect at all, because that just
> updates a few bookkeeping variables, but as the linker map shows, the
> latter setting has (as expected) caused most of dlmalloc.o to be
> garbage-collected. That is, those bookkeeping variables are not used
> for anything.
> 
> IOWs, with SYS_SPL_MALLOC=y and SPL_SYS_MALLOC_SIMPLE=y, the value of
> CONFIG_SYS_SPL_MALLOC_SIZE is irrelevant, and one still only has the
> small, SRAM-backed, malloc arena available.
> 
> Now I want to change that so that the mem_malloc_init() instead
> updates the gd->malloc* variables to point at the SDRAM area.
> 
> However, there's a small complication, namely when SPL_STACK_R=y is
> also in the mix. In that case, the "simple" malloc arena is indeed
> updated to point at the SDRAM area carved out of the new stack (see
> spl_relocate_stack_gd()). So that case works in the sense that one
> does get a "large" "simple" malloc arena (of size
> SPL_STACK_R_MALLOC_SIMPLE_LEN) - but CONFIG_SYS_SPL_MALLOC_SIZE is
> still irrelevant. Once I change the mem_malloc_init() logic, this
> would then break, because the gd->malloc* variables would be updated
> again. Also, it doesn't really make sense to allow the .config to
> essentially specify two different SDRAM-backed malloc arenas.
> 
> So since CONFIG_SYS_SPL_MALLOC and its dependent options are no-ops
> currently when SPL_STACK_R && SPL_SYS_MALLOC_SIMPLE, simply forbid
> that combination.
> 
> Simple grepping suggests that these boards/configs are affected, in
> that they become a tiny bit smaller, and the defconfig will need
> refreshing:
> 
>   am62ax_evm_r5_defconfig
>   am62x_evm_r5_defconfig
>   am64x_evm_a53_defconfig
>   am64x_evm_r5_defconfig
>   am65x_evm_a53_defconfig
>   am65x_hs_evm_a53_defconfig
>   iot2050_defconfig
>   j7200_evm_a72_defconfig
>   j721e_evm_a72_defconfig
>   j721s2_evm_a72_defconfig
>   j721s2_evm_r5_defconfig
>   verdin-am62_r5_defconfig

I've boot tested this on j721e and am65x evms, so it's likely true that
all of these platforms are fine.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230919/ed2891bd/attachment.sig>


More information about the U-Boot mailing list