Re: [ECOS] Re: CYGPKG_DEVS_DISK_MMC "hardware"?

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes:

    John> Hi Peter
    John> Peter Niebert wrote:

    >> The package CYGPKG_DEVS_DISK_MMC which implements a disk driver
    >> for MMC cards via SPI has a "hardware" attribute in the ecos.db
    >> In order to make it run, a corresponding SPI device must be
    >> declared with a low level SPI driver (in my case AT91).
    >> 
    >> As a consequence of the "hardware" attribute, ecosconfig
    >> refuses to add this package. My feeling is, it should not be
    >> there and the "interface" declaration in the cdl script of the
    >> driver should be sufficient for requirements?

    John> The documentation for this package indicates that the
    John> presence of the hardware attribute is deliberate, but it's
    John> not clear why this should be necessary. I expect Bart Veer
    John> can explain. Bart?

The generic MMC package has no idea how the MMC socket is wired up on
any given board, e.g. how the chip select is wired up. Hence the
package needs some glue from elsewhere, usually the platform HAL, in
the form of a cyg_spi_device structure cyg_spi_mmc_dev0. Without that
platform-specific structure things are just not going to work.

Now, cyg_spi_mmc_dev0 can be provided in three places:

  1) the platform HAL, as part of the process of porting eCos to that
     platform. 
  2) some other package.
  3) application code.

Option (3) is a very bad idea. It means you can build a configuration
which depends on application code. Hence it is impossible to build the
testcases and verify the configuration. That leaves options (1) and
(2).

Next, consider some scenarios:

  1) there is an existing eCos port to a board with an MMC socket, but
     the existing port does not implement the MMC glue. The obvious
     thing to do is to patch the port, as per the porting section in
     the MMC documentation. Since you are already modifying existing
     eCos code, editing ecos.db as well to add the MMC package does
     not seem like a big issue.

     Note that the MMC package is active_if CYGPKG_IO_DISK, so if an
     application does not involve any disk I/O then the MMC package
     will be inactive and no code will be generated for it. Hence
     there are zero overheads associated with listing the MMC package
     in the ecos.db target entry.

  2) a board does not have an MMC socket but does have the SPI signals
     on an expansion connector, and an MMC socket has been hooked up
     to that. The existing eCos port cannot have known about that, so
     the MMC glue has to be added. There are three approaches:

     a) tweak the existing port as per (1) above. This may cause
        conflicts if the port gets updated in anoncvs.

     b) clone the existing port to produce a new platform HAL and a
        new ecos.db target entry. That may make more sense if the
        board has been extended in other ways. The cloned port can
        then have the MMC glue added.

     c) create a new HAL package to complement the platform HAL,
        containing cyg_spi_mmc_dev0 and similar glue for anything else
        you have attached to an expansion connector. Create a new
        ecos.db target entry which adds the new HAL package as well as
        the MMC driver. If desired, both the new package and the new
        target entry can live in a private repository using the
        multiple repository support, thus keeping the master
        repository pristine.

  3) this is a port to a new board, based on an existing one but with
     some added hardware including an MMC socket. Effectively this is
     just a variation of (2).

So, all sensible ways of adding MMC support to a port involve some
glue code in an eCos package, and often it also involves adding a new
ecos.db target entry. Also adding the MMC package to the appropriate
target entry does not seem like a lot of effort to me.

But does it gain anything? In my opinion, yes. It means that if you
want to include disk I/O support in your configuration, all that is
needed is an "ecosconfig add disk". Suddenly all the disk device
drivers associated with the target become active, and the devices are
available to your application. There is no need to also add various
device drivers etc. to your configuration, all that has been sorted
out for you as part of the porting process.

There is also less scope for user confusion. Again consider scenario
(1) above where there is an existing port without MMC support. Without
the hardware property a novice user would still be able to add the MMC
package to a configuration, even though there is no chance of it
working because the necessary glue has not been written. With the
hardware property the user will be told that what he is attempting is
not sensible. Hopefully he will then have the sense to read the
documentation and do all the work needed to port the MMC support,
instead of just expecting things to work by magic.

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.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss