[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