From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rafal Jaworowski <raj@semihalf.com>
Date: Thu, 03 Jan 2008 11:30:25 +0100
Subject: [U-Boot-Users] disabling d-cache in 'bootelf' for QNX
In-Reply-To: <200801031116.18392.sr@denx.de>
References: <477BCC7F.4030709@semihalf.com> <200801031116.18392.sr@denx.de>
Message-ID: <477CB941.2020001@semihalf.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Stefan,

you wrote:
>> Currently do_bootelf() disables data cache just before passing control to
>> the entry point:
>>
>>         /*
>>          * QNX images require the data cache is disabled.
>>          * Data cache is already flushed, so just turn it off.
>>          */
>>         if (dcache_status ())
>>                 dcache_disable ();
>>
>> With this piece of code present I'm seeing strange effects (corrupt data
>> access, hangs) in standalone apps running from the ELF envelope.
> 
> What platform are you testing on? PPC? If yes, which one?
> 

Yes, 85xx.

>> A pure 
>> binary made of this same ELF works without problems. Contrary to the
>> comment above, there's no quarantee in do_bootelf() code flow that all data
>> cache has been flushed and it seems there needs to be flush_data_cache()
>> executed before the disable.
> 
> dcache_disable() should flush the dcache itself before disabling it. At least 
> this is the implementation I have seen on 405 and IIRC other PPC platforms.
> 

Indeed, in certain cases it does actually (e.g. 86xx), but it's not uniform
unfortunatelly. In my case (85xx) dcache_disable() does not flush the cache
before disabling.

>> 1. Does it really hold true that QNX requires d-cache disabled upon passing
>> control to it?
>>
>> 2. If so, this is a custom QNX thing that belongs to do_bootm_qnxelf() and
>> should be handled there and not at the common ELF handling level.
> 
> Hmmm. I think that calling applications and especially OS'es is more safe with 
> caches disabled then with caches enabled.
> 

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?

kind regards,
Rafal