[PATCH] boardf: Modify DRAM message

[Tom Rini]

On Mon, Oct 14, 2024 at 10:10:43AM +0530, Neha Malcom Francis wrote:
> Hi Andrew
> 
> On 11/10/24 01:59, Andrew Davis wrote:
> > On 10/10/24 1:50 PM, Simon Glass wrote:
> > > Hi Neha,
> > > 
> > > On Thu, 10 Oct 2024 at 01:09, Neha Malcom Francis <n-francis at ti.com> wrote:
> > > > 
> > > > The message "DRAM:  2 GiB (effective 32 GiB)" can be a little confusing,
> > > > modify the message to show exactly what is meant:
> > > > 
> > > > "DRAM:  2 GiB (available for U-Boot out of total 32 GiB)"
> > > > 
> > > > Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> > > > ---
> > > >   common/board_f.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/common/board_f.c b/common/board_f.c
> > > > index 154675d0e40..b7add8f7d3d 100644
> > > > --- a/common/board_f.c
> > > > +++ b/common/board_f.c
> > > > @@ -254,7 +254,7 @@ static int show_dram_config(void)
> > > > 
> > > >          print_size(gd->ram_size, "");
> > > >          if (!sizes_near(gd->ram_size, size)) {
> > > > -               printf(" (effective ");
> > > > +               printf(" (available for U-Boot out of total ");
> > > >                  print_size(size, ")");
> > > >          }
> > > >          board_add_ram_info(0);
> > > > -- 
> > > > 2.34.1
> > > > 
> > > 
> > > I've forgotten why the first number can be so much lower than the
> > > second. What is causing that?
> > > 
> > > This is quite a long string...could we say "(total 32 GiB)" ? Then
> > > perhaps add something to doc/ to talk about the banner that U-Boot
> > > prints?
> > > 
> > 
> > Why not just only print the total number? The amount available to
> > U-Boot seems like an internal detail, I'd guess most folks just what
> > to see at a glance how much DDR was detected on their system.
> > 
> 
> Looking at the git history of this line, seems like we were printing U-Boot
> available size first and then modified it to show the entire DRAM available
> as "effective size"... quite possibly directly showing the total is a better
> idea.
> 
> Unless anyone has any reason to have this detail?

There's probably more history as well, but not totally relevant these
days. Some solution that starts from "most SoCs are 64bit and can easily
address all memory" and goes from there to not grow the overall U-Boot
binary much would be good.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241014/11e019ff/attachment.sig>