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

Wolfgang Denk
2009-09-01T09:47:05Z

Dear Haavard Skinnemoen,

In message <20090901105752.5bb77fc0@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."