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

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090901105752.5bb77fc0 at hskinnemoen-d830> you wrote:
>
> > 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.

You mean you want to have the same memory area mapped _twice_, once
cached and once (at another address) uncached?

Well, this obviously cannot be done with a plain 1:1 mapping. But
then: isn't that asking for trouble anyway? Or is there anything that
prevents you for example reading stale cached data after the memory
content has changed by accesses through the uncached mapping?

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

I don't see how paging comes into play here?

> > 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?

Broken? You might call it a design decision. This is a boot loader,
and simplicity of design and easy porting and board bring up are
usually higher rated that sequeezing out the last few percent of
performance. IIRC, on PowerPC the difference of running with DC
enabled or not is only in the 10% range or so.

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

If you want to run with data caches enabled by default, then it would
probably make more sense if you invested efforts in extending the CFI
driver to provide hooks / callbacks to (temporarily) switch of data
cache for the memory range in question. This wouls allow you to run
with DC enabled on the flash area, and still use the CFI driver.

Such changes will have it much easier to find their way into mainline
than adding a proprietary flash driver.

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
Status quo. Latin for "the mess we're in."