From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8869 invoked by alias); 31 Dec 2010 09:01:22 -0000 Received: (qmail 8860 invoked by uid 22791); 31 Dec 2010 09:01:20 -0000 X-SWARE-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS,RCVD_IN_RP_RNBL,RDNS_DYNAMIC,TW_KG X-Spam-Check-By: sourceware.org Received: from ctel-78-157-16-61.cabletel.com.mk (HELO relay.cabletel.com.mk) (78.157.16.61) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 31 Dec 2010 09:01:15 +0000 Received: from [192.168.209.21] (unknown [92.53.40.73]) by relay.cabletel.com.mk (Postfix) with ESMTP id 2D5D8114BA2 for ; Fri, 31 Dec 2010 10:01:26 +0100 (CET) Message-ID: <4D1D9BD2.2080407@siva.com.mk> Date: Fri, 31 Dec 2010 09:01:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 ThunderBrowse/3.3.4 MIME-Version: 1.0 CC: eCos developers Subject: Re: Cortex-M Vector Table Offset References: <4D11FF19.6000304@siva.com.mk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CableTel-MailScanner-Information: Please contact the ISP for more information X-CableTel-MailScanner-ID: 2D5D8114BA2.A0D70 X-CableTel-MailScanner: Found to be clean X-CableTel-MailScanner-SpamScore: s X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2010-12/txt/msg00011.txt.bz2 On 23.12.2010 19:12, Christophe Coutand wrote: > > Hi, > > Allowing the variant to overwrite CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM > seems the way to go. > That's what I have done so far by introducing conditional #define in the arch. I would also consider removing CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM with appropriate patch to current STM32 variant. > Maybe the idea was to have > CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM equal to the SRAM base and > CYGARC_REG_NVIC_VTOR_TBLOFF to fine tune the offset. I think it is > enough to have a patch that make it possible to redefine > CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM. > RegardingCYGARC_REG_NVIC_VTOR_TBLOFF it would be good to hear author's rationale. Is it some code used during Cortex-M port development or is placed to meet some Cortex-M features not implemented in current implementations? Can we omit it? > > It is up to the variant/platform to propagate any CDL definition down to > CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM and the memory layout so no patch for > the existing code is required? > It is possible to put CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM in var_io.h or in CDL. However hal_io.h must be patched with /#if !defined CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM/ condition. var_io.h would be better (simple) choice for devices with "fixed" SRAM position/configuration, such as LPC17xx and CDL seem to give some flexibility for devices like Kinetis. In the mean time, other similar issues have occurred since my first post, I would present them and propose solution(s) in the context of variant port(s). At the end of this year I wish all eCos developers Happy New 2011. Ilija > > Christophe > > > -----Original Message----- > From: ecos-devel-owner@ecos.sourceware.org on behalf of Ilija Kocho > Sent: Wed 12/22/2010 5:37 AM > To: eCos developers > Subject: Cortex-M Vector Table Offset > > Hello > > In a course of porting eCos to Cortex-M based devices, other than STM32, > an issue occurs that must be addressed. > > The problem (In following discussion I refer to ROM start-up > configuration): > > In current Cortex-M port the Vector Table Offset is fixed (VTOR set) by > architecture port to 0x20000000 (CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM > defined in hal/cortexm/arch//include/hal_io.h). This is the > place where it should be expected but on some devices this is not > possible: > > The example is NXP LPC 17xx family that has no RAM in Data (SRAM) > partition (i.e. at 0x20000000). Instead SRAM is located within Code > partition at address 0x10000000. > > Proposed solution: > > Define Vector Table base (CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM) in the > variant with override option for the platform: respective var_io.h > and/or plf_io.h. > > Also there is apparent dependence between > CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM and devices' memory configuration(s) > so we could consider some shared defines with pkgconf files and/or CDL. > This could provide flexibility useful for some other devices such as > Freescale Kinetis family. > > Patch(es) should be easy and harmless. I could produce ones after > discussion. > > For the end I have one question: What is use of > CYGARC_REG_NVIC_VTOR_TBLOFF(0) (hal/cortexm/arch/current/src/hal_misc.c) > > Best regards > Ilija > >