* Re: [ECOS] Re: CYGPKG_DEVS_DISK_MMC "hardware"?
2009-05-27 7:40 ` [ECOS] " John Dallaway
@ 2009-05-27 10:51 ` Bart Veer
0 siblings, 0 replies; 3+ messages in thread
From: Bart Veer @ 2009-05-27 10:51 UTC (permalink / raw)
To: John Dallaway; +Cc: peter, ecos-discuss
>>>>> "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
^ permalink raw reply [flat|nested] 3+ messages in thread