[U-Boot] Enabling Cache in SPL - how to speed up booting from SPL

[U-Boot] Enabling Cache in SPL - how to speed up booting from SPL

[Stefano Babic]

Hi,

because we are fast able to boot the kernel directly from SPL, I am
experimenting now how we can speed up the process. Mainly my focus is
how to make copy from storage (=NAND) to RAM faster.

There are two approaches I can see: using DMA in NAND driver, or/and
enabling cache. I have not yet patches (I hacked the code dirtly), but I
have some results I cannot understand.

First of all, DMA. DMA for OMAP is mainlined now with Simon's patches,
enabling DMA in nand_spl_simple.c as sent by Simon does not work for me,
but I have adapted the patch to my platform (twister board, mainlined,
with TI AM3517). Here the results measuring between start of the copy
and before giving the control to the kernel (kernel size is 2188100):

                                   Seconds
-----------------------------------------------------------------
No cache, no DMA                    1.700
DMA in NAND driver                  1.190
Enabling Cache                      2.120

With enabled DMA I won on my platform ~600mSec. However, enabling cache
is worse than disabling, and this let me really confused.

I have not done any special things to enable cache, and I reused code
already provided. I have only set to an arbitrary address in RAM (but
64KB aligned) gd->tbl, and then I called enable_caches(). I can see that
mmu_setup() is called, and at the end icache_status() and
dcache_status() return both that cache is enabled.

But copying from NAND takes longer enabling cache, and this does not
really make sense. Does anybody have an hint what I am missing ?

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] Enabling Cache in SPL - how to speed up booting from SPL

[Marek Vasut]

> Hi,
> 
> because we are fast able to boot the kernel directly from SPL, I am
> experimenting now how we can speed up the process. Mainly my focus is
> how to make copy from storage (=NAND) to RAM faster.
> 
> There are two approaches I can see: using DMA in NAND driver, or/and
> enabling cache. I have not yet patches (I hacked the code dirtly), but I
> have some results I cannot understand.
> 
> First of all, DMA. DMA for OMAP is mainlined now with Simon's patches,
> enabling DMA in nand_spl_simple.c as sent by Simon does not work for me,
> but I have adapted the patch to my platform (twister board, mainlined,
> with TI AM3517). Here the results measuring between start of the copy
> and before giving the control to the kernel (kernel size is 2188100):
> 
>                                    Seconds
> -----------------------------------------------------------------
> No cache, no DMA                    1.700
> DMA in NAND driver                  1.190
> Enabling Cache                      2.120
> 
> With enabled DMA I won on my platform ~600mSec. However, enabling cache
> is worse than disabling, and this let me really confused.
> 
> I have not done any special things to enable cache, and I reused code
> already provided. I have only set to an arbitrary address in RAM (but
> 64KB aligned) gd->tbl, and then I called enable_caches(). I can see that
> mmu_setup() is called, and at the end icache_status() and
> dcache_status() return both that cache is enabled.
> 
> But copying from NAND takes longer enabling cache, and this does not
> really make sense. Does anybody have an hint what I am missing ?

L2 is on too?

M

> 
> Best regards,
> Stefano Babic

[U-Boot] Enabling Cache in SPL - how to speed up booting from SPL

[Stefano Babic]

On 10/02/2012 13:28, Marek Vasut wrote:
>> Hi,
>>
>> because we are fast able to boot the kernel directly from SPL, I am
>> experimenting now how we can speed up the process. Mainly my focus is
>> how to make copy from storage (=NAND) to RAM faster.
>>
>> There are two approaches I can see: using DMA in NAND driver, or/and
>> enabling cache. I have not yet patches (I hacked the code dirtly), but I
>> have some results I cannot understand.
>>
>> First of all, DMA. DMA for OMAP is mainlined now with Simon's patches,
>> enabling DMA in nand_spl_simple.c as sent by Simon does not work for me,
>> but I have adapted the patch to my platform (twister board, mainlined,
>> with TI AM3517). Here the results measuring between start of the copy
>> and before giving the control to the kernel (kernel size is 2188100):
>>
>>                                    Seconds
>> -----------------------------------------------------------------
>> No cache, no DMA                    1.700
>> DMA in NAND driver                  1.190
>> Enabling Cache                      2.120
>>
>> With enabled DMA I won on my platform ~600mSec. However, enabling cache
>> is worse than disabling, and this let me really confused.
>>
>> I have not done any special things to enable cache, and I reused code
>> already provided. I have only set to an arbitrary address in RAM (but
>> 64KB aligned) gd->tbl, and then I called enable_caches(). I can see that
>> mmu_setup() is called, and at the end icache_status() and
>> dcache_status() return both that cache is enabled.
>>
>> But copying from NAND takes longer enabling cache, and this does not
>> really make sense. Does anybody have an hint what I am missing ?
> 
> L2 is on too?

As far as I have understood, I can disable L2 on TI-omap3 only if I set
CONFIG_SYS_L2CACHE_OFF, and this is not my case. And there should be
then any apparent difference between SPL and U-Boot by enabling the
cache (I mean, if L2 is off, is off also in u-boot). When U-boot runs, I
see only that enable_caches() is called after setting the page tables,
and that is enough in u-boot to get dcache working. I did the same in
SPL, but it seems really something is missing...

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================