* What is the reason to...
@ 2008-11-04 14:46 oliver munz @ s p e a g
2008-11-04 18:57 ` Bart Veer
0 siblings, 1 reply; 14+ messages in thread
From: oliver munz @ s p e a g @ 2008-11-04 14:46 UTC (permalink / raw)
To: ecos-devel
mark CYGPKG_IO_SPI as HARDWARE?
I think Generic SPI or I2C and so one should be loadable whitout an
template. Can we change this?
Thanks
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-04 14:46 What is the reason to oliver munz @ s p e a g
@ 2008-11-04 18:57 ` Bart Veer
2008-11-07 18:20 ` oliver munz @ s p e a g
2008-11-18 17:16 ` Jonathan Larmour
0 siblings, 2 replies; 14+ messages in thread
From: Bart Veer @ 2008-11-04 18:57 UTC (permalink / raw)
To: munz; +Cc: ecos-devel
>>>>> "Oliver" == oliver munz @ s p e a g <munz@speag.ch> 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
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-04 18:57 ` Bart Veer
@ 2008-11-07 18:20 ` oliver munz @ s p e a g
2008-11-08 21:40 ` Gábor Török
` (2 more replies)
2008-11-18 17:16 ` Jonathan Larmour
1 sibling, 3 replies; 14+ messages in thread
From: oliver munz @ s p e a g @ 2008-11-07 18:20 UTC (permalink / raw)
To: Bart Veer; +Cc: ecos-devel
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 <munz@speag.ch> 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
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-07 18:20 ` oliver munz @ s p e a g
@ 2008-11-08 21:40 ` Gábor Török
2008-11-08 23:25 ` Oliver Munz @ SNR
2008-11-09 13:46 ` Bart Veer
2008-11-09 13:35 ` Bart Veer
2008-11-23 21:43 ` Bart Veer
2 siblings, 2 replies; 14+ messages in thread
From: Gábor Török @ 2008-11-08 21:40 UTC (permalink / raw)
To: munz, ecos-devel
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 <munz@speag.ch> 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 <munz@speag.ch> 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
>>
>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-08 21:40 ` Gábor Török
@ 2008-11-08 23:25 ` Oliver Munz @ SNR
2008-11-09 11:08 ` Gary Thomas
2008-11-09 13:46 ` Bart Veer
1 sibling, 1 reply; 14+ messages in thread
From: Oliver Munz @ SNR @ 2008-11-08 23:25 UTC (permalink / raw)
To: Gábor Török; +Cc: ecos-devel
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...
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 <munz@speag.ch> 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 <munz@speag.ch> 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
>>>
>>>
>>>
>
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-08 23:25 ` Oliver Munz @ SNR
@ 2008-11-09 11:08 ` Gary Thomas
2008-11-09 13:52 ` Bart Veer
0 siblings, 1 reply; 14+ messages in thread
From: Gary Thomas @ 2008-11-09 11:08 UTC (permalink / raw)
To: oli; +Cc: Gábor Török, ecos-devel
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
>> <munz@speag.ch> 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 <munz@speag.ch> 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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-07 18:20 ` oliver munz @ s p e a g
2008-11-08 21:40 ` Gábor Török
@ 2008-11-09 13:35 ` Bart Veer
2008-11-23 21:43 ` Bart Veer
2 siblings, 0 replies; 14+ messages in thread
From: Bart Veer @ 2008-11-09 13:35 UTC (permalink / raw)
To: munz; +Cc: ecos-devel
>>>>> "Oliver" == oliver munz @ s p e a g <munz@speag.ch> writes:
Oliver> In this case templates like:
Oliver> target at91sam7sek {
Oliver> alias { "Atmel AT91SAM7SEK evaluation board" at91_at91sam7sek }
Oliver> packages { CYGPKG_HAL_ARM
Oliver> CYGPKG_HAL_ARM_AT91
Oliver> CYGPKG_HAL_ARM_AT91SAM7
Oliver> CYGPKG_HAL_ARM_AT91SAM7SEK
Oliver> CYGPKG_IO_SERIAL_ARM_AT91
Oliver> CYGPKG_DEVS_FLASH_AT91
Oliver> CYGPKG_DEVS_SPI_ARM_AT91
Oliver> CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC
Oliver> CYGPKG_DEVS_USB_AT91
Oliver> }
Oliver> description "
Oliver> The at91sam7sek target provides the packages needed to run eCos
Oliver> on an
Oliver> Atmel AT91SAM7S-EK evaluation board."
Oliver> }
Oliver> should be changed?
Oliver> They are missing the CYGPKG_IO_SPI and so on...
I believe they should be changed. From
http://ecos.sourceware.org/docs-latest/ref/spi-porting.html:
"If there is already an SPI bus driver for the target hardware then
both that driver and this generic SPI package CYGPKG_IO_SPI should
be included in the ecos.db target entry."
I do not know all the inner details of the AT91 SPI driver so there
may be unexpected side effects.
Bart
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-08 21:40 ` Gábor Török
2008-11-08 23:25 ` Oliver Munz @ SNR
@ 2008-11-09 13:46 ` Bart Veer
2008-11-09 15:34 ` Frank Pagliughi
1 sibling, 1 reply; 14+ messages in thread
From: Bart Veer @ 2008-11-09 13:46 UTC (permalink / raw)
To: Gábor Török; +Cc: munz, ecos-devel
>>>>> "tgabor84" == =?ISO-8859-1?Q?G=E1bor T=F6r=F6k?= <tgabor84@gmail.com> writes:
tgabor84> I think it is the same issue CYGPKG_IO_USB and
tgabor84> CYGPKG_IO_USB_SLAVE, which are also marked as hadware
tgabor84> packages and not included in the templates.
CYGPKG_IO_USB and CYGPKG_IO_USB_SLAVE are included in the target
definitions for some targets, e.g. assabet, corresponding to the
boards for which slave-side USB first became available. The reasoning
is the same as for SPI and I2C: if the application does not use the
functionality then it gets eliminated at link-time. Again I do not
know if this works properly with more recent drivers. Also, USB is
somewhat more complicated than SPI.
Side issue: please be careful with terminology. A template is a
hardware-independent description of functionality, e.g. "default",
"redboot", or "net". Templates live in separate files below the
templates/ subdirectory of the eCos repository. A target definition
describes a hardware target, i.e. a specific board. Target definitions
live in the ecos.db file. The combination of a target definition and a
template gives an initial configuration.
Bart
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-09 11:08 ` Gary Thomas
@ 2008-11-09 13:52 ` Bart Veer
0 siblings, 0 replies; 14+ messages in thread
From: Bart Veer @ 2008-11-09 13:52 UTC (permalink / raw)
To: Gary Thomas; +Cc: oli, tgabor84, ecos-devel
>>>>> "Gary" == Gary Thomas <gary@mlbassoc.com> writes:
Gary> 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...
Gary> The reason things are done this way is to allow building a
Gary> configuration with minimal drivers included. The hardware
Gary> drivers (e.g. CYGPKG_DEVS_SPI_ARM_AT91) are designed such
Gary> that they will be disabled unless the corresponding generic
Gary> layer is present (CYGPKG_IO_SPI). Thus in the default
Gary> configuration SPI will be disabled.
Gary> Adding CYGPKG_IO_SPI enables the whole SPI framework,
Gary> including the platform drivers.
No. What you are describing is true for some types of device, e.g.
ethernet and flash. It is not true for SPI or I2C. Those depend on
link-time elimination of unwanted functionality, as opposed to
configure-time adding of desired functionality. A key difference is
that SPI and I2C are buses that may be needed by other bits of the
port, including the platform HAL. Hence to keep things simple for
users the generic code must be included in the configuration by
default.
Bart
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-09 13:46 ` Bart Veer
@ 2008-11-09 15:34 ` Frank Pagliughi
0 siblings, 0 replies; 14+ messages in thread
From: Frank Pagliughi @ 2008-11-09 15:34 UTC (permalink / raw)
To: Bart Veer; +Cc: Gábor Török, munz, ecos-devel
I also think that our views on the issue are affected by which
configuration editor we use. If I'm not mistaken, when using the
command-line editor you can just "add" the drivers into your
configuration, but if you use the GUI configtool, you can't add the
packages and must edit "ecos.db" to get these drivers. And then you must
manage a non-standard database file when upgrading from CVS.
So people, like me, who tend to use the GUI configtool would have more
of a reason to want to see theese drivers included in the target definition.
- Frank Pagliughi
Bart Veer wrote:
>>>>>> tgabor84> I think it is the same issue CYGPKG_IO_USB and
>>>>>> tgabor84> CYGPKG_IO_USB_SLAVE, which are also marked as hadware
>>>>>> tgabor84> packages and not included in the templates.
>>>>>>
>>>>>> CYGPKG_IO_USB and CYGPKG_IO_USB_SLAVE are included in the target
>>>>>> definitions for some targets, e.g. assabet, corresponding to the
>>>>>> boards for which slave-side USB first became available. The reasoning
>>>>>> is the same as for SPI and I2C: if the application does not use the
>>>>>> functionality then it gets eliminated at link-time. Again I do not
>>>>>> know if this works properly with more recent drivers. Also, USB is
>>>>>> somewhat more complicated than SPI.
>>>>>>
>>>>>> Side issue: please be careful with terminology. A template is a
>>>>>> hardware-independent description of functionality, e.g. "default",
>>>>>> "redboot", or "net". Templates live in separate files below the
>>>>>> templates/ subdirectory of the eCos repository. A target definition
>>>>>> describes a hardware target, i.e. a specific board. Target definitions
>>>>>> live in the ecos.db file. The combination of a target definition and a
>>>>>> template gives an initial configuration.
>>>>>>
>>>>>> Bart
>>>>>>
>>>>>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-04 18:57 ` Bart Veer
2008-11-07 18:20 ` oliver munz @ s p e a g
@ 2008-11-18 17:16 ` Jonathan Larmour
2008-11-18 18:39 ` Bart Veer
1 sibling, 1 reply; 14+ messages in thread
From: Jonathan Larmour @ 2008-11-18 17:16 UTC (permalink / raw)
To: Bart Veer; +Cc: munz, ecos-devel
Bart Veer wrote:
>>>>>> "Oliver" == oliver munz @ s p e a g <munz@speag.ch> 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.
I've said this before and will just take the opportunity to say it again:
the 'hardware' attribute just gets in the way. You can't have packages in
the target definition that aren't 'hardware', and you can't add packages
which are marked as 'hardware', so there is a wholly artificial division
between packages.
I would prefer the whole 'hardware' attribute was dropped and give platform
developers, and application developers the ability to control their own
hardware configuration without having to edit repository files. It should
be possible for the HAL developers to list any driver packages appropriate
for their hardware in the target definition; and possible for app
developers to add/remove from that as needed. There's always been plug-in
modules, expansion buses etc., nevermind modern configurable hardware, so
assuming hardware is static seems archaic.
I suspect it has cost people more wasted time and confusion than it has
ever saved. I've had to jump through these hoops, and not seen any benefit.
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-18 17:16 ` Jonathan Larmour
@ 2008-11-18 18:39 ` Bart Veer
2008-11-18 18:45 ` Jonathan Larmour
0 siblings, 1 reply; 14+ messages in thread
From: Bart Veer @ 2008-11-18 18:39 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: ecos-devel
>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
Jifl> Bart Veer wrote:
>>>>>>> "Oliver" == oliver munz @ s p e a g <munz@speag.ch> 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.
Jifl> I've said this before and will just take the opportunity to
Jifl> say it again: the 'hardware' attribute just gets in the way.
Jifl> You can't have packages in the target definition that aren't
Jifl> 'hardware', and you can't add packages which are marked as
Jifl> 'hardware', so there is a wholly artificial division between
Jifl> packages.
Jifl> I would prefer the whole 'hardware' attribute was dropped
Jifl> and give platform developers, and application developers the
Jifl> ability to control their own hardware configuration without
Jifl> having to edit repository files. It should be possible for
Jifl> the HAL developers to list any driver packages appropriate
Jifl> for their hardware in the target definition; and possible
Jifl> for app developers to add/remove from that as needed.
Jifl> There's always been plug-in modules, expansion buses etc.,
Jifl> nevermind modern configurable hardware, so assuming hardware
Jifl> is static seems archaic.
Jifl> I suspect it has cost people more wasted time and confusion
Jifl> than it has ever saved. I've had to jump through these
Jifl> hoops, and not seen any benefit.
The hardware attribute is an extremely poor substitute for what I had
planned in the original design of the configuration system, but in my
opinion right now is not the right time to have that discussion. The
SPI and I2C subsystems work just fine when developers follow the
documentation, although admittedly it would have been useful if there
had been reference driver implementations checked in at the same time
as the generic packages. AFAIK nobody is planning any further work on
the host-side tools before 3.0, so the hardware attribute will stay
for the foreseeable future.
Bart
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-18 18:39 ` Bart Veer
@ 2008-11-18 18:45 ` Jonathan Larmour
0 siblings, 0 replies; 14+ messages in thread
From: Jonathan Larmour @ 2008-11-18 18:45 UTC (permalink / raw)
To: Bart Veer; +Cc: ecos-devel
Bart Veer wrote:
>
> The hardware attribute is an extremely poor substitute for what I had
> planned in the original design of the configuration system, but in my
> opinion right now is not the right time to have that discussion.
Yes I wasn't proposing changing it now. Just mentioning while it was on-topic.
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: What is the reason to...
2008-11-07 18:20 ` oliver munz @ s p e a g
2008-11-08 21:40 ` Gábor Török
2008-11-09 13:35 ` Bart Veer
@ 2008-11-23 21:43 ` Bart Veer
2 siblings, 0 replies; 14+ messages in thread
From: Bart Veer @ 2008-11-23 21:43 UTC (permalink / raw)
To: munz; +Cc: ecos-devel
>>>>> "Oliver" == oliver munz @ s p e a g <munz@speag.ch> writes:
Oliver> In this case templates like:
Oliver> target at91sam7sek {
Oliver> alias { "Atmel AT91SAM7SEK evaluation board" at91_at91sam7sek }
Oliver> packages { CYGPKG_HAL_ARM
Oliver> CYGPKG_HAL_ARM_AT91
Oliver> CYGPKG_HAL_ARM_AT91SAM7
Oliver> CYGPKG_HAL_ARM_AT91SAM7SEK
Oliver> CYGPKG_IO_SERIAL_ARM_AT91
Oliver> CYGPKG_DEVS_FLASH_AT91
Oliver> CYGPKG_DEVS_SPI_ARM_AT91
Oliver> CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC
Oliver> CYGPKG_DEVS_USB_AT91
Oliver> }
Oliver> description "
Oliver> The at91sam7sek target provides the packages needed to run eCos
Oliver> on an
Oliver> Atmel AT91SAM7S-EK evaluation board."
Oliver> }
Oliver> should be changed?
Oliver> They are missing the CYGPKG_IO_SPI and so on...
As per http://ecos.sourceware.org/ml/ecos-devel/2008-11/msg00012.html,
yes. However it looks like other changes are needed. If you just add
CYGPKG_IO_SPI to the target definition (not template, that is
something else) then you end up with SPI driver code even in
executables that do not use SPI. Just build the default config, then
do an objdump of install/tests/kernel/current/tm_basic, and you'll see
the spi functions.
Changing spi_at91.cdl, removing the -library=libextras.a from the
compile spi_at91_init.cxx, sorts out that problem. However I don't
have a suitable board handy right now so I cannot check that
everything still works.
So somebody needs to do some experimenting and provide a patch.
Bart
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-11-23 21:43 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-04 14:46 What is the reason to oliver munz @ s p e a g
2008-11-04 18:57 ` Bart Veer
2008-11-07 18:20 ` oliver munz @ s p e a g
2008-11-08 21:40 ` Gábor Török
2008-11-08 23:25 ` Oliver Munz @ SNR
2008-11-09 11:08 ` Gary Thomas
2008-11-09 13:52 ` Bart Veer
2008-11-09 13:46 ` Bart Veer
2008-11-09 15:34 ` Frank Pagliughi
2008-11-09 13:35 ` Bart Veer
2008-11-23 21:43 ` Bart Veer
2008-11-18 17:16 ` Jonathan Larmour
2008-11-18 18:39 ` Bart Veer
2008-11-18 18:45 ` Jonathan Larmour
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).