On Fri, Mar 1, 2019 at 11:45 AM Marek Vasut <ma...@denx.de> wrote: > > On 3/1/19 11:37 AM, Simon Goldschmidt wrote: > > On Fri, Mar 1, 2019 at 11:30 AM Marek Vasut <ma...@denx.de> wrote: > >> > >> On 2/26/19 10:27 PM, Simon Goldschmidt wrote: > >>> To find out how big the early malloc heap must be in SPL, add a debug > >>> print statement that dumps its usage before switching to relocated heap > >>> in spl_relocate_stack_gd() via CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN. > >>> > >>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschm...@gmail.com> > >>> --- > >>> > >>> common/spl/spl.c | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/common/spl/spl.c b/common/spl/spl.c > >>> index 2e2af1b28e..88d4b8a9bf 100644 > >>> --- a/common/spl/spl.c > >>> +++ b/common/spl/spl.c > >>> @@ -728,6 +728,8 @@ ulong spl_relocate_stack_gd(void) > >>> > >>> #if defined(CONFIG_SPL_SYS_MALLOC_SIMPLE) && CONFIG_VAL(SYS_MALLOC_F_LEN) > >>> if (CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN) { > >>> + debug("SPL malloc() before relocation used 0x%lx bytes (%ld > >>> KB)\n", > >>> + gd->malloc_ptr, gd->malloc_ptr / 1024); > >> > >> Shouldn't this use %p ? > > > > Despite its name, 'gd->malloc_ptr' is of type 'unsigned long', so I > > think this is > > correct. After all, I only copied the code from other places where the heap > > usage is dumped, too. > > Isn't that broken on some arm64 systems then ? :)
I don't think it's broken for 'ptr' as that seems to be the offset into the malloc pool. Some 64-bit platforms migth have a problem with gd->malloc_base being unsigned long though - I don't know the size of unsigned long on arm64. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot