PowerPC Cache Warning Help Request

[Sebastian Huber]

On 23/10/14 15:16, Joel Sherrill wrote:
>
>
> On October 23, 2014 1:52:47 AM PDT, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>> On 21/10/14 04:56, Gedare Bloom wrote:
>>> On Mon, Oct 20, 2014 at 5:11 PM, Peter Dufault<dufault at hda.com>
>> wrote:
>>>>>
>>>>>>> On Oct 20, 2014, at 16:47 , Joel
>> Sherrill<Joel.Sherrill at oarcorp.com>  wrote:
>>>>>>>
>>>>>>>>> However, should unimplemented versions return an error instead
>> of being
>>>>>>>>> a NOP?  That would force one to visit code that makes
>> assumptions.
>>>>>>>
>>>>>>> If this is OK for the mpc55xx, feel free to submit a patch
>> turning the warning off for it.
>>>>>>>
>>>>>>> I tend to agree that if I had a generic drive that wanted to
>> flush data cache and all we can do on a target is flush all, then
>> that's preferable to flushing nothing.
>>>>>>>
>>>>>>> If these are called from a cache test then we would end up with a
>> hard error instead of a warning in that test which makes the issue
>> worse.
>>>>>>>
>>>>>
>>>>> I'm flat-out, I can't do a proper job on this.  I couldn't have
>> told you that the MPC55XX had a unified cache before I checked this
>> morning, but I would have gotten the answer correct on a
>> multiple-choice question.
>>>>>
>>>>> I think that unimplemented operations should return errors and not
>> OK, forcing one to add an implementation when it is OK.  But the
>> MPC55XX and its cache works fine as long as you keep cache-flushing in
>> mind and flush it when you should, so I don't recommend anything be
>> changed in the next RTEMS release.
>>>>>
>>> +1
>>> What we should do is make sure any generic cache mgr functions that
>>> get called within RTEMS are all implemented (I recall there being
>>> some, they may be in score/cpu code though.) Then make the
>>> unimplemented calls be errors. If someone uses it without checking,
>>> they should get slapped for it.
>>
>> What do you mean with "return errors"?  Should this be a fatal error or
>> a
>> linker error?
>
> Let's take the simplest case. A CPU with no cache control. Empty stubs is the right implementation.
>
> Next up is just enable, disable and flush. Can we map those to more specialized methods. Is it ok and expected that disable data cache does all? Or flush flushes all.

What is the use case for a cache disable/enable at application level?  Most 
cache disable functions in the tree are broken.

The only useful cache manager functions I see is data cache flush/invalidate 
lines and instruction cache invalidate lines.

>
> My thinking is that there are probably tiers of cache capabilities and if we can define expected behavior of higher tier operations onto lower capability CPU models, then we have a good solution.
>
> I don't like any errors in this case because as Peter says the code works well enough for applications as is if it is being used. Injecting a fatal error would be breakage. Returning an error would (I think) take an API change which no code would look at.
>
>
>


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.