| Message ID | 1455039661-14242-1-git-send-email-eddy.petrisor@nxp.com |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
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
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; } }
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(-)