ARM Vectors.S Question

[Michael Jones <mike at proclivis dot com>]

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
__exception_handlers:
#ifdef CYGSEM_HAL_ROM_RESET_USES_JUMP
// 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
#else        
        ldr     pc,.reset_vector                // 0x00
#endif        
        ldr     pc,.undefined_instruction       // 0x04
        ldr     pc,.software_interrupt          // 0x08 start && software int
        ldr     pc,.abort_prefetch              // 0x0C
        ldr     pc,.abort_data                  // 0x10
#ifdef CYGNUM_HAL_ARM_VECTOR_0x14
        .word   CYGNUM_HAL_ARM_VECTOR_0x14
#else
        .word   0                               // unused
#endif
        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
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
#ifdef CYGSEM_HAL_ARM_PID_ANGEL_BOOT         
PTR(start) // This is copied to 0x28 for bootup // 0x40
#endif        
           // 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
hal_vsr_table:
        .rept   8               
        .long   0
        .endr

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

        .balign 16
#ifdef CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT
	// Vectors used to communicate between eCos and ROM environments
        .globl  hal_virtual_vector_table
hal_virtual_vector_table:
        .rept   CYGNUM_CALL_IF_TABLE_SIZE
        .long   0
        .endr
#endif

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
hal_vsr_table:
        .rept   16       <========              
        .long   0
        .endr

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

Thanks,

Mike

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss