[U-Boot] OMAP3 performance regression in 2011.12
Aneesh V
aneesh at ti.com
Tue Jan 17 16:18:38 CET 2012
On Tuesday 17 January 2012 08:21 PM, Måns Rullgård wrote:
> Aneesh V<aneesh at ti.com> writes:
>
>> Hi Joe,
>>
>> On Monday 09 January 2012 09:18 PM, Joe Woodward wrote:
>>
>>> If I take the 2011.12 uBoot release the kernel takes about twice the
>>> time to boot (compared to 2011.09), and the device is noticably
>>> slower.
>>>
>>> Then if I comment out the v7_out_cache_disable() line in cpu.c and
>>> rebuild uBoot then everything speeds up again.
>>>
>>> I thought the kernel would turn on the cache again too...
>>> [...]
>>> I did a bit of Googling and found:
>>> http://www.spinics.net/lists/arm-kernel/msg50064.html
>>> http://www.spinics.net/lists/arm-kernel/msg50083.html
>>>
>>> It may be that the kernel is re-enabling the L1 cache, but expecting
>>> L2 to be on?
>>
>> Ideally kernel should be enabling L2 too. But looks like L2 was enabled
>> by ROM code itself in OMAP3, but D-cache disabled globally. So, it gets
>> enabled as soon as the D-cache is enabled globally.
>>
>> L2$ in OMAP3 is a bit tricky. The cache is known to ARM but
>> enabling/disabling it and affecting secure entries needs ROM
>> assistance. So, while ARMv7 generic code can flush L2, we need OMAP
>> specific code to enable/disable it.
>
> On OMAP3 ES2 and later, the L2EN bit in the auxiliary control register
> is banked between secure and non-secure modes, so there is no need for
> ROM calls to enable/disable the L2$ on these chips.
>
Yes, but IIRC, there was an erratum around it in some ARM revisions (I
think 3430 ES2 was affected) and the workaround was to keep both the
banked bits at the same value always. So, to keep things simple and
working for all revisions, I try to change both together. In the U-Boot
code where this is done I have added a comment on this.
More information about the U-Boot
mailing list