From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19440 invoked by alias); 12 Oct 2013 14:54:03 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 19427 invoked by uid 89); 12 Oct 2013 14:54:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail.ihostasp.net Received: from mail.ihostasp.net (HELO mail.ihostasp.net) (209.190.184.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 12 Oct 2013 14:54:01 +0000 Received: from 174-24-26-24.clsp.qwest.net [174.24.26.24] by mail.ihostasp.net with SMTP; Sat, 12 Oct 2013 10:53:52 -0400 From: Michael Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1A3BDE41-BECF-4AA5-86AE-35460B4A67FC@proclivis.com> Date: Sat, 12 Oct 2013 14:54:00 -0000 To: ecos discuss Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: [ECOS] ARM Vectors.S Question X-SW-Source: 2013-10/txt/msg00008.txt.bz2 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 whe= n virtual vectors are turned on, hal_if is stepping on the vectors.=20 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=20=20=20=20=20=20=20=20 ldr pc,.reset_vector // 0x00 #endif=20=20=20=20=20=20=20=20 ldr pc,.undefined_instruction // 0x04 ldr pc,.software_interrupt // 0x08 start && software i= nt 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=20=20=20=20=20=20=20=20=20 PTR(start) // This is copied to 0x28 for bootup // 0x40 #endif=20=20=20=20=20=20=20=20 // location 0x40 is used for storing DRAM size if known // for some platforms. =20=20=20=20=20=20=20=20 // // "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.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 // .section ".fixed_vectors" // Interrupt/exception VSR pointers .globl hal_vsr_table hal_vsr_table: .rept 8=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 .long 0 .endr .globl hal_dram_size hal_dram_size:=20=20 .long 0 // what, if anything, hal_dram_type means is up to the platform .globl hal_dram_type hal_dram_type:=20=20 .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 n= ot 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 thi= s: .globl hal_vsr_table hal_vsr_table: .rept 16 <=3D=3D=3D=3D=3D=3D=3D=3D=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 .long 0 .endr Or explain why this works on typical ARM platforms so I know what is differ= ent 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