[U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.

[Aneesh V <aneesh@ti.com>]

On Friday 13 January 2012 11:08 PM, Sughosh Ganu wrote:
> hi Heiko,
>
> On Fri Jan 13, 2012 at 04:29:29PM +0100, Heiko Schocher wrote:
>> Hello Sugosh,
>>
>> Sughosh Ganu wrote:
>>> hi Christian,
>>>
>>> On Fri Jan 13, 2012 at 09:06:26AM +0100, Christian Riesch wrote:
>>>> Hi Sughosh,
>>>> I had a look at the patch and I tried to understand what's going on
>>>> here (I must confess that I didn't know anything about this cache
>>>> stuff).
>>>
>>>    Ok, thanks for taking time off to understand this issue.
>>>
>>>> On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu<urwithsughosh@gmail.com>  wrote:
>>>>> The current implementation invalidates the cache instead of flushing
>>>>> it. This causes problems on platforms where the spl/u-boot is already
>>>>> loaded to the RAM, with caches enabled by a first stage bootloader.
>>
>> Hmm.. how did u-boot work on such boards? How can u-boot work with D-Cache
>> enabled, if u-boot is not initializing it? (And I think, on davinci SoC
>> we have a none working uboot ethernet driver if d-cache is enabled too).
>> There must be a page_table in DRAM for using D-Cache in U-Boot, if u-boot
>> don't initialize it, it maybe overrides it ... or miss I something?
>
>    Well, there is some data in the cache, which if not flushed creates
>    problems on my board. I get the board to boot just by commenting out
>    cpu_init_crit call. My hypothesis that the D-cache is enabled is
>    simply because cache invalidation followed by cache disabling breaks
>    the board, while flushing it prior to disabling gets it to boot
>    fine. This(invalidation) would not have been a problem if the cache
>    was in the disabled state.

It would have affected if the state of dirty bits and valid bits are
not guaranteed at reset. But looks like cache entries are guaranteed to
be invalidated on reset in ARM926ejs per the spec (which is not the
case in ARMv7). In this case, I agree that flush shouldn't harm
anything ideally.

>
>>
>> Are you sure, the RBL enables the D-Cache on your board? Nevertheless,
>> I think, we must disable the D-Cache here with "cleaning" it (as your
>> patch did) instead only invalidating it, as current code did.
>
>    I am not sure, this is just my guess. By default, the caches are
>    disabled on reset, so the only possible source is the rbl. But I
>    don't have access to the rbl code to say for sure. Unfortunately i
>    also don't have JTAG or any other debugger to dig more into

I will be surprised too if D-cache is enabled by ROM code. But I agree
that your problem and the solution seems to indicate something like
that. To be sure can you check the value of CP15 System control
register on SPL entry? You are already reading it. Can you save it
somewhere and spit it out later?

>    this. But yes, like you mention, we must be cleaning the cache
>    before disabling it, so this fix is correct.

I think it will be good to add an invalidate of I-cache too. You have
replaced an invalidate of I & D cache with a flush of only D-cache.

br,
Aneesh