[U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.

[Marek Vasut <marek.vasut@gmail.com>]

> > On Wed Jan 11, 2012 at 01:42:38PM +0100, Marek Vasut wrote:
> > > > On Wed Jan 11, 2012 at 11:47:27AM +0100, Marek Vasut wrote:
> > > > > > On Tue Jan 10, 2012 at 09:07:58PM +0100, Marek Vasut wrote:
> > > > > > > > The current implementation invalidates the cache instead of
> > > > > > > > flushing it. This causes problems on platforms where the
> > > > > > > > spl/u-boot is already loaded to the RAM, with caches enabled
> > > > > > > > by a first stage bootloader.
> > > > > > > 
> > > > > > > What platforms are affected?
> > > > > > > 
> > > > > >   It is causing a problem on the hawkboard, where the spl is
> > > > > >   loaded directly to the RAM by a rom bootloader. We did not see
> > > > > >   this earlier since cpu_init_crit was not getting called due to
> > > > > >   CONFIG_SKIP_LOWLEVEL_INIT.
> > > > > > 
> > > > > > -sughosh
> > > > > 
> > > > > I see ... why don't you directly load U-Boot to DRAM then ?
> > > > > 
> > > >   The rom bootloader(rbl) uses a different ecc layout from the one
> > > >   used by the davinci nand driver(u-boot and linux).
> > > 
> > > Can't you just tell the driver to use the correct ecc layout when
> > > flashing then?
> > > 
> >   Changing the ecc layout for a single board, hmm not sure. Using a
> >   spl instead does me no harm whatsoever -- I don't need to update the
> >   spl frequently in any case, and then can use the nand driver as is.
> 
> And how do you replace the SPL?
> 
> Either way, I think the correct approach is to allow the driver to handle
> the SPL update too.

Or rather -- to be able to load u-boot directly. It seems to be more correct 
solution. The SPL you're using is just a workaround and also you need to TI 
flasher to replace it, right ?
> 
> M
> 
> > -sughosh