| Message ID | 20200606095813.325-1-xypron.glpk@gmx.de |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/1] arm: sunxi: increase SYS_MALLOC_F_LEN | expand |
Hi, On Sat, Jun 06, 2020 at 09:58:13AM +0000, Heinrich Schuchardt wrote: > The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any > additional drivers marked as DM_FLAG_PRE_RELOC are loaded before > relocation. > > CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image > verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. > > CONFIG_LOG=Y is another setting requiring additional early malloc > area, cf. log_init(). > > When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled > we see as output in main U-Boot > > alloc_simple() alloc space exhausted > > With this patch the default values of SYS_MALLOC_F_LEN and > SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000. > > Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de> Where is this SYS_MALLOC_F_LEN allocated from (in particular for the SPL). Is it from the SRAM? If so, on older SoCs, we probably don't have 8k to spare. Maxime -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200608/07211686/attachment.sig>
On 08/06/2020 09:02, Maxime Ripard wrote: > Hi, > > On Sat, Jun 06, 2020 at 09:58:13AM +0000, Heinrich Schuchardt wrote: >> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any >> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before >> relocation. >> >> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image >> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. >> >> CONFIG_LOG=Y is another setting requiring additional early malloc >> area, cf. log_init(). >> >> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled >> we see as output in main U-Boot >> >> alloc_simple() alloc space exhausted >> >> With this patch the default values of SYS_MALLOC_F_LEN and >> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000. Heinrich, many thanks for the debugging and the nice solution! >> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de> > > Where is this SYS_MALLOC_F_LEN allocated from (in particular for the > SPL). Is it from the SRAM? This is the value for U-Boot proper only, so it's taken from DRAM. There is CONFIG_SPL_SYS_MALLOC_F_LEN for the SPL, which we don't touch. So the SPL is safe. Cheers, Andre > > If so, on older SoCs, we probably don't have 8k to spare. > > Maxime >
On 6/8/20 11:07 AM, Andr? Przywara wrote: > On 08/06/2020 09:02, Maxime Ripard wrote: >> Hi, >> >> On Sat, Jun 06, 2020 at 09:58:13AM +0000, Heinrich Schuchardt wrote: >>> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any >>> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before >>> relocation. >>> >>> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image >>> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. >>> >>> CONFIG_LOG=Y is another setting requiring additional early malloc >>> area, cf. log_init(). >>> >>> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled >>> we see as output in main U-Boot >>> >>> alloc_simple() alloc space exhausted >>> >>> With this patch the default values of SYS_MALLOC_F_LEN and >>> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000. > > Heinrich, many thanks for the debugging and the nice solution! > >>> >>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de> >> >> Where is this SYS_MALLOC_F_LEN allocated from (in particular for the >> SPL). Is it from the SRAM? > > This is the value for U-Boot proper only, so it's taken from DRAM. There > is CONFIG_SPL_SYS_MALLOC_F_LEN for the SPL, which we don't touch. So the > SPL is safe. SPL_SYS_MALLOC_F_LEN and TPL_SYS_MALLOC_F_LEN default to SYS_MALLOC_F_LEN. I am not aware of any TPL usage for ARCH_SUNXI. So this patch affects all three variables. But we should explicitly set the SPL_SYS_MALLOC_F_LEN default if 0x2000 is too big for any board. I will send a new version of the patch. Best regards Heinich > > Cheers, > Andre > >> >> If so, on older SoCs, we probably don't have 8k to spare. >> >> Maxime >> >
diff --git a/Kconfig b/Kconfig index 0e7ccc0b07..13204e2384 100644 --- a/Kconfig +++ b/Kconfig @@ -146,7 +146,7 @@ config SYS_MALLOC_F_LEN default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \ ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \ ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \ - ARCH_LS1046A) + ARCH_LS1046A || ARCH_SUNXI) default 0x400 help Before relocation, memory is very limited on many platforms. Still,
The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any additional drivers marked as DM_FLAG_PRE_RELOC are loaded before relocation. CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC. CONFIG_LOG=Y is another setting requiring additional early malloc area, cf. log_init(). When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled we see as output in main U-Boot alloc_simple() alloc space exhausted With this patch the default values of SYS_MALLOC_F_LEN and SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000. Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de> --- Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.20.1