[U-Boot] Need input: Use Virtual address in commands; add translation/physical
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:
- The addresses taken as arguments to and printed out by current commands will be interpreted as virtual addresses. This will minimize the changes required to uboot to get this working, and allows command code to dereference the address given directly as a pointer - poking around the code, I believe this to be the more common case. This could really go either way - we could specify the physical address here, but I think that is more counter to the assumptions of the existing code. Having a VA is slightly awkward in some of the code - the flash code comes to mind, but the particular flash code I've looked at is so confused with VA vs PA that I don't think it really matters which way we go.
- 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.
- 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.
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.
Cheers, Becky
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
Dear Jerry,
In message 492DD314.7070700@gmail.com you wrote:
How would xlat know which direction it is to translate?
From the argument that is passed to it:
xlat 1234 or xlat 0x1234
are taken as VA's (see discussion about default address interpretation), so "xlat" will print the PA.
xlat 1234.p or xlat 0x1234.p
has a PA as argument, so it prints the VA.
Multiple arguments (even mixed) might be allowed, too, for example:
xlat 1234 1234.p 5678 5678.p
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)
Seems too complex for a simple mind like mine ;-)
Question: Do we need a translation function?
Define "need". It is certainly very useful, especially if things don;t work as expected and you want to check address translation.
See the "xlat" command in the BDI2000 - how often did you use that?
[Right, I didn't invent that name. I'm recycling used bits. Hope this is OK.]
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 tend to allow for suffixes, i. e. "6789ABCD" or "6789ABCD.v" are VAs, while "6789ABCD.p" is a PA.
To me, that is easier to read.
I haven't looked at the number parsing code to see how hard it would be to squeeze this into it.
Not really difficult.
Stuff face, write code. Does it get any better than that? ;-)
I'm an optimist, to yes, of course it does. The amount of code that needs to get written grows and grows. Enough work for all of us :-)
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Jerry,
In message 492DD314.7070700@gmail.com you wrote:
How would xlat know which direction it is to translate?
From the argument that is passed to it:
xlat 1234 or xlat 0x1234
are taken as VA's (see discussion about default address interpretation), so "xlat" will print the PA.
xlat 1234.p or xlat 0x1234.p
has a PA as argument, so it prints the VA.
Multiple arguments (even mixed) might be allowed, too, for example:
xlat 1234 1234.p 5678 5678.p
Ooo, I think the answer to that xlat would make my head hurt.
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)
Seems too complex for a simple mind like mine ;-)
Ah, we are on the same page here with xlat except I had spurious parenthesis (brain was working in C mode, not bash mode) and I used 0v/0p instead of .v .p.
[snip]
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 tend to allow for suffixes, i. e. "6789ABCD" or "6789ABCD.v" are VAs, while "6789ABCD.p" is a PA.
To me, that is easier to read.
Agreed. The .[0-9a-z] suffix is a convention already used by u-boot and is much more readable than my 0v and 0p proposal.
[snip]
Best regards,
Wolfgang Denk
Thanks, gvb
On Wed, Nov 26, 2008 at 4:11 PM, Becky Bruce becky.bruce@freescale.com 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:
- The addresses taken as arguments to and printed out by current
commands will be interpreted as virtual addresses. This will minimize the changes required to uboot to get this working, and allows command code to dereference the address given directly as a pointer - poking around the code, I believe this to be the more common case. This could really go either way - we could specify the physical address here, but I think that is more counter to the assumptions of the existing code. Having a VA is slightly awkward in some of the code - the flash code comes to mind, but the particular flash code I've looked at is so confused with VA vs PA that I don't think it really matters which way we go.
At least for MIPS, the VA is used exclusively. IIRC on ARM9 the MMU isn't initialized at all (or minimally).
- 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.
virt_to_phys and phys_to_virt?
- 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.
I would love to see memory addresses get parsed through a common routine - that would allow easily hooking in an arch/platform specific routine to filter out addresses that should be avoided.
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.
Pretty much all MIPS has this - everything is virtual and the top three bits specify how translation gets done. Several of the 8 possibilities boil down to 'replace the top three bits of VA with 0'. As an example, VA of 0xa0000000 is PA 0x0 (uncached), VA of 0x80000000 is PA 0x0 (cached).
As far as more physical address bits than virtual, the Au15x0 has 36 bit physical address, although IIRC the code in tree doesn't handle any peripherals that are outside the 'normal' range. For our board we have set up static TLB mappings for the regions we need and access them through VA space.
Comments? I'm looking for some consensus here before I spend my weekend writing a whole bunch of code.
don't forget some hooks to clear out the TLB/VM hardware and return the machine to an appropriate state before launching an image (depending on arch and image type).
Dear Andrew,
In message c166aa9f0811261512p273f56a8qa17d22b4d57523d3@mail.gmail.com you wrote:
- 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.
virt_to_phys and phys_to_virt?
C'me on, we actually have to *type* that command every now and then, so please let's chose a short name. "xlat" has the benefit that BDI users already know the it, it's short, and can probably be abbreviated as "xl" or so without risk of name collisions :-)
I would love to see memory addresses get parsed through a common routine - that would allow easily hooking in an arch/platform specific routine to filter out addresses that should be avoided.
U-Boot is not supposed to do any such filtering.
"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn
Best regards,
Wolfgang Denk
I would love to see memory addresses get parsed through a common routine - that would allow easily hooking in an arch/platform specific routine to filter out addresses that should be avoided.
U-Boot is not supposed to do any such filtering.
"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn
... followed later by ...
For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken
What about suicidal things like accessing a bus region that hangs the machine, hitting the one address that resets the whole thing? Yes, I know that's broken design, but hardware like that exists, and is not going to change because we wish it so.
Many times I've accidentally left some control character in the input stream or typed one too many or too few zeros, and the address gets parsed wrong, code accesses something it shouldn't and things lock up. I (sometimes) know what I'm doing, but I have customers who (sometimes) don't.
How about this - have a weak function or #ifdef/#endif to call out to a platform address checking routine (only on parsing an address, not every access), but only if an environment variable is set. That would leave the default way of things, but allow people who are distributing u-boot to others to try and make their system a bit more robust.
Dear Andrew,
In message c166aa9f0811270906p6252c2b5m26adaeab4f154b89@mail.gmail.com you wrote:
What about suicidal things like accessing a bus region that hangs the machine, hitting the one address that resets the whole thing? Yes, I know that's broken design, but hardware like that exists, and is not going to change because we wish it so.
No, it's not broken design - it may even be intentional.
And you may want to be able to test if the system really resets when you write to that address - and U-Boot shall allow this.
U-Boot really shall allow you to do all things.
Remember that the U-Boot user is not the average Johnny Loser who cannot write a signle line of code without all Eclipse and a bunch of other graphical tools on his system - U-Boot is for developers who bring up new hardware.
I (sometimes) know what I'm doing, but I have customers who (sometimes) don't.
Such customers are not supposed to be allowed access to the U-Boot console, right? Or they need adequate training. Would you let everybody in the cockpit of a A380?
How about this - have a weak function or #ifdef/#endif to call out to a platform address checking routine (only on parsing an address, not every access), but only if an environment variable is set. That would leave the default way of things, but allow people who are distributing u-boot to others to try and make their system a bit more robust.
That would be a restriction of the freedom of things you can do with U-Boot. We didn't have anything like that for the last 8+ years, and I still see no need for it.
Best regards,
Wolfgang Denk
Hi Becky,
On Wednesday 26 November 2008, Becky Bruce wrote:
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?
Just a comment: We are using 36bit addresses on 440 since a few years now. And it's only VA for the user right now and works quite well so far. The SoC peripherals for example usually are located at > 4GB on those chips. If possible we just truncate the upper 4 bits on the PA to get the VA. But this doesn't work in all cases of course. So again, the user only types VA'es.
It would be great though to add this ".p" feature to access PA'es as well.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
participants (5)
-
Andrew Dyer -
Becky Bruce -
Jerry Van Baren -
Stefan Roese -
Wolfgang Denk