From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10968 invoked by alias); 25 Nov 2008 22:58:02 -0000 Received: (qmail 10862 invoked by uid 22791); 25 Nov 2008 22:58:01 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS 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; Tue, 25 Nov 2008 22:57:10 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id C819421800B; Tue, 25 Nov 2008 22:56:59 +0000 (GMT) X-Virus-Scanned: amavisd-new at ecoscentric.com 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 q5GoYnj0eETz; Tue, 25 Nov 2008 22:56:58 +0000 (GMT) Received: from [127.0.0.1] (hagrid.vpn.ecoscentric.com [192.168.145.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 3E9323B4006C; Tue, 25 Nov 2008 22:56:58 +0000 (GMT) Message-ID: <492C82BF.6090502@eCosCentric.com> Date: Tue, 25 Nov 2008 22:58:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Evgeniy Dushistov CC: Andrew Lunn , ecos-devel@ecos.sourceware.org Subject: Re: at91sam9263ek References: <20081106182328.GA13554@rain> <20081110092057.GG31000@lunn.ch> <4922EF4D.6020809@eCosCentric.com> <20081125205031.GA14639@rain> In-Reply-To: <20081125205031.GA14639@rain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2008-11/txt/msg00067.txt.bz2 Evgeniy Dushistov wrote: > On Tue, Nov 18, 2008 at 04:37:33PM +0000, Jonathan Larmour wrote: > >>Andrew Lunn wrote: >> >>>On Thu, Nov 06, 2008 at 09:23:28PM +0300, Evgeniy Dushistov wrote: >>> >>>>Hi, >>>> >>>>I want to see working ecos on at91sam9263ek board. >>>>As far as I know, there is no freely available source code of ecos port on >>>>this hardware, am I right? (I know about ecoscentric, but it is not >>>>freely available). >>>> >>>>May be anybody is working on such kind of port? >>>> >>>>Right now I'm reading docs about cdl language, and stuck on which >>>>variant to choose: create directory at91sam9 in >>>>packages/hal/arm/arm9 and write hal package from scratch >>>>or use packages/hal/arm/at91 stuff, at91sam9263ek is very similar >>>>to at91sam7s, >> >>I don't think it's that similar. At least, it seems similar at a >>high-level, but differs in most of the details once you get into it. The >>register layouts differ in many places between the SAM9 variants even. I >>think you'd end up with huge amounts of ifdefs. > > Can you, please, give, example of such defence? Well I had flicked through our own SAM926x implementation to see the variations, and there was differences for most of the base addresses as you saw, the bus matrix, the EBI, pin mappings, peripheral assignments, USB and PLLs. Just to be clear, I was talking about cloning, rather than really starting from scratch, but I'm sure that's what you were considering. >>I recommend the former approach. If there is anything that can sensibly be >>shared, perhaps it could be broken out into a separate package. >> > > you mean split hal on several packages? > like package for work with gpio, > for reset cpu and so on? I meant have a common package for the bits which are indeed common. The reason is that I think it would be bad for the AT91 HAL to be a big mess of #ifdefs for all the different variants all the way through. It's getting that way already. eCos is meant to be modular, rather than having large monolithic headers with the kitchen sink thrown in. It becomes difficult to work out exactly what does apply where. I guess alternatively, if it were in a single package, then it would be better to break it into different files, and only the correct files are used according to the configuration. A bit like the SH3 or SH4 HALs (I suggest looking at those to see what I mean). Those had to deal with the same sorts of problems - peripherals in various implementations combined in different ways. IMHO. For example, consider the cache and MMU stuff. That really shouldn't belong in the AT91 HAL. At least not the existing form of AT91 HAL. At the very least you can't have hal_cache.h and var_io.h in both the ARM9 HAL and the AT91 HAL, so _something_ will have to be majorly reorganised. 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. ------["The best things in life aren't things."]------ Opinions==mine