From: Chee, Tien Fong <tien.fong.chee@intel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] common/memsize.c: Increase save array for supporting memory size > 4GB
Date: Mon, 2 Jul 2018 13:51:17 +0000 [thread overview]
Message-ID: <1530539476.9905.4.camel@intel.com> (raw)
In-Reply-To: <5e4698ee-a807-be7f-d143-3ad1a611c9fc@denx.de>
On Sat, 2018-06-23 at 05:29 +0200, Marek Vasut wrote:
> On 06/21/2018 08:31 AM, Chee, Tien Fong wrote:
> >
> > On Thu, 2018-06-21 at 06:34 +0200, Marek Vasut wrote:
> > >
> > > On 06/20/2018 09:06 AM, tien.fong.chee at intel.com wrote:
> > > >
> > > >
> > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > >
> > > > 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 <tien.fong.chee@intel.com>
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Change save array size to save[BITS_PER_LONG - 1]
> > > > ---
> > > > common/memsize.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/common/memsize.c b/common/memsize.c
> > > > index 5670e95..13b0047 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 - 1];
> > > > long save_base;
> > > > long cnt;
> > > > long val;
> > > >
> > > Does this work with LPAE systems, where bits per long == 32 and
> > > the
> > > address space is bigger ? Or with similar setups ? I mean, you
> > > can
> > > have
> > > >
> > > >
> > > > 4 GiB of RAM on 32bit system ...
> > This function is designed to work with 32bit or 64 bits system, for
> > example the argument such as maxsize can be 32bit or 64 bit, if
> > value
> > larger than 4GiB is passed as maxsize argument with 32bit system,
> > the
> > whole thing will go wrong.
> And what do you do when you identify a problem in mainline ? :-)
>
I have no idea at this moment, how about fixing the issue for save
array in 64-bit 1st?
next prev parent reply other threads:[~2018-07-02 13:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 7:06 [U-Boot] [PATCH v2] common/memsize.c: Increase save array for supporting memory size > 4GB tien.fong.chee at intel.com
2018-06-21 4:34 ` Marek Vasut
2018-06-21 6:31 ` Chee, Tien Fong
2018-06-23 3:29 ` Marek Vasut
2018-07-02 13:51 ` Chee, Tien Fong [this message]
2018-07-11 12:42 ` [U-Boot] [U-Boot, " Tom Rini
2018-07-11 12:48 ` Marek Vasut
2018-07-11 12:50 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1530539476.9905.4.camel@intel.com \
--to=tien.fong.chee@intel.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox