* [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB @ 2018-06-13 7:32 tien.fong.chee at intel.com 2018-06-18 16:59 ` Tom Rini 0 siblings, 1 reply; 4+ messages in thread From: tien.fong.chee at intel.com @ 2018-06-13 7:32 UTC (permalink / raw) To: u-boot 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> --- 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; -- 1.7.7.4 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB 2018-06-13 7:32 [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB tien.fong.chee at intel.com @ 2018-06-18 16:59 ` Tom Rini 2018-06-19 5:52 ` Chee, Tien Fong 0 siblings, 1 reply; 4+ messages in thread From: Tom Rini @ 2018-06-18 16:59 UTC (permalink / raw) To: u-boot On Wed, Jun 13, 2018 at 03:32:43PM +0800, 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> > --- > 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? Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180618/600eb89a/attachment.sig> ^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB 2018-06-18 16:59 ` Tom Rini @ 2018-06-19 5:52 ` Chee, Tien Fong 2018-06-19 6:01 ` Marek Vasut 0 siblings, 1 reply; 4+ messages in thread From: Chee, Tien Fong @ 2018-06-19 5:52 UTC (permalink / raw) To: u-boot 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 <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> > > --- > > 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! > ^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB 2018-06-19 5:52 ` Chee, Tien Fong @ 2018-06-19 6:01 ` Marek Vasut 0 siblings, 0 replies; 4+ messages in thread From: Marek Vasut @ 2018-06-19 6:01 UTC (permalink / raw) To: u-boot On 06/19/2018 07:52 AM, Chee, Tien Fong wrote: > 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 <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> >>> --- >>> 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. That's BS reasoning and just sloppy programming. I agree with Tom. -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-06-19 6:01 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-06-13 7:32 [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB tien.fong.chee at intel.com 2018-06-18 16:59 ` Tom Rini 2018-06-19 5:52 ` Chee, Tien Fong 2018-06-19 6:01 ` Marek Vasut
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox