rtems-CVS-050303 i.MX/MX1/csb336 BUG and BUGFIX
Pavel Pisa
ppisa4lists at pikron.com
Fri Mar 4 00:58:32 UTC 2005
Hello Joel and all others,
there has been introduced bug into bsp_vector_table definition.
It has been changed to "rtems_irq_hdl bsp_vector_table;".
This means, that ldscript declares address of variable
of the function pointer type.
This is than silently casted from (rtems_irq_hdl) to (rtems_irq_hdl*)
aka (long*) in
rtems/c/src/lib/libbsp/arm/shared/irq/irq_init.c:rtems_irq_mngt_init()
vectorTable = (long *) VECTOR_TABLE;
and uninitialized memory contents is used as base address for the vector table
/* Initialize the vector table contents with default handler */
for (i=0; i<BSP_MAX_INT; i++)
*(vectorTable + i) = (long)(default_int_handler);
Next oneliner patch solves described problem
---------------------------------------------------------------------------------------------
diff --minimal -r -u -P -p rtems/c/src/lib/libcpu/arm/mc9328mxl/irq/irq.h.orig rtems/c/src/lib/libcpu/arm/mc9328mxl/irq/irq.h
--- rtems/c/src/lib/libcpu/arm/mc9328mxl/irq/irq.h.orig 2005-03-04 00:57:56.000000000 +0100
+++ rtems/c/src/lib/libcpu/arm/mc9328mxl/irq/irq.h 2005-03-04 01:00:05.000000000 +0100
@@ -114,7 +114,7 @@ typedef void (*rtems_irq_enable) (con
typedef void (*rtems_irq_disable) (const struct __rtems_irq_connect_data__*);
typedef int (*rtems_irq_is_enabled)(const struct __rtems_irq_connect_data__*);
-extern rtems_irq_hdl bsp_vector_table;
+extern rtems_irq_hdl bsp_vector_table[BSP_MAX_INT];
#define VECTOR_TABLE bsp_vector_table
typedef struct __rtems_irq_connect_data__ {
---------------------------------------------------------------------------------------------
But I have big problem to analyze and find this hidden bug.
I have added next output into cpu.c to see more information
---------------------------------------------------------------------------------------------
diff --minimal -r -u -P -p rtems/cpukit/score/cpu/arm/cpu.c.orig rtems/cpukit/score/cpu/arm/cpu.c
--- rtems/cpukit/score/cpu/arm/cpu.c.orig 2004-04-29 13:32:29.000000000 +0200
+++ rtems/cpukit/score/cpu/arm/cpu.c 2005-03-04 00:42:30.000000000 +0100
@@ -221,6 +223,47 @@ void rtems_exception_init_mngt()
#define SET_REG(r, ctx, v) (((uint32_t *)ctx)[r] = v)
#define GET_OFFSET(insn) (insn & 0xfff)
+char *_print_full_context_mode2txt[0x20]={
+ [0x10]="user", /* User */
+ [0x11]="fiq", /* FIQ - Fast Interrupt Request */
+ [0x12]="irq", /* IRQ - Interrupt Request */
+ [0x13]="super", /* Supervisor */
+ [0x17]="abort", /* Abort */
+ [0x1b]="undef", /* Undefined */
+ [0x1f]="system" /* System */
+ };
+
+void _print_full_context(uint32_t spsr)
+{
+ char *mode;
+ uint32_t prev_sp,prev_lr,cpsr,tmp;
+ int i;
+
+ printk("active thread thread 0x%08x\n", _Thread_Executing->Object.id);
+
+ mode=_print_full_context_mode2txt[spsr&0x1f];
+ if(!mode) mode="unknown";
+
+ asm volatile (" MRS %[cpsr], cpsr \n"
+ " ORR %[tmp], %[spsr], #0xc0 \n"
+ " MSR cpsr_c, %[tmp] \n"
+ " MOV %[prev_sp], sp \n"
+ " MOV %[prev_lr], lr \n"
+ " MSR cpsr_c, %[cpsr] \n"
+ : [prev_sp] "=&r" (prev_sp), [prev_lr] "=&r" (prev_lr),
+ [cpsr] "=&r" (cpsr), [tmp] "=&r" (tmp)
+ : [spsr] "r" (spsr)
+ : "cc");
+
+ printk("Previous sp=0x%08x lr=0x%08x and actual cpsr=%08x\n", prev_sp, prev_lr, cpsr);
+
+ for(i=0;i<48;){
+ printk(" 0x%08x",((uint32_t*)prev_sp)[i++]);
+ if((i%6) == 0)
+ printk("\n");
+ }
+
+}
/* This function is supposed to figure out what caused the
* data abort, do that, then return.
@@ -311,6 +354,8 @@ void do_data_abort(uint32_t insn, uint
printk("data_abort at address 0x%x, instruction: 0x%x, spsr = 0x%x\n",
ctx->register_lr - 8, insn, spsr);
+ _print_full_context(spsr);
+
/* disable interrupts, wait forever */
_CPU_ISR_Disable(tmp);
while(1) {
---------------------------------------------------------------------------------------------
But I would like to enhance ARM debugging support for RTEMS,
because it would save me many hours. I do not know, when/where I
would be able to dig time for that, but it is inevitable.
I have some slight experience with GDB internals, even noticed in some
RTEMS documentation :-).
That is why I should be able to implement/port ARM stub for RTEMS
if I am helped with RTEMS side of the game.
I have already looked at RTEMS sources for other architectures,
but I would like to discuss case with more knowledge people.
As I understand, there are two possible kinds of stubs for RTEMS.
One is running in RTEMS thread and can be used to debug other RTEMS
threads over RS-232 or ETHERNET. This stub cannot be used for
core executive primitives and interrupts debugging.
The second one is stub directly connected to the RS-232 hardware,
which could be used for debugging of all code run with enabled
interrupts.
Please, can you give me information, where should be ARM specific
files located and which architecture implementation is the best
starting point. I am not sure, which kind of stub is better
for beginning. Suggestions there welcomed as well.
Thanks in advance
Pavel Pisa
==================================================
PiKRON s.r.o. Phone: +420 2 96781671
Kankovskeho 1235 Phone/Fax: +420 2 84684676
182 00 Praha 8 WWW: http://www.pikron.com/
Czech Republic e-mail: ppisa4lists at pikron.com
==================================================
More information about the users
mailing list