Instruction cache for leon3

[Jerry Needell]

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?
I think that is correct.  It has been lurking for quite awhile :-)

>> 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
>>