From: Jerry Van Baren <gvb.uboot@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Need input: Use Virtual address in commands; add translation/physical
Date: Wed, 26 Nov 2008 17:52:04 -0500 [thread overview]
Message-ID: <492DD314.7070700@gmail.com> (raw)
In-Reply-To: <CDB66AA7-C842-4FFE-A3A9-796DBE163D4A@freescale.com>
Hi Becky,
Becky Bruce wrote:
> Folks,
>
> We're going to be seeing more platforms with larger physical addresses
> (PA) than virtual addresses (VA) supported in u-boot, and this kind of
> ruins the current assumption inherent in much of u-boot that VA ==
> PA. On ppc, we've begin implementing the ability to actually
> translate VAs to PAs and vice-versa. But this brings up the question
> of, when I type an address on the command line, what exactly am I
> specifying? Is that a virtual address, or a physical address?
>
> Wolfgang and I talked about this on IRC a bit earlier, and what we're
> proposing is this:
[snip good discussion]
> - Initially, a xlat (or insert better name here) command-line command
> will be added to give you a PA given a VA, and vice-versa.
How would xlat know which direction it is to translate?
Thoughts:
vtop(virtual) returns physical
ptov(physical) returns virtual
or (see below thought on 0v / 0p)
xlat(0p1234) returns virtual
xlat(0v1234) returns physical
xlat(0x1234) returns physical (per convention from snipped discussion)
I'm not wild about xlat doing dual duty (I'm not wild about vtop/ptov
either but like it a little better). Shock but no awe. :-/
Question: Do we need a translation function?
> - Going forward, commands will be extended to take either a VA or PA
> at the command line, with the syntax for this TBD and per argument
> (i.e. if a command takes multiple addresses, each one can be either a
> va or pa, and they can be intermingled). The default will remain VA
> if no modifier is specified.
Thought:
0v6789ABCD is a virtual address (the value is interpreted as hex)
0p6789ABCD is a physical address
Of course "v" and "p" should be accepted in either case.
Kinda ugly, but fits into the 0x style conventions.
I haven't looked at the number parsing code to see how hard it would be
to squeeze this into it.
> Note that unless your platform actually has enabled configs with VA !=
> PA (which is just MPC8641D at the moment, as far as I know), things
> will look exactly the same as they always have.
>
> Comments? I'm looking for some consensus here before I spend my
> weekend writing a whole bunch of code.
Stuff face, write code. Does it get any better than that? ;-)
> Cheers,
> Becky
Have a great Thanksgiving,
gvb
next prev parent reply other threads:[~2008-11-26 22:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 22:11 [U-Boot] Need input: Use Virtual address in commands; add translation/physical Becky Bruce
2008-11-26 22:52 ` Jerry Van Baren [this message]
2008-11-26 23:18 ` Wolfgang Denk
2008-11-27 1:39 ` Jerry Van Baren
2008-11-26 23:12 ` Andrew Dyer
2008-11-26 23:22 ` Wolfgang Denk
2008-11-27 17:06 ` Andrew Dyer
2008-11-27 22:15 ` Wolfgang Denk
2008-11-27 6:31 ` Stefan Roese
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=492DD314.7070700@gmail.com \
--to=gvb.uboot@gmail.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.