[PATCH 4/9] board_f: Fix printing gd->ram_size and gd->ram_top

[Pali Rohár]

On Friday 09 September 2022 12:20:57 Simon Glass wrote:
> Hi Pali,
> 
> On Fri, 9 Sept 2022 at 09:34, Pali Rohár <pali at kernel.org> wrote:
> >
> > Members gd->ram_size and gd->ram_top are of type phys_addr_t which does not
> > have to fit into ulong type. So cast them into unsigned long long.
> 
> Which board does this break?

Uff.. I'm not sure right now as I have this patch for months. Anyway,
looking at it I think the issue is with 36-bit powerpc stuff where
phys_addr_t is 64-bit, ulong is 32-bit and therefore ram_size can be up
to 64 GB. Of course addressable RAM maximally 4 GB. Anyway, there should
not be any break, this is just debug output.

> >
> > Fixes: 37dc958947ed ("global_data.h: Change ram_top type to phys_addr_t")
> > Signed-off-by: Pali Rohár <pali at kernel.org>
> > ---
> >  common/board_f.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/common/board_f.c b/common/board_f.c
> > index 15e442a0cf33..9e34fbee147e 100644
> > --- a/common/board_f.c
> > +++ b/common/board_f.c
> > @@ -325,7 +325,7 @@ static int setup_dest_addr(void)
> >         /*
> >          * Ram is setup, size stored in gd !!
> >          */
> > -       debug("Ram size: %08lX\n", (ulong)gd->ram_size);
> > +       debug("Ram size: %08llX\n", (unsigned long long)gd->ram_size);
> >  #if defined(CONFIG_SYS_MEM_TOP_HIDE)
> >         /*
> >          * Subtract specified amount of memory to hide so that it won't
> > @@ -345,7 +345,7 @@ static int setup_dest_addr(void)
> >         gd->ram_top = gd->ram_base + get_effective_memsize();
> >         gd->ram_top = board_get_usable_ram_top(gd->mon_len);
> >         gd->relocaddr = gd->ram_top;
> > -       debug("Ram top: %08lX\n", (ulong)gd->ram_top);
> > +       debug("Ram top: %08llX\n", (unsigned long long)gd->ram_top);
> >  #if defined(CONFIG_MP) && (defined(CONFIG_MPC86xx) || defined(CONFIG_E500))
> >         /*
> >          * We need to make sure the location we intend to put secondary core
> > --
> > 2.20.1
> >
> 
> Reviewed-by: Simon Glass <sjg at chromium.org>
> 
> This seems OK, as it still only shows 8 digits in most cases.

No? IIRC %08 prints at least 8 digits (not at most).