I got a little exception handling bolted onto the FORTH code so at least now when it crashes I have a hint where it was, as well as don't have to reset the machine. I'd given up on it after wasting hours trying to get anything working a week ago ... all because of a silly missing .align directive. Bummer. And I wasted a few today too.
And I don't even need it anymore anyway!
ABORT: Exception Prefetch Abort
pc: 52423020 sr: 200001D0
r0: 8000E5C8
r1: 00000082
r2: 8000E5C0
r3: 00000046
r4: 8000E5D8
r5: 8000E61C
r6: 8001E5BC
r7: 8000E5C0
r8: 8000C008
r9: 00000000
r10: 8000E5D4
r11: 8000D190
r12: 8000C094
r13: 8000E194 00000000 00020010 000008D4 8000B45C 00000000 00020010 000008E1 80009024
r14: 800092CC
r15: 00000000
Well isn't that impressive. Pity it doesn't really help with the bugs in my code. Although at least it does then simply jump back to the FORTH interpreter loop, so at least I don't have to resort to a hardware reset to continue.
I also changed the forth interpreter to run in user mode. Not because I really need to, but because I was too lazy to handle the exception stack pointer properly - since it was running in supervisor mode it uses the same stack pointer as the segfault-type exceptions. Probably it should run in system mode ...
Exception Setup
The following is just info for the few who might be looking for it - it took me a little while to dig it all up solely because I kept looking in the wrong places. It's not terribly interesting unless you're writing a kernel with no prior experience, it's not good code, and it's not even correct in many cases, but maybe there's something useful here for somebody.
The 'exception vectors' on the beagle are stored in the last few bytes of the omap's onboard 64K of RAM, and it is a jump table, not a function pointer array. Although they're actually setup so that there's room to use a function array immediately afterward by doing a pc-relative load, since 4 bytes isn't enough to do much else. The vectors start at 0x4020ffc8, although the Cortex-A8 also has a system control coprocessor register (c12) to move it.
So the init function just copies a 'prototype' image of the code across:
// initialise exception vectors
.global ex_init
ex_init:
ldr r2,=ex_vect
ldr r3,=0x4020ffc8
ldr r1,=v_end_vect
1: ldr r0,[r2],#4
str r0,[r3],#4
cmp r2,r1
blo 1b
bx lr
ex_vect:
ldr pc, v_undefined_instruction
ldr pc, v_software_interrupt
ldr pc, v_prefetch_abort
ldr pc, v_data_abort
ldr pc, v_not_used
ldr pc, v_irq
ldr pc, v_fiq
v_undefined_instruction: .word ex_undefined_instruction
v_software_interrupt: .word ex_software_interrupt
v_prefetch_abort: .word ex_prefetch_abort
v_data_abort: .word ex_data_abort
v_not_used: .word ex_not_used
v_irq: .word ex_irq
v_fiq: .word ex_fiq
v_end_vect:
Where the ex_* labels mark the exception handlers themselves.
NOTE: it's missing the stuff to muck about with the caches, which is pretty important when you're writing code as data ... but for now it works. Perhaps I could avoid the code copy by just copying the address table ... I just don't know if I can assume that, or just use the system control register to move the table.
This is the first thing being done after Das U-Boot has executed the 'kernel image' - the only other thing i'm doing is setting stack pointer somewhere 'known'. I'm not entirely sure of the whole system state at this point (perhaps 'cpu powered up, and in supervisor mode' is all one can assume), so I don't even know if/what caches are even enabled for example.
Exception usage
Since all I want to do is dump some state and reset the interpreter, my exception handlers all do the same thing (apart from recording which one was invoked), but normally each exception type needs the correct return operations at least. It doesn't handle irqs properly either (right now i'd just like to know if they happen for no reason).
For simplicity my exception handlers just set a specific stack pointer on entry to do their work. That's because each processor mode and a few of the exceptions have their own shadow stack and link registers, and the only way to initialise them is to be in the right mode first. Again, too lazy.
After that they save all the register state to memory, and then call some C to dump the state, before jumping back to the FORTH ABORT code, with a reset back to user mode.
So an example of a specific handler (although I use a macro):
ex_prefetch_abort:
ldr sp,=EX_STACK
push { r0 }
ldr r0,=3
b ex_handle
Then it executes:
ex_handle:
push { r0 }
ldr r0, =ex_regsave+4
// save original registers
stm r0, { r1-r14 }^
// save exception type
pop { r1 }
str r1,[r0, #-16]
pop { r1 }
// save pc, sr, and r0
str lr, [r0, #-8]
str r1, [r0, #-4]
mrs r1, spsr
str r1, [r0, #-12]
// display something about it
sub r0,r0,#16
bl exception_dump
// Now we want to reset everything and jump back to the forth loop
ldr r14,=DOABORT
movs pc,r14
The final
movs also restores the CPSR and thus the processor mode.Note: This is by no means particularly pretty or nice code. It was just the first thing I got working!
And the data-structure for passing to C:
.data
ex_type: .word 0
ex_regsr: .word 0
ex_regpc: .word 0
ex_regsave: .word 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
And finally the C code.
struct exception_detail {
uint32 type;
uint32 sr;
uint32 pc;
uint32 reg[16];
};
const char const *extypes[8] = {
"Reset",
"Undefined Instruction",
"Software Interrupt",
"Prefetch Abort",
"Data Abort",
"Not used",
"IRQ",
"FIQ"
};
void exception_dump(struct exception_detail *e) {
int i;
send("\r\n\r\nABORT: Exception ");
send(extypes[e->type]);
...
}
