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

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090901134257.59961e79 at hskinnemoen-d830> you wrote:
>
> > > complexity (which can be kept to a minimum) localized to a handful of
> > > drivers, and don't change the command line interface or the board
> > > configuration interface.
> > 
> > We're not doing this. At least not intentionally.
> 
> Good. Then let's please put a stop to the madness of exposing virtual
> addresses all over the place.

But that's what we've been doing all the time. You just did not notice
it because of the usual 1:1 mapping.

On a 32 bit system with 36 bit physical addresses you cannot use a
physical address when running the "md" command, for example. we
always assumed that the 32 bit VA we used matched 1:1 to a PA with
the missing high bits set to 0, right?

> > The discussion we had was based on our knowledge about existing
> > systems, and needs to also handle more complex situations like for
> > example 32 bit systems with 36 bit physical addresses.
> 
> As far as I understand, the only difference for such systems is that
> keeping 64-bit physical addresses around are a bit more costly than
> passing around 32-bit virtual pointers. But presumably those systems
> have enough memory to make it a non-issue...

That's not true. There are 32 bit systems with bigger physical
address spaces. 


And note that this is not a new thing. We have been doing this allt
he time - just without ever explicitly mentioning it, because so far
nobody ever complained about it.

> > Agreed - assuming it is possible without hurting the majority of
> > other existing configurations.
> 
> Yes, that is indeed possible, as evidenced by the fact that it used to
> work without hurting any other configurations. It took another "special
> case" to break it.

My understanding is that the special case is yours - using a non-1:1
mapping.

> > discussions  with  Stefan Roese and Detlev Zundel it seems to me that
> > map_physmem() is probably not the right approach (judging  only  from
> > the  name).  We  should  not try to fix cache attributes by modifying
> > addresses / address maps
> 
> And why not? That's what Linux does, and it works wonderfully across 26
> different architectures.

We do not want to implement a full-fledged OS with virtual memory and
on-demand paging and all that stuff in U-Boot.

> > Instead, we should really extend the CFI driver such that it does not
> > matter if the addresses you are passing refer to cached or uncached
> > memory, and then provide hooks in the CFI driver to allow for testing
> > if cache is enabled, and switching cache off if it is.
> 
> What's the advantage of such an approach? It sounds much more
> complicated from the driver's point of view as well.

The advantage is that other drivers with similar needs can use it as
well.

> > To me such an approach makes much more sense, as it  is  generic  and
> > can be used by other drivers and other architectures - even if it may
> > come at the cost of more effort on your systems.
> 
> In what way is it more generic? In what way can map/unmap_physmem() not
> be used with other drivers and architectures?

On other architectures it is not possible to map the same memory area
multiple times with different attributes.  Remapping  addresses  thus
cannot  help  -  you  really  have  to  switch  the  MMO resp. memory
controller setinngs to turn data cache on or off.

> > Well, but board/atmel/atstk1000/flash.c _is_ a proprietary driver for
> > some flash chips that seem to be CFI conformant at first glance.  You
> > would not get such a driver into mailine any more. 
> 
> So I guess dropping support for ATNGW100 is the only remaining option?

No, why? We're discussing ways to fix the problems, aren;t we?

> At least STK1000 has a working flash driver.

Only because it was added so long ago, before we were more consequent
about using the generic driver. 

It would be a good idea to clean up this board  support,  remove  the
proprietary  flash driver and use the CFI driver instead. Patches are
welcome.

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
I will also, for an appropriate fee, certify that  your  keyboard  is
object-oriented,  and  that  the bits on your hard disk are template-
compatible.            - Jeffrey S. Haemer in <411akr$3ga at cygnus.com>