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

[Jerry Van Baren <gvb.uboot@gmail.com>]

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