From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27552 invoked by alias); 21 Jan 2009 19:54:47 -0000 Received: (qmail 27534 invoked by uid 22791); 21 Jan 2009 19:54:46 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS,ZMIde_GENERICSPAM1 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jan 2009 19:54:38 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 68F1D60B8003; Wed, 21 Jan 2009 19:54:36 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sBkVZj9vTK0; Wed, 21 Jan 2009 19:54:35 +0000 (GMT) Message-ID: <49777D7A.4040602@eCosCentric.com> Date: Wed, 21 Jan 2009 19:54:00 -0000 From: Jonathan Larmour User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Evgeniy Dushistov CC: ecos-discuss@ecos.sourceware.org, ecos-devel@ecos.sourceware.org Subject: Re: [ECOS] at91sam9263ek support ver. beta 1 References: <496F6BD6.3040001@eCosCentric.com> <20090121182051.GA12420@rain> In-Reply-To: <20090121182051.GA12420@rain> OpenPGP: id=A5FB74E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2009-01/txt/msg00038.txt.bz2 Evgeniy Dushistov wrote: > On Thu, Jan 15, 2009 at 05:01:10PM +0000, Jonathan Larmour wrote: >> Evgeniy Dushistov wrote: >>> I need this changes, because of at91sam9 use the same code as arm9 to >>> work with caches: >>> http://sites.google.com/site/duhistov/Home/0003-rename-all-hal_cache.h-to-var_cache.h-and-copy-creat.patch?attredirects=0 >> Urk. There are easier ways to do this. And in any case, putting >> ARM9-specific code in the architecture HAL is not right. Even with that >> addressed, it will break a lot of people's ports out there (not in >> anoncvs). That's something which should not be done lightly - I don't mean >> it can never be done, but it should be avoided and in this case can be. And >> in fact, should be because that's what the name "var_cache.h" signifies - a >> different processor variant, whereas in your patch it's used for platform >> ports too, most of which have the same variant. >> >> I think the main problem is that we have separate processor HALs for ARM9, >> XScale, etc. But not for ARM7. There should be probably be an ARM7 >> processor variant HAL to deal with bits which are specific to that. That's >> where hal_cache.h would live, along with anything else that isn't shared >> with other processor variants, but is shared with other ARM7's. >> > > But how this helps in our case, in at91 family there are arm7 and arm9 > variants? That's why I move common with arm9 part to level higher -> arm. Which is IMHO the wrong approach. What I am proposing is that an ARM7-based AT91 target would have a target record in ecos.db that included both CYGPKG_HAL_ARM_AT91 and CYGPKG_HAL_ARM_ARM7. An ARM9-based AT91 target would have a target record in ecos.db that contains both CYGPKG_HAL_ARM_AT91 and CYGPKG_HAL_ARM_ARM9. > You suggest just make copy/paste from arm9 to at91 ? Nope. > Or there is cdl trick to use(include) in at91 header from arm9 directory? No need. > There are no other examples of such situation in eocs source code base, > when core of processor changed, but IP blocks are almost the same? No indeed there are no current examples, which is why we need to do something a bit more radical, i.e. creating a CYGPKG_HAL_ARM_ARM7 package to break out the bits that are different from other cores. >> This would also open up the possibility in future of breaking out some code >> in vectors.S which currently has to cater for the lowest-common-denominator >> instruction set of ARM architecture v4. It would be nice to be able to use >> better instructions in some places, and thumb in particular is simpler in >> later architecture versions. >> >> Adding a new CYGPKG_HAL_ARM_ARM7 to the target definition in ecos.db is a >> much simpler change. >> > > There is CYGINT_HAL_ARM_ARCH_ARM7, may be it is possible to use it? That's not really relevant for what I'm talking about, since we need to be concerned about the location of files like hal_cache.h, which can't depend on configuration options. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine