[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Becky Bruce]

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

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Jerry Van Baren]

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

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Andrew Dyer]

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

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Wolfgang Denk]

Dear Jerry,

In message <492DD314.7070700@gmail.com> you wrote:
> 
> How would xlat know which direction it is to translate?

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Wolfgang Denk]

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

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

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Jerry Van Baren]

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

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Andrew Dyer]

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

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot] Need input: Use Virtual address in commands; add translation/physical

[Wolfgang Denk]

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

-- 
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
Any technology distinguishable from magic is insufficiently advanced.