From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27159 invoked by alias); 9 Nov 2008 11:08:48 -0000 Received: (qmail 26682 invoked by uid 22791); 9 Nov 2008 11:08:47 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hermes.mlbassoc.com (HELO mail.chez-thomas.org) (204.133.123.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 09 Nov 2008 11:08:10 +0000 Received: by mail.chez-thomas.org (Postfix, from userid 999) id 1EB023B52971; Sun, 9 Nov 2008 03:43:09 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hermes.chez-thomas.org X-Spam-Level: Received: from hermes.chez-thomas.org (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id 93E903B528BF; Sun, 9 Nov 2008 03:43:08 -0700 (MST) Message-ID: <4916BEBC.90200@mlbassoc.com> Date: Sun, 09 Nov 2008 11:08:00 -0000 From: Gary Thomas User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: oli@snr.ch CC: =?ISO-8859-1?Q?G=E1bor_T=F6r=F6k?= , ecos-devel@ecos.sourceware.org Subject: Re: What is the reason to... References: <4910602A.3090408@speag.ch> <49148705.3090007@speag.ch> <30c102240811081339l17a02418w19863a27256eadc9@mail.gmail.com> <49161FCF.5020909@snr.ch> In-Reply-To: <49161FCF.5020909@snr.ch> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: 2008-11/txt/msg00011.txt.bz2 Oliver Munz @ SNR wrote: > Yes, if it's the case, that the drivers only are linked in the > application, if they are realy needed, then there is no reason to don't > include the CYGPKG_IO_*'s and if the CYGPKG_IO_*'s do control, if the > drivers are linked to the applications, then they shouldn't be marked as > "hardware"... > > But i don't know how it is... The reason things are done this way is to allow building a configuration with minimal drivers included. The hardware drivers (e.g. CYGPKG_DEVS_SPI_ARM_AT91) are designed such that they will be disabled unless the corresponding generic layer is present (CYGPKG_IO_SPI). Thus in the default configuration SPI will be disabled. Adding CYGPKG_IO_SPI enables the whole SPI framework, including the platform drivers. > Gábor Török schrieb: >> I think it is the same issue CYGPKG_IO_USB and CYGPKG_IO_USB_SLAVE, >> which are also marked as hadware packages and not included in the >> templates. >> >> On Fri, Nov 7, 2008 at 7:20 PM, oliver munz @ s p e a g >> wrote: >> >>> In this case templates like: >>> >>> target at91sam7sek { >>> alias { "Atmel AT91SAM7SEK evaluation board" at91_at91sam7sek } >>> packages { CYGPKG_HAL_ARM >>> CYGPKG_HAL_ARM_AT91 >>> CYGPKG_HAL_ARM_AT91SAM7 >>> CYGPKG_HAL_ARM_AT91SAM7SEK >>> CYGPKG_IO_SERIAL_ARM_AT91 >>> CYGPKG_DEVS_FLASH_AT91 >>> CYGPKG_DEVS_SPI_ARM_AT91 >>> CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC >>> CYGPKG_DEVS_USB_AT91 >>> } >>> description " >>> The at91sam7sek target provides the packages needed to run eCos >>> on an >>> Atmel AT91SAM7S-EK evaluation board." >>> } >>> >>> should be changed? >>> >>> They are missing the CYGPKG_IO_SPI and so on... >>> >>> Thanks Oliver >>> >>> Bart Veer schrieb: >>> >>>>>>>>> "Oliver" == oliver munz @ s p e a g writes: >>>>>>>>> >>>>>>>>> >>>> Oliver> mark CYGPKG_IO_SPI as HARDWARE? >>>> Oliver> I think Generic SPI or I2C and so one should be loadable >>>> Oliver> whitout an template. Can we change this? >>>> >>>> The problem here is that other drivers such as the wallclock or >>>> dataflash are likely to depend on the SPI/I2C bus being available. On >>>> some platforms there may even be platform HAL dependencies on the bus. >>>> Now, by convention you can enable flash support on a given platform >>>> simply by e.g. "ecosconfig add flash" and everything sorts itself out. >>>> If the SPI or I2C bus driver was not automatically part of the >>>> configuration then that would stop working. >>>> >>>> If you want the SPI or I2C support to be automatically available when >>>> needed, working within the limitations of current CDL, then the >>>> generic SPI or I2C packages have to be part of the target definition >>>> in ecos.db. That means they have to be hardware packages. >>>> >>>> Also, in most cases the expectation is that the generic SPI and I2C >>>> packages will only be usable if the target definition also specifies a >>>> device driver appropriate for the hardware. So if you are adding SPI >>>> or I2C support to a target then you have to edit the ecos.db target >>>> entry anyway, and adding two packages instead of one is no big deal. >>>> >>>> Now, both the generic SPI and I2C packages have been carefully >>>> designed to ensure that they add zero overhead to the application if >>>> nothing actually uses the SPI or I2C bus. Any unused functionality >>>> gets eliminated at link-time by linker garbage collection. Hence the >>>> only real overhead is at build-time: ecosconfig or the configtool may >>>> take a little longer to run, and a couple more files get compiled. >>>> Neither is likely to be noticed by users unless they sit down with a >>>> stopwatch. >>>> >>>> Bart >>>> >>>> >>>> >> >> >> -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------