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

[Sughosh Ganu]

hi Christian,

On Thu Jan 12, 2012 at 01:03:05PM +0100, Christian Riesch wrote:
> Hi Sughosh,
> 
> On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu <urwithsughosh at gmail.com> 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.
> >
> > The V bit of the cp15's control register c1 is set to the value of
> > VINITHI on reset. Do not clear this bit by default, as there are SOC's
> > with no valid memory region at 0x0.
> >
> > Signed-off-by: Sughosh Ganu <urwithsughosh at gmail.com>
> > Cc: Albert Aribaud <albert.u.boot at aribaud.net>
> > ---
> >
> > Changes since V1
> > * Added arm926 keyword to the subject line
> > * Removed the superfluous setting of r0.
> > * Fixed the comment to reflect the fact that V is not being cleared
> 
> I did a few tests of this patch with the da850evm (on an AM1808
> experimenter's kit) and the calimain (on our custom board)
> configurations.
> 
> I used u-boot from git://git.denx.de/u-boot-ti.git master, head is
> 14023683951b9a2bd277e999b0798b4917aca5d5. On top of this I applied
> these three patches:
> 
> [U-Boot,1/2,V2] arm926: Flush the data cache before disabling it.
> http://patchwork.ozlabs.org/patch/135275/
> 
> [U-Boot,2/2,V4] Changes to move hawkboard to the new spl infrastructure
> http://patchwork.ozlabs.org/patch/135433/
> 
> [U-Boot,v2] arm, davinci: Add support for the Calimain board from
> OMICRON electronics
> http://patchwork.ozlabs.org/patch/135593/
> 
> First I compiled for the da850evm.
> make mrproper
> make da850evm_config
> make -j3 -s u-boot.ais
> 
> I flashed the resulting u-boot.ais to the SPI flash of the AM1808
> experimenter's kit:
> mono dvflashutils/OMAP-L138/GNU/sfh_OMAP-L138.exe -targetType AM1808
> -flashType SPI_MEM -p /dev/ttyUSB0 -flash_noubl ../u-boot/u-boot.ais
> And tried to boot -> SUCCESS
> 
> I also tried the TI way (using the ubl):
> mono dvflashutils/OMAP-L138/GNU/sfh_OMAP-L138.exe -targetType AM1808
> -flashType SPI_MEM -p /dev/ttyUSB0 -flash
> dvflashutils/OMAP-L138/GNU/ubl/ubl_AM1808_SPI_MEM.bin
> ../u-boot/u-boot.bin
> And tried to boot -> SUCCESS
> 
> Countercheck: I reverted patch "[U-Boot,1/2,V2] arm926: Flush the data
> cache before disabling it." and rebuilt
> git revert HEAD~2
> make mrproper
> make da850evm_config
> make -j3 -s u-boot.ais
> 
> Again I tried with ubl and without -> both worked -> SUCCESS
> 
> Since you state that problems arise with the AIS scripts I also did a
> test loading u-boot with an AIS.

<snip>

> I run
> mono dvflashutils/OMAP-L138/GNU/AISUtils/HexAIS_OMAP-L138.exe -ini
> da850evm.ini -o u-boot.ais
> program to flash and run -> SUCCESS
> 
> I undo the revert
> git reset --hard HEAD^
> and rebuild
> make mrproper
> make da850evm_config
> make -j3 -s u-boot.ais
> program and run -> SUCCESS
> 
> Similar tests with the calimain board were also successful.
> 
> Since all my tests were successful I wonder what issues did you have
> with the cache? Can you describe the problems you had? I think the
> difference is that you are booting from NAND and have an OMAP-L138,
> whereas I boot from SPI (on the da850evm) or from NOR (on calimain)
> and have an AM1808 on both boards, right?

  Thanks a lot for all the testing. One difference i think we have on
  these boards and hawkboard, is that on hawkboard, the rbl configures
  the memory and loads the target image(spl in this case) directly to
  the ram. Looking at da850evm's lds file, it looks like the spl
  gets loaded to the sram, configures dram and then copies u-boot to
  the target load address.

  I think the rbl is enabling the caches in case of hawkboard, and
  on loading spl, it causes a problem when the cache is invalidated
  instead of being flushed. I'm pretty sure this is the problem, as
  the hawkboard does not boot without this fix. Thanks for the time
  taken for doing such elaborate tests.

-sughosh