[U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

On Sat, 29 Aug 2009 13:39:02 +0200
Stefan Roese <sr at denx.de> wrote:
> I think too, that revering the patch in question is not the right
> "solution" for this problem in the current stage. But I have to admit
> that I don't have enough insight into your platform to come up with
> another good idea quickly.

Yeah, I only meant to suggest it as one possible solution, with this
patch being one other, less intrusive but also less complete, solution.

And I'm not really even opposed to the patch in question, I just need
to know how I should configure my systems from now on since all of a
sudden, some addresses are supposed to be virtual while others are
physical, and it doesn't seem to be documented anywhere what should be
used where.

> > > So...which config symbols are supposed to be virtual now, and how
> > > are you supposed to know how the virtual-to-physical mappings are
> > > set up in
> > > advance?
> >
> > Everything is treated as virtual unless it's being used for hardware
> > setup.  If you use something to do memory accesses, it's virtual.  A
> > lot of code had been just using the PA as a VA, because things were
> > always mapped 1-1.
> 
> Correct. All those addresses to configure the CFI driver should be
> virtual addresses.

That cannot possibly be true, as the start address of the flash is
passed to physmem_map().

It is also an absolutely idiotic thing to do since on any CPU with
a MMU, the virtual address can be anything, so locking all the
configuration symbols to specific virtual addresses would effectively
lock down the MMU configuration forever (and I imagine that would be a
particularly nasty problem on hardware with more physical address bits
than virtual.)

> > Can you point me at an example in your scenario of code that
> > interacts with the flash?
> 
> Yes, please give us an example of your memory mapping (physical and
> virtual) on your failing platform.

CFI-compatible flash at physical address 0. By default, all virtual
addresses up to 2GB are mapped 1:1 with caching enabled (when paging
is enabled, which it isn't in u-boot, this area is translated through
the MMU.) Then, virtual address 0x80000000..0x9fffffff is mapped to
0x0..0x1fffffff with caching enabled (supervisor-only and not translated
even with paging enabled; this is where the Linux kernel is mapped).
Then, virtual address 0xa0000000..0xbfffffff is mapped to
0x0..0x1fffffff with caching disabled -- this is where we want to access
the flash and other external hardware. Then there's another paged
region and finally a 512MB uncached, direct-mapped region for accessing
internal peripherals.

So the problem is that even though we may read from the flash using the
physical address as virtual address, we cannot initialize, erase or
write it using those addresses. Hence the need for map_physmem().

Haavard