On Thu, Jan 12, 2012 at 2:53 PM, Sughosh Ganu <urwithsugh...@gmail.com> wrote: > On Thu Jan 12, 2012 at 01:03:05PM +0100, Christian Riesch wrote: >> 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. > > <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.
This is only true if the SPL is actually used. Have a closer look at my test report, I tested three different methods: 1) The first test was done with the SPL and yes, here the RBL loads the SPL into SRAM, initializes DDR memory and then copies u-boot.bin to DDR memory. 2) The second test was done with TI's UBL. Here, the RBL loads the UBL into SRAM, the UBL initializes DDR memory and then copies u-boot.bin to DDR memory. 3) The third test was done without SPL and without UBL: Here the DDR memory init is in the AIS, so in fact the RBL does memory initialization and then RBL loads u-boot.bin to DDR memory. This is the same case that you have on the hawkboard (only that you have the OMAP-L138 and NAND flash instead) and it works for me regardless of your patch. Christian > > 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 > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot