| Commit message (Collapse) | Author | Files | Lines |
|---|
|
* cpu_asm.S: Small patch to fix a bug in the rtems sparc port. The
bug has been there all the time, but only hits the leon bsp since the
leon cpu has a 5-stage pipeline (erc32 has 4 stages).
|
|
* rtems/score/cpu.h: Added _CPU_Initialize_vectors().
* cpu_asm.S: Modify to properly dereference _ISR_Vector_table
now that it is dynamically allocated.
|
|
* cpu_asm.S: Fix for CPUs with FPU revision B or C.
|
|
routines and structures that require CPU model specific information
are now in libcpu. This primarily required moving erc32 specific
information from score/cpu files to libcpu/sparc and the erc32 BSP.
|
|
|
|
+ interrupt masking correction
+ FPU rev.B workaround
+ minor erc32 related fixes
|
|
getting the spurious trap handling to work required a couple more
fixes - I have attached a patch against rtems-4.0.0 with the
necessary changes. I also added functionality so that the
address of the trapped instruction is reported and in case of
a data access error, the data address is also reported.
|
|
.s files to .S in conformance with GNU conventions. This is a
minor step along the way to supporting automake.
|
|
|
|
external interrupt priorities were not being honored. Here is some
of his original report:
using rtems/erc32, I have a problem with interrupt priority when
interrupts occure simultaneously. Erc32 has an interrupt force
register where interrupts can be generated. If more than one
interrupt is generated, the interrupt handlers are scheduled in
the wrong order, i.e. with the lowest priority first.
I have attched a program that generates three interrupts, 0x11, 0x12
and 0x13. Interrupt 0x13 should be handled first, but is actually
handled last. Below is the output from sis:
sis> go
resuming at 0x02000000
RAM size: 4096 K, ROM size: 2048 K
Watchdog disabled
Waitstates = RAM read: 0, RAM write: 0, ROM read: 0, ROM write: 0
Power-down mode enabled
infinite UART baudrate
External interrupt received with vector 0x11
External interrupt received with vector 0x12
External interrupt received with vector 0x13
I have verified that sis generates the interrupts in the correct
order, i.e. 0x13 first, then 0x12 and then 0x11. So the problem
seems to be in the rtems interrupt handler. Do you use the PIL field
in the %psr register to mask lower priority interrupts or are all
external interrupts considered to have the same priority ..?
Here is a description of the fix:
it turned out that lower priority interrupts were not at all masked
off during interrupt handling. I made the following fix to cpu_asm.s:
... fix is in the code ...
There might be a simpler way of doing this, but this works...
|
|
|
|
|
|
of switching to the modified GNU GPL.
|
|
|
|
subject to causing unpredictable window underflow/overflows.
|
|
|
|
|
|
|
|
|
