All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test
Date: Thu, 20 May 2010 17:00:50 -0500	[thread overview]
Message-ID: <1274392850.18152.253.camel@petert> (raw)
In-Reply-To: <20100520203251.D1BA6CCF026@gemini.denx.de>

Hi Wolfgang,

> > 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.

I didn't express it well, but what I was getting at was that the
"Testing X .. Y" would ideally state exactly what is being tested.
Unaligned addresses would still be allowed.  I think right now the end
address is always automatically aligned to the same alignment as the
start address though, so the current output is very misleading.

eg:
mw.l 0x1000 0x12345678 0x1000
mtest 0x1003 0x1ffc 1 1
Testing 00001003 ... 00001ffc:
...
md 0x1000 10; md 0x1ff0 10
00001000: 12345600 00000000 00000000 00000000    .4V.............
00001010: 00000000 00000000 00000000 00000000    ................
00001020: 00000000 00000000 00000000 00000000    ................
00001030: 00000000 00000000 00000000 00000000    ................
00001ff0: 00000000 00000000 00000000 00000078    ...............x
00002000: 12345678 12345678 12345678 12345678    .4Vx.4Vx.4Vx.4Vx
00002010: 12345678 12345678 12345678 12345678    .4Vx.4Vx.4Vx.4Vx
00002020: 12345678 12345678 12345678 12345678    .4Vx.4Vx.4Vx.4Vx

You can see the starting alignment was respected, but the ending
alignment was truncated to be 32-bit aligned to the starting address.
In the above example, I think it would be nice to see "Testing
00001003 ... 00001ffe".  Or some other way such that the user knows that
their input wasn't executed to a T; their end address was truncated.

Best,
Peter

  reply	other threads:[~2010-05-20 22:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-20 17:08 [U-Boot] [PATCH] mtest: Fix end address of increment/decrement test Peter Tyser
2010-05-20 18:43 ` Wolfgang Denk
2010-05-20 19:07   ` Peter Tyser
2010-05-20 19:44     ` Wolfgang Denk
2010-05-20 20:11       ` Peter Tyser
2010-05-20 20:32         ` Wolfgang Denk
2010-05-20 22:00           ` Peter Tyser [this message]
2010-05-20 22:07             ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1274392850.18152.253.camel@petert \
    --to=ptyser@xes-inc.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.