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

[Aneesh V]

Hi Sughosh,

On Thursday 19 January 2012 12:23 PM, Sughosh Ganu wrote:
> On Tue Jan 17, 2012 at 08:27:58AM -0700, Tom Rini wrote:
>> On Mon, Jan 16, 2012 at 11:46 PM, Sughosh Ganu<urwithsughosh at gmail.com>  wrote:
>
>>>>>> 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.
>>>>
>>>> Putting my TI hat on, I've confirmed with the RBL folks that they
>>>> aren't turning on ICACHE/DCACHE.
>>>
>>>   Well, i'm not sure then why does the cache invalidation cause a
>>>   problem on my platform. Btw, will this patch be
>>>   accepted. Irrespective of the cache state on my board, it is not a
>>>   wrong fix, and moreover results in the booting of my board.
>>>
>>>   I haven't yet tried out reading the cache bit state in the spl. Will
>>>   try out this experiment in a day or two, and share the results.
>>
>> I think someone needs to look over this init code very carefully.  If
>> I can summarize from memory quickly, when we enable the
>> CP_CRITICAL_INITS code for everyone that exposed a problem on the
>> hawkboard that _looks_like_ DCACHE is enabled by RBL as changing the
>> code from doing an invalidate to a flush+invalidate fixes a problem.
>> But the manual says we should be doing flush+invalidate anyhow and the
>> RBL code is not turning on DCACHE.  Maybe we've got something else
>> being done not as the manual says and that's tickling another issue?
>
>    Tried a few things on my end.
>    * Read the D-cache value in the spl, and confirmed that the data
>      cache is indeed not enabled.

What is the value of the B bit in CP15 SCR register? I wonder if RBL is
doing all the IMB operations required after copying the SPL image and
before executing it. IMB is required for consistency between data and
instruction sides. For instance after copying the SPL, the memory and
instruction cache could be incoherent. So, instruction cache needs to
be invalidated. In fact more needs to be done and there is an entire
chapter in the ARM926EJS TRM that discusses this (Chapter 9 -
Instruction Memory Barrier). Here is the key excerpt:

9.2 IMB operation
To ensure consistency between data and instruction sides, you must take
the following
steps:
1. Clean the DCache
2. Drain the write buffer
3. Synchronize data and instruction streams in level two AHB subsystems
4. Invalidate the ICache on page 9-4
5. Flush the prefetch buffer on page 9-4.

Ideally RBL should be doing all this before jumping to SPL. But, I
wonder if anything is missing in RBL and was getting done as a
side-effect of your flush.

Just a thought. Do you care to try 2-5 in SPL and see if it makes any
difference?(and avoid 1. in fact 1 seems to be the least useful thing
in our case!)

>
>    * Enabled the data cache explicitly in cpu_init_crit, and booted
>      u-boot. u-boot comes up fine, and trying a ping switches off the
>      data cache with the warning message.

How are you enabling D-cache. Please note that just setting C bit
doesn't enable D-cache. MMU needs to be enabled (M bit) for D-cache to
be enabled. MMU in turn needs page-table. I wonder if you are doing all
this in cpu_init_crit()?

br,
Aneesh