[U-Boot-Users] disabling d-cache in 'bootelf' for QNX

[Rafal Jaworowski]

Josh Boyer wrote:
>>>> Yeah, after a second thought I tend to agree. Maybe the way to go is doing
>>>> data cache flush from within dcache_disable() properly i.e. bring it in for
>>>> arch variations that don't do it currently like 85xx... Actually to confirm
>>>> my observations I tested a working patch that flushes d-cache at
>>>> cache_disable() just like 86xx and it works for me, this is: my problems
>>>> disappear. Do you think this is a better option?
>>> Yes, I think this is the way to go. Please provide a patch and send it to the 
>>> 85xx maintainer. Best would be if you could check the other ARCH's (at least 
>>> PPC) for this dcache_disable() behaviour too.
>>>
>> I checked, and only 7xx/74xx, 86xx and 4xx do it properly. For all other PPC
>> variants cache_disable() does not flush d-cache before disabling it... So the
>> problem is quite widespread. I'll try to come up with something generic, but
>> am not sure if it'll fit every other variant.
> 
> Out of curiosity, how do you disable dcache on 44x?  The only way I
> know how to turn the cache off on 440 is to set the Guarded bit in the
> TLB entries.  There is no cache disable bit.
> 

I believe this is how "disabling" is achieved currently in U-Boot: the DRAM
region is TLB-mapped with the G bit set. But I was rather referring to
introducing a d-cache flush as a first step of dcache_disable() in cases it is
not there, and not re-working the disable sequence itself. 440 is special
about this and we probably have to live with d-cache being either always
present or "disabled" via G bit.

> (And from what I see, dcache_disable, icache_disable, and icache_enable
> all just simply return without doing anything on 440).
> 

I mistyped: it is 40x that does flushing before disabling d-cache; on 440, as
you say, there are stubs for these ops.

kind regards,
Rafal