[U-Boot] [PATCH] common/memsize.c: fix endless loop when saving
When cnt reaches 0, any shift operation will keep cnt=0, so the condition `cnt >= 0` doesn't make sense.
To fix this endless loop, we drop the useless condition and simply break the loop when cnt reaches 0.
Signed-off-by: Eddy Petrișor eddy.petrisor@nxp.com --- common/memsize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/memsize.c b/common/memsize.c index 5c0d279..a6af993 100644 --- a/common/memsize.c +++ b/common/memsize.c @@ -33,7 +33,7 @@ long get_ram_size(long *base, long maxsize) long size; int i = 0;
- for (cnt = (maxsize / sizeof(long)) >> 1; cnt >= 0; cnt >>= 1) { + for (cnt = (maxsize / sizeof(long)) >> 1; ; cnt >>= 1) { addr = base + cnt; /* pointer arith! */ sync(); save[i] = *addr; @@ -43,6 +43,7 @@ long get_ram_size(long *base, long maxsize) *addr = ~cnt; } else { *addr = 0; + break; } }
2016-02-09 19:41 GMT+02:00 Eddy Petrișor eddy.petrisor@nxp.com:
When cnt reaches 0, any shift operation will keep cnt=0, so the condition `cnt >= 0` doesn't make sense.
To fix this endless loop, we drop the useless condition and simply break the loop when cnt reaches 0.
This should fix the endless issue introduced by the previous patch 8e7cba048baae68ee0916a8f52b4304277328d5e
Hannes, can you confirm that with this patch the reported size is correct and the boot is normal again? I initially thought the size might be incorret due to some buggy HW I have (it has some unstable DDR settings, which lead to incorrect reports on my side initially).
Signed-off-by: Eddy Petrișor eddy.petrisor@nxp.com
common/memsize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/memsize.c b/common/memsize.c index 5c0d279..a6af993 100644 --- a/common/memsize.c +++ b/common/memsize.c @@ -33,7 +33,7 @@ long get_ram_size(long *base, long maxsize) long size; int i = 0;
for (cnt = (maxsize / sizeof(long)) >> 1; cnt >= 0; cnt >>= 1) {
for (cnt = (maxsize / sizeof(long)) >> 1; ; cnt >>= 1) { addr = base + cnt; /* pointer arith! */ sync(); save[i] = *addr;@@ -43,6 +43,7 @@ long get_ram_size(long *base, long maxsize) *addr = ~cnt; } else { *addr = 0;
break; } }-- 1.9.2.459.g68773ac
On 02/09/2016 06:55 PM, Eddy Petrișor wrote:
2016-02-09 19:41 GMT+02:00 Eddy Petrișor eddy.petrisor@nxp.com:
When cnt reaches 0, any shift operation will keep cnt=0, so the condition `cnt >= 0` doesn't make sense.
To fix this endless loop, we drop the useless condition and simply break the loop when cnt reaches 0.
This should fix the endless issue introduced by the previous patch 8e7cba048baae68ee0916a8f52b4304277328d5e
Hannes, can you confirm that with this patch the reported size is correct and the boot is normal again? I initially thought the size might be incorret due to some buggy HW I have (it has some unstable DDR settings, which lead to incorrect reports on my side initially).
Hi Eddy, the board does boot with this patch. But the reported memsize is wrong. 1GiB instead 256MiB.
So we need some v2 to get rid.
best regards, Hannes
Pe 10 feb. 2016 8:26 a.m., "Hannes Schmelzer" hannes@schmelzer.or.at a scris:
On 02/09/2016 06:55 PM, Eddy Petrișor wrote:
2016-02-09 19:41 GMT+02:00 Eddy Petrișor eddy.petrisor@nxp.com:
Hannes, can you confirm that with this patch the reported size is correct and the boot is normal again? I initially thought the size might be incorret due to some buggy HW I have (it has some unstable DDR settings, which lead to incorrect reports on my side initially).
Hi Eddy, the board does boot with this patch. But the reported memsize is wrong. 1GiB instead 256MiB.
So we need some v2 to get rid.
Taking into account the first version was reverted, would you be willing to test a reworked patch targeting v2016.05, (when I have it ready)?
best regards, Hannes
On 2016-02-10 18:30, Eddy Petrișor wrote:
Pe 10 feb. 2016 8:26 a.m., "Hannes Schmelzer" <hannes@schmelzer.or.at mailto:hannes@schmelzer.or.at> a scris:
On 02/09/2016 06:55 PM, Eddy Petrișor wrote:
2016-02-09 19:41 GMT+02:00 Eddy Petrișor <eddy.petrisor@nxp.com
mailto:eddy.petrisor@nxp.com>:
Hannes, can you confirm that with this patch the reported size is correct and the boot is normal again? I initially thought the size might be incorret due to some buggy HW I have (it has some unstable DDR settings, which lead to incorrect reports on my side initially).
Hi Eddy, the board does boot with this patch. But the reported memsize is wrong. 1GiB instead 256MiB.
So we need some v2 to get rid.
Taking into account the first version was reverted, would you be willing to test a reworked patch targeting v2016.05, (when I have it ready)?
Hi Eddy, for me - yes. But as Wolfgang said, the code is maybe already perfect :-) Do we really have here the need to tune this?
Pe 10 feb. 2016 7:58 p.m., "Hannes Schmelzer" hannes@schmelzer.or.at a scris:
On 2016-02-10 18:30, Eddy Petrișor wrote:
Taking into account the first version was reverted, would you be willing
to test a reworked patch targeting v2016.05, (when I have it ready)?
Hi Eddy, for me - yes. But as Wolfgang said, the code is maybe already perfect :-) Do we really have here the need to tune this?
I was looking at that code due to my hw's DDR issues and spent some time trying to understand why does it have duplicated code, and I assume I am not the only one nor will be the last one.
But to be honest, I think the better approach would be to do the change in 2 steps, first the upper block, then the bottom one.
Eddy
participants (3)
-
Eddy Petrișor -
Eddy Petrișor -
Hannes Schmelzer