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

[Simon Glass]

Hi Pali,

On Fri, 9 Sept 2022 at 15:46, Pali Rohár <pali at kernel.org> wrote:
>
> 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.

OK

>
> > >
> > > 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).

Yes we are saying the same thing. It is %016x that I would object to.

Regards,
Simon