Instruction cache for leon3

[Joel Sherrill]

PR1249 and the fix is committed.

Thanks for spotting this.

--joel

Joel Sherrill wrote:
> Jerry Needell wrote:
>   
>> Joel and all,
>> After a great deal of head scratching and and very odd behavior, I have 
>> found a very simple problem that needs to be corrected:
>> in c/src/lib/libcpu/sparc/configure.ac the line
>>
>> AM_CONDITIONAL(has_instruction_cache, test "$RTEMS_CPU_MODEL" = "leon1" \
>> || test "$RTEMS_CPU_MODEL" = "leon2" )
>>
>> should be modified to also allow for the instruction cache in the leon3!!
>>   
>>     
> I can't think of anywhere else that would need to be fixed.
>
> This appears to impact 4.6, 4.7, and the CVS head.  Right?
>   
>> For anyone interested, it took me a very long time to trace this 
>> problem, which manifested itself very intermittently when I would load a 
>> new interrupt vector via rtems_interrupt_catch or set_vector. Since  the 
>> vector is inserted in the trap table, the instruction cache must be 
>> flushed but since the leon3 was not identified as having an instruction 
>> cache, the function to flush it was dummied out! The result was very 
>> unpredictable but often resulted in an unexpected "ta 0" on the first 
>> occurrence of the newly installed interrupt since the trap table is 
>> populated with "ta 0" handlers by default and while the new vector was 
>> loader into table, the default vector was still in the cache from a 
>> previous execution of a nearby interrupt.
>>
>> Do you know of any other area that should be scrubbed for similar problems?
>>
>>
>> - Jerry
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>   
>>     
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>