Skip to contentSkip to conversation

Enabling Cache in SPL - how to speed up booting from SPL

U-Boot Stefano Babic 2 participants 3 messages Feb 10, 2012

lore
Share & tools
lore
#0 lore raw

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

Signature · 5 lines
=====================================================================
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
=====================================================================
#1 lore raw
Quoted 25 lines

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.

Quoted 8 lines

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

Quoted 3 lines

Best regards,
Stefano Babic

#2 lore raw
Quoted 31 lines · Marek Vasut
Quoted 31 lines

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.

Quoted 4 lines
Quoted 2 lines

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

Signature · 5 lines
=====================================================================
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
=====================================================================