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