[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