From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chee, Tien Fong Date: Tue, 19 Jun 2018 05:52:59 +0000 Subject: [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB In-Reply-To: <20180618165922.GI4609@bill-the-cat.ec.rr.com> References: <1528875163-22096-1-git-send-email-tien.fong.chee@intel.com> <20180618165922.GI4609@bill-the-cat.ec.rr.com> Message-ID: <1529387578.10031.14.camel@intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Mon, 2018-06-18 at 12:59 -0400, Tom Rini wrote: > On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.chee at intel.com > wrote: > > > > > From: Tien Fong Chee > > > > In ARM 64-bits, memory size can be supported is more than 4GB, > > hence increasing save array is needed to cope with testing larger > > memory. > > > > Signed-off-by: Tien Fong Chee > > --- > >  common/memsize.c |    2 +- > >  1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/common/memsize.c b/common/memsize.c > > index 5670e95..b091203 100644 > > --- a/common/memsize.c > > +++ b/common/memsize.c > > @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR; > >  long get_ram_size(long *base, long maxsize) > >  { > >   volatile long *addr; > > - long           save[31]; > > + long           save[BITS_PER_LONG]; > >   long           save_base; > >   long           cnt; > >   long           val; > Since BITS_PER_LONG is 32 or 64, shouldn't we use B_P_L - 1 here?  Or > are you saying there's also a case where this is wrong on 32bit > today? As long as the array is large enough to cope with shifting implementation, then it should be fine. For 32-bit, only 31 units in array required for storing 31 shifting values, and this apply for 64- bit also as long as the implementation of first shifting value is not change(cnt = (maxsize / sizeof(long)) >> 1). IMO, for simplifying and safety purpose(may be one day implementation change to "cnt = (maxsize / sizeof(long))", above B_P_L is still workable. > Thanks! >