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