[ECOS] ARM Vectors.S Question

Michael Jones mike@proclivis.com
Sat Oct 12 14:54:00 GMT 2013

I am having some trouble understanding the ARM startup. I am not using one the existing HAL, so I can't get in a debugger to see how things work. I am doing a new HAL.

The code that sets up the exception table does not have enough space so when virtual vectors are turned on, hal_if is stepping on the vectors. 

The Vectors.S file has the following code:

        .global __exception_handlers
// 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   CYGNUM_HAL_ARM_VECTOR_0x14
        .word   0                               // unused
        ldr     pc,.IRQ                         // 0x18
        ldr     pc,.FIQ                         // 0x1C

// The layout of these pointers should match the vector table above since
// they are copied in pairs.
        .global vectors
UNMAPPED_PTR(reset_vector)                      // 0x20
PTR(undefined_instruction)                      // 0x24
PTR(software_interrupt)                         // 0x28
PTR(abort_prefetch)                             // 0x2C
PTR(abort_data)                                 // 0x30
        .word   0                               // 0x34
PTR(IRQ)                                        // 0x38
PTR(FIQ)                                        // 0x3c
PTR(start) // This is copied to 0x28 for bootup // 0x40
           // location 0x40 is used for storing DRAM size if known
           // for some platforms.
// "Vectors" - fixed location data items
//    This section contains any data which might be shared between
// an eCos application and any other environment, e.g. the debug
// ROM.                        
        .section ".fixed_vectors"
        // Interrupt/exception VSR pointers
        .globl  hal_vsr_table
        .rept   8               
        .long   0

        .globl  hal_dram_size
        .long   0
	// what, if anything, hal_dram_type means is up to the platform
        .globl  hal_dram_type
        .long   0

        .balign 16
	// Vectors used to communicate between eCos and ROM environments
        .globl  hal_virtual_vector_table
        .long   0

The hal_vsr_table allocates 8 longs. But the vector table requires 16 longs, 8 are the exception handlers (load the pc), and 8 are vectors.

The 16 longs are copied in place in pairs with code like this:

        ldr     r2,[r1,#HAL_ARM_IRQ_VECTOR]   // IRQ
        str     r2,[r0,#HAL_ARM_IRQ_VECTOR]
        ldr     r2,[r1,#HAL_ARM_IRQ_VECTOR_ADDR]
        str     r2,[r0,#HAL_ARM_IRQ_VECTOR_ADDR]

Because hal_virtual_vector_table is near the hal_vsr_table, hal_if steps on the vectors.

The only way I can imagine this every worked with virtual vectors would be if if the table were based on 2 byte instructions and address, which does not make any sense to me. The addresses are all 32 bits, at least in my case.

Can someone either confirm this is incorrectly coded and should be like this:

        .globl  hal_vsr_table
        .rept   16       <========              
        .long   0

Or explain why this works on typical ARM platforms so I know what is different than my platform.



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 mailing list