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

[Christian Riesch]

On Thu, Jan 12, 2012 at 2:53 PM, Sughosh Ganu <urwithsughosh at 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 <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.

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot