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

Haavard Skinnemoen
2009-09-01T08:57:52Z

Wolfgang Denk <wd@denx.de> wrote:
> Dear Haavard Skinnemoen,
>
> In message <20090831155327.62b58f8f@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