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

[Heiko Schocher <hs@denx.de>]

Hello Sughosh,

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

That is what I not understand, because, if the RBL really enables
the D-Cache, how could u-boot work, if it not disables it!

>   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.
> 
>> 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

:-( You maybe could read the interesting values, and store them some-
where, and print it later?

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

Yes, the fix is correct, but we should try to understand, what is
really the problem on your hw!

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany