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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox