PowerPC Cache Warning Help Request

[Joel Sherrill]

On October 23, 2014 6:38:27 AM PDT, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>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.

Personally I don't see enable and disable used besides during BSP initialization.  Maybe disable when app starts if having trouble with a user provided driver. But much beyond that
>>
>> 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.
>>
>>
>>