[U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB
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;
On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.chee@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!
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@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!
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@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.
participants (4)
-
Chee, Tien Fong -
Marek Vasut -
tien.fong.chee＠intel.com
-
Tom Rini