What is the reason to...

What is the reason to...

[oliver munz @ s p e a g]

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

Re: What is the reason to...

[Bart Veer]

>>>>> "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.

Re: What is the reason to...

[oliver munz @ s p e a g]

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
>
>   

Re: What is the reason to...

[Gábor Török]

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
>>
>>

Re: What is the reason to...

[Oliver Munz @ SNR]

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
>>>
>>>
>>>       
>
>
>   

Re: What is the reason to...

[Gary Thomas]

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
------------------------------------------------------------

Re: What is the reason to...

[Bart Veer]

>>>>> "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.

Re: What is the reason to...

[Bart Veer]

>>>>> "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.

Re: What is the reason to...

[Bart Veer]

>>>>> "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.

Re: What is the reason to...

[Frank Pagliughi]

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
>>>>>>
>>>>>>             

Re: What is the reason to...

[Jonathan Larmour]

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

Re: What is the reason to...

[Bart Veer]

>>>>> "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.

Re: What is the reason to...

[Jonathan Larmour]

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

Re: What is the reason to...

[Bart Veer]

>>>>> "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.