[U-Boot] P2020 SPL L2 clearing

Kumar Gala galak at kernel.crashing.org
Tue Feb 8 17:55:10 CET 2011


On Feb 7, 2011, at 4:22 AM, Fabian Cenedese wrote:

> At 14:17 03.02.2011 +0100, Fabian Cenedese wrote:
>> Hi
>> 
>> I'm creating a SPL u-boot image for our board. In the file
>> arch/powerpc/cpu/mpc85xx/cpu_init_nand.c is the setup for
>> the L2 cache as SRAM. In the end is a loop that fills the
>> cache with 0 (512KB in this case).
>> 
>>       /* Initialize L2 SRAM to zero */
>>       l2srbar = (char *)CONFIG_SYS_INIT_L2_ADDR;
>>       for (i = 0; i < CONFIG_SYS_L2_SIZE; i++)
>>               l2srbar[i] = 0;
>> 
>> Two questions for this:
>> 
>> 1. Why is the access byte-wise and not dword-wise? This
>> is only for mpc85xx and I think they all can access the cache
>> with 32bits instead of just 8. That would speed up by factor 4
>> (confirmed in my tests with P2020).

No real reason, probably historic and no one noticed.  Patch welcome to change this to 32-bit accesses, not really sure why we just dont call memset.

>> 
>> 2. Why does the cache to be cleared at all? L2-SRAM is usually
>> just used to copy in the second part of the u-boot image, so
>> the 0s will be overwritten again anyway.

This needs to be done because we enable ECC.

>> I came to this loop because the board takes an awful long
>> time to boot up. I'm measuring now cpu ticks until board_init_r
>> (in the first part loader before the u-boot image gets loaded).
>> With this loop it takes about 4 seconds, without just 50 ms.
>> How come the L2 access is so slow? I already increased
>> the lb clock but that only helps "outside". Even if this loop
>> didn't need any time I'd still have the questions above.
> 
> I just wanted to ask again if somebody has any insight
> on this. Maybe Kumar?

Patch welcome to clean this up to be more efficient.

- k



More information about the U-Boot mailing list