> > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
