[U-Boot] [PATCH] mtest: Fix end address of increment/decrement test

[Wolfgang Denk]

Dear Peter Tyser,

In message <1274386292.18152.119.camel at petert> you wrote:
> 
> The current output leaves a lot of interpretation up to the user.

Agreed. This is one of the typical commands that where never well
designed or even intnded for normal users, but serrved a purpose, and
found useful, so it stuck.  No surprise it has sharp edges ;-)

> It depends on interpretation.  eg:
> => mtest 0x1000 0x1ffd 1 1       
> Testing 00001000 ... 00001ffd:

To be honest - I wasn't even aware we support such a notation ;-)

> This is *really* testing bytes 0x1000-0x1fff.  It's impossible for Joe
> User to figure that out though...

...not without reading the source code, indeed. But then, this is
always a good excercise :-)

> As far as the output, my vote would be to align the end address to a
> 32-bit address and add 3.  eg assuming a starting address of 1000 and
> ending addresses of:
> 0x1ffc - output: Testing 00001000 ... 00001fff
> 0x1ffd - output: Testing 00001000 ... 00001fff
> 0x1ffe - output: Testing 00001000 ... 00001fff
> 0x1fff - output: Testing 00001000 ... 00001fff
> 0x2000 - output: Testing 00001000 ... 00002003
> 0x2001 - output: Testing 00001000 ... 00002003

No, please do not implement such automatic alignment; it may be useful
for some cases, but it may as well hurt, for example if you
intentionally want to run mtest with misalignment, like giving both
odd start and end addresses.

> Another possibility would be to replace the "end address" argument with
> a "size" argument.  So "mtest 0x1000 0x1000" would test 0x1000 bytes at
> address 0x1000, from 0x1000-0x1fff.  I think that would be clearer to
> most people, but the downside is you'd have to do some math to calculate
> the size parameter in some cases (eg testing the region after exception
> vectors, but before the U-Boot image in RAM).

I think it is more difficult to calculate the sizes instead of the end
addresses.

> Let me know what you think about how to display the tested memory
> region.  I'm fine with leaving the "end addr" vs "size" debate for the
> next release, if at all.

I always appreciate is someone is thorough and willing enough to clean
up such old mess.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                           -- H. L. Mencken