2017-07-27 12:44 GMT+02:00 Philipp Tomsich <philipp.toms...@theobroma-systems.com>: > > > On Mon, 24 Jul 2017, Andy Yan wrote: > >> Some platforms has very small sram to run spl code, so >> it may have no enough sapce for so much malloc pool before >> relocation in spl stage as the normal u-boot stage. >> Use CONFIG_VAL(SYS_MALLOC_F_LEN) to fit this condition. >> >> Signed-off-by: Andy Yan <andy....@rock-chips.com> >> Acked-by: Daniel Schwierzeck <daniel.schwierz...@gmail.com> >> Acked-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com> >> --- >> >> Changes in v3: >> - use CONFIG_VAL(), which suggested by Simon >> >> Changes in v2: None >> >> arch/mips/cpu/start.S | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S >> index d01ee9f..aa07654 100644 >> --- a/arch/mips/cpu/start.S >> +++ b/arch/mips/cpu/start.S >> @@ -60,8 +60,8 @@ >> sp, sp, GD_SIZE # reserve space for gd >> and sp, sp, t0 # force 16 byte alignment >> move k0, sp # save gd pointer >> -#ifdef CONFIG_SYS_MALLOC_F_LEN >> - li t2, CONFIG_SYS_MALLOC_F_LEN >> +#if CONFIG_VAL(SYS_MALLOC_F_LEN) >> + li t2, CONFIG_VAL(SYS_MALLOC_F_LEN) > > > With CONFIG_VAL(...) there should always be a value returned. > > Could we drop the #if guard around this, as the PTR_SUBU below will then an > identity transform (i.e. it will compute "sp = sp - 0")?
I don't see any advantage in it. This code is compiled with "set .noreorder" so the assembler can't optimize or eliminate the dummy instructions in case of "CONFIG_SYS_MALLOC_F_LEN = 0".Also there is another instruction below which also needs this guard. Thus it would be more consistent if both places use the same #if guard. > > >> PTR_SUBU \ >> sp, sp, t2 # reserve space for early malloc >> and sp, sp, t0 # force 16 byte alignment >> @@ -75,7 +75,7 @@ >> blt t0, t1, 1b >> PTR_ADDIU t0, PTRSIZE >> >> -#ifdef CONFIG_SYS_MALLOC_F_LEN >> +#if CONFIG_VAL(SYS_MALLOC_F_LEN) >> PTR_S sp, GD_MALLOC_BASE(k0) # gd->malloc_base offset >> #endif >> .endm >> > -- - Daniel _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
