* [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.