Instruction cache for leon3

Joel Sherrill joel.sherrill at oarcorp.com
Mon Jul 30 18:25:38 UTC 2007


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
>   




More information about the users mailing list