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

[Haavard Skinnemoen]

Wolfgang Denk <wd at denx.de> wrote:
> Dear Haavard Skinnemoen,
> 
> In message <20090831155327.62b58f8f at hskinnemoen-d830> you wrote:
> >
> > Possibly. But it means even more effort and even larger code, so I'm
> > not exactly happy about it.
> 
> Really? Sorry if I'm asking dumb questions - I don't know  AVR32:  is
> it  true  that  stting  up a non-1:1 mapping for the NOR flash (i. e.
> what you are doing now) is easier (less code) than setting up  a  1:1
> mapping? What exactly are the reasons for this?

Like I explained in an earlier mail, the default setup includes a 1:1
mapping of the lowest addresses, but it's cacheable. The default setup
also includes an uncached mapping of the same memory at a higher
virtual address.

Yes, it is much easier (and smaller) to use the default virtual memory
layout than setting up paging (which involves several exception
handlers).

> > > Indeed I am, and intentionally, because this is a different topic. If
> > > your system requires to set up the MMU to enable  caching,  then  you
> > > are  supposed  to  do  it  in  a  way compatible with the rest of the
> > > software design, i. e. as transparently  as  possible.  None  of  the
> > > architectures  I  know resonably well have problems setting up a 1: 1
> > > address mapping even when the MMU is on (but I  have  to  admit  that
> > > AVR32 is not among these architectures).
> > 
> > I suspect quite a few other architectures run with caches disabled
> > because it's not safe to run with caches enabled with the current
> > software design.
> 
> Well, usually we run with IC on and  with  DC  off,  usually  because
> quite  a  number  of  drivers  and  other  code do not use proper I/O
> accessors yet, and/or because it's easier and  nobody  really  cares.
> For  example  on  PowerPC,  adding support for the data cache usually
> gives only a minimal performance boost.  This  may  be  different  on
> other architectures.

Ok, so the code is broken and nobody else cares?

I suppose I could disable the DC (which is a bit complicated, but
possible), but that would just add to the already high cost (in terms
of both code size and performance) of using common code (i.e. the CFI
driver), so I'm leaning towards a custom flash driver instead.

> > > Cache should not be relevant  at  all  when  defining  a  physcal  or
> > > virtual memory map.
> > 
> > Physical, no, but it's very common that the MMU defines caching
> > properties (enabled/disabled, writeback/writethrough, etc.)
> 
> Agreed. But it should be not so difficult to use the MMU to set up  a
> 1:1  mapping  if  you have to set up the MMU at all - or is there any
> problems with that which I'm not aware of?

Yes, there is: caching.

> > > Heh. If more  platforms had broken this rule we would probably have
> > > become aware of these violations earlier, and stopped them doing such
> > > naughty things ;-)
> > 
> > Seems like you think it's more important to follow arbitrary rules than
> > writing code that works well.
> 
> Keeping the code as simple as possible is not exactly an arbitrary
> rule. At least not for me.

As simple as possible, but no simpler...

Haavard