Hi Sughosh, On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu <urwithsugh...@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 <urwithsugh...@gmail.com> > Cc: Albert Aribaud <albert.u.b...@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. This is my da850evm.ini [General] busWidth=8 BootMode=SPIMASTER crcCheckType=NO_CRC [PLLANDCLOCKCONFIG] PLL0CFG0 = 0x00180001 PLL0CFG1 = 0x00000205 PERIPHCLKCFG = 0x00000002 [EMIF3DDR] PLL1CFG0 = 0x15010001 PLL1CFG1 = 0x00000002 DDRPHYC1R = 0x000000C4 SDCR = 0x0A034622 SDTIMR = 0x184929C8 SDTIMR2 = 0xB80FC700 SDRCR = 0x00000406 CLK2XSRC = 0x00000000 [INPUTFILE] FILENAME=u-boot.bin LOADADDRESS=0xC1080000 ENTRYPOINTADDRESS=0xC1080000 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? Regards, Christian _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot