[ECOS] vector.s branch 0 problem
Mon Jul 2 13:34:00 GMT 2007
I may have a found why my ecos does not work at all but i'd like so
feedback on it.
I used the command:
arm-elf-objdump -h -S -C vectors.o > vectors.lss
to have a clearer view of what was going on at the init scale.
Everything seemed nice so far but this morning i noticed that on the
rom vectors init:
Disassembly of section .vectors:
0: eafffffe b 0 <__exception_handlers>
4: e59ff018 ldr pc, [pc, #24] ; 24 <.undefined_instruction>
8: e59ff018 ldr pc, [pc, #24] ; 28 <.software_interrupt>
c: e59ff018 ldr pc, [pc, #24] ; 2c <.abort_prefetch>
10: e59ff018 ldr pc, [pc, #24] ; 30 <.abort_data>
14: b4405f62 strltb r5, [r0], -#3938
18: e59ff018 ldr pc, [pc, #24] ; 38 <.IRQ>
1c: e59ff018 ldr pc, [pc, #24] ; 3c <.FIQ>
I'm not a real genius when it come to assembly language but seems to
me the thing just loops forever at address 0.
I lurked a bit into vector.s and found the code that generated the
part above was that:
// Assumption: ROM code has these vectors at the hardware reset address.
// A simple jump removes any address-space dependencies [i.e. safer]
b reset_vector // 0x00
ldr pc,.reset_vector // 0x00
ldr pc,.undefined_instruction // 0x04
ldr pc,.software_interrupt // 0x08 start && software int
ldr pc,.abort_prefetch // 0x0C
ldr pc,.abort_data // 0x10
.word 0 // unused
ldr pc,.IRQ // 0x18
ldr pc,.FIQ // 0x1C
Now if we take a closer look at the code at 0, it is supposed to
branch to the start of the reset_vector. I noticed there's isn't a "."
(dot) at the start of the name, don't know if it's important or not
but as those are right from the cvs i thought it would be improper to
Do you guys have any idea what comes wrong here ?
Thanks in advance.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss