From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 375 invoked by alias); 21 Jan 2009 19:20:59 -0000 Received: (qmail 357 invoked by uid 22791); 21 Jan 2009 19:20:58 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_MX,SARE_FREE_WEBM_RuMail,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2-2.mail.ru (HELO mx2.mail.ru) (194.67.23.122) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jan 2009 19:20:53 +0000 Received: from [79.134.88.168] (port=42686 helo=rain) by mx2.mail.ru with asmtp id 1LPid8-000FEG-00; Wed, 21 Jan 2009 22:20:50 +0300 Received: by rain (nbSMTP-1.00) for uid 1000 dushistov@mail.ru; Wed, 21 Jan 2009 21:20:52 +0300 (MSK) Date: Wed, 21 Jan 2009 19:20:00 -0000 From: Evgeniy Dushistov To: Jonathan Larmour Cc: ecos-discuss@ecos.sourceware.org, ecos-devel@ecos.sourceware.org Subject: Re: [ECOS] at91sam9263ek support ver. beta 1 Message-ID: <20090121182051.GA12420@rain> References: <496F6BD6.3040001@eCosCentric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <496F6BD6.3040001@eCosCentric.com> User-Agent: Mutt/1.5.16 (2007-06-09) 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: 2009-01/txt/msg00037.txt.bz2 On Thu, Jan 15, 2009 at 05:01:10PM +0000, Jonathan Larmour wrote: > Hi Evgeniy, > > Thanks for working on this. > > 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. You suggest just make copy/paste from arm9 to at91 ? Or there is cdl trick to use(include) in at91 header from arm9 directory? 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? > 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? -- /Evgeniy