[U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR
Haavard Skinnemoen
haavard.skinnemoen at atmel.com
Tue Sep 1 12:18:30 CEST 2009
Stefan Roese <sr at denx.de> wrote:
> On Tuesday 01 September 2009 10:57:52 Haavard Skinnemoen wrote:
> > > 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 wouldn't put it like this. The CFI driver assumes that the FLASH mapping is
> not cached. This makes perfect sense in my point of view.
Yes, and it can do that safely because it specifically asks for an
uncached address from map_physmem(). That part didn't actually change
with the patch in question -- the problem is that the address returned
by map_physmem() is now exposed through external interfaces -- it's not
just an internal implementation detail anymore.
> > 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.
>
> On some 440 platforms we configure the FLASH cached upon powerup, and disable
> the caching after relocating to SDRAM. So when the CFI driver is started, the
> FLASH is not cached any more, but we have the cache speedup upon relocation.
That's what I want to do as well! And I can actually do that as long as
the flash subsystem uses map_physmem() consistently.
Haavard
More information about the U-Boot
mailing list