* [U-Boot] P2020 SPL L2 clearing
@ 2011-02-03 13:17 Fabian Cenedese
2011-02-07 10:22 ` Fabian Cenedese
0 siblings, 1 reply; 7+ messages in thread
From: Fabian Cenedese @ 2011-02-03 13:17 UTC (permalink / raw
To: u-boot
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 mpx85xx 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).
2. Why does the cache to be cleared@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.
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.
Thanks
bye Fabi
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] P2020 SPL L2 clearing
2011-02-03 13:17 [U-Boot] P2020 SPL L2 clearing Fabian Cenedese
@ 2011-02-07 10:22 ` Fabian Cenedese
2011-02-08 16:55 ` Kumar Gala
0 siblings, 1 reply; 7+ messages in thread
From: Fabian Cenedese @ 2011-02-07 10:22 UTC (permalink / raw
To: u-boot
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).
>
>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.
>
>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?
Thanks
bye Fabi
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] P2020 SPL L2 clearing
2011-02-07 10:22 ` Fabian Cenedese
@ 2011-02-08 16:55 ` Kumar Gala
2011-02-09 8:06 ` Fabian Cenedese
2011-02-11 14:34 ` Fabian Cenedese
0 siblings, 2 replies; 7+ messages in thread
From: Kumar Gala @ 2011-02-08 16:55 UTC (permalink / raw
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] P2020 SPL L2 clearing
2011-02-08 16:55 ` Kumar Gala
@ 2011-02-09 8:06 ` Fabian Cenedese
2011-02-09 16:18 ` Kumar Gala
2011-02-11 14:34 ` Fabian Cenedese
1 sibling, 1 reply; 7+ messages in thread
From: Fabian Cenedese @ 2011-02-09 8:06 UTC (permalink / raw
To: u-boot
>>> 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).
>>>
>>> 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.
I can try that too and see how it goes. I will test this for my board
and send a patch once I get my way around git (didn't use it so far).
>>> 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.
Isn't this an optional feature? Shouldn't this loop be enclosed in
# ifdef CONFIG_DDR_ECC or doesn't this apply to L2-SRAM?
Thanks
bye Fabi
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] P2020 SPL L2 clearing
2011-02-09 8:06 ` Fabian Cenedese
@ 2011-02-09 16:18 ` Kumar Gala
0 siblings, 0 replies; 7+ messages in thread
From: Kumar Gala @ 2011-02-09 16:18 UTC (permalink / raw
To: u-boot
On Feb 9, 2011, at 2:06 AM, Fabian Cenedese wrote:
>
>>>> 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).
>>>>
>>>> 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.
>
> I can try that too and see how it goes. I will test this for my board
> and send a patch once I get my way around git (didn't use it so far).
>
>>>> 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.
>
> Isn't this an optional feature? Shouldn't this loop be enclosed in
> # ifdef CONFIG_DDR_ECC or doesn't this apply to L2-SRAM?
No, its not optional for the L2 cache (especially when we are in SRAM mode). Its also independent of DDR ECC.
- k
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] P2020 SPL L2 clearing
2011-02-08 16:55 ` Kumar Gala
2011-02-09 8:06 ` Fabian Cenedese
@ 2011-02-11 14:34 ` Fabian Cenedese
2011-02-12 17:44 ` Kumar Gala
1 sibling, 1 reply; 7+ messages in thread
From: Fabian Cenedese @ 2011-02-11 14:34 UTC (permalink / raw
To: u-boot
>>> 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'm still trying to get my head around this. From looking at the code
this doesn't seem to be necessary. The ECC errors are disabled
before L2 is configured as SRAM:
cpu_init_f (NAND)
/* set MBECCDIS=1, SBECCDIS=1 */
out_be32(&l2cache->l2errdis,
(MPC85xx_L2ERRDIS_MBECC | MPC85xx_L2ERRDIS_SBECC));
/* set L2E=1 & L2SRAM=001 */
out_be32(&l2cache->l2ctl,
(MPC85xx_L2CTL_L2E | MPC85xx_L2CTL_L2SRAM_ENTIRE));
And these ECC disable bits are only cleared once the u-boot has
already been copied to RAM and L2 is really used as cache:
cpu_init_r
/* set MBECCDIS=0, SBECCDIS=0 */
clrbits_be32(&l2cache->l2errdis,
(MPC85xx_L2ERRDIS_MBECC |
MPC85xx_L2ERRDIS_SBECC));
So am I getting something wrong?
Thanks
bye Fabi
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] P2020 SPL L2 clearing
2011-02-11 14:34 ` Fabian Cenedese
@ 2011-02-12 17:44 ` Kumar Gala
0 siblings, 0 replies; 7+ messages in thread
From: Kumar Gala @ 2011-02-12 17:44 UTC (permalink / raw
To: u-boot
On Feb 11, 2011, at 8:34 AM, Fabian Cenedese wrote:
>
>>>> 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'm still trying to get my head around this. From looking at the code
> this doesn't seem to be necessary. The ECC errors are disabled
> before L2 is configured as SRAM:
>
> cpu_init_f (NAND)
> /* set MBECCDIS=1, SBECCDIS=1 */
> out_be32(&l2cache->l2errdis,
> (MPC85xx_L2ERRDIS_MBECC | MPC85xx_L2ERRDIS_SBECC));
>
> /* set L2E=1 & L2SRAM=001 */
> out_be32(&l2cache->l2ctl,
> (MPC85xx_L2CTL_L2E | MPC85xx_L2CTL_L2SRAM_ENTIRE));
>
> And these ECC disable bits are only cleared once the u-boot has
> already been copied to RAM and L2 is really used as cache:
>
> cpu_init_r
> /* set MBECCDIS=0, SBECCDIS=0 */
> clrbits_be32(&l2cache->l2errdis,
> (MPC85xx_L2ERRDIS_MBECC |
> MPC85xx_L2ERRDIS_SBECC));
>
> So am I getting something wrong?
Nope, I was reading that is enabling ECC, wasn't paying attention that its ERROR disable
So the clearing out isn't necessary.
- k
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-02-12 17:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-03 13:17 [U-Boot] P2020 SPL L2 clearing Fabian Cenedese
2011-02-07 10:22 ` Fabian Cenedese
2011-02-08 16:55 ` Kumar Gala
2011-02-09 8:06 ` Fabian Cenedese
2011-02-09 16:18 ` Kumar Gala
2011-02-11 14:34 ` Fabian Cenedese
2011-02-12 17:44 ` Kumar Gala
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.