This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Self defining CDL interfaces

On Tue, 2003-09-30 at 04:22, Bart Veer wrote:
> >>>>> "Jifl" == Jonathan Larmour <> writes:
>     Jifl> Gary Thomas wrote:
>     >> There are many examples of CDL which have comments like this:
>     >> 
>     >> # FIXME: This really belongs in the NS DP83902A package
>     >> cdl_interface CYGINT_DEVS_ETH_NS_DP83902A_REQUIRED {
>     >> display   "NS DP83902A ethernet driver required"
>     >> }
>     >> 
>     >> These appear in target/platform instance CDL files.
>     >> 
>     >> Does anyone remember why this interface is not defined in the
>     >> common/platform-independent CDL file?
>     Jifl> Because those platform-independent CDL files are generally
>     Jifl> active_if that interface themselves. It's catch-22: the
>     Jifl> parent is active_if a cdl_interface, but if the parent
>     Jifl> contains that cdl_interface itself it can never be enabled
>     Jifl> because it's inactive!
>     Jifl> I'd like to know what Bart's idea of a real solution would
>     Jifl> be though. The only thing I can imagine is having a
>     Jifl> CYGPKG_DEVS_ETH_NS_DP83902A_REALLY within
>     Jifl> CYGPKG_DEVS_ETH_NS_DP83902A where the latter (the parent)
>     Jifl> contains the cdl_interface, but it's the latter that has the
>     Jifl> active_if. But this is icky fluff that just makes the whole
>     Jifl> lot more confusing.
>     Jifl> My preference would be for cdl_interfaces always to be
>     Jifl> active in the sense of being able to be implemented; so if
>     Jifl> their parent is inactive, then that's similar to having a
>     Jifl> no_define.
> A real solution? Sounds like a challenge.
> I think the key is to separate out the hardware definition from the
> device driver configuration options. When you have a selected a
> target that target will have certain chips, irrespective of whether or
> not the device drivers for those chips are loaded/active/enabled. So
> the cdl interfaces which specify the presence of those chips and
> perhaps precise characteristics should go into a separate part of the
> configuration hierarchy.
> A first stab at a solution, not fully thought through, would be
> something like this:
> cdl_component CYGHWR_TARGET {
>     display   "Target hardware details"
>     parent    ""
>     flavor    none
>     cdl_component CYGHWR_TARGET_INTERFACES {
>         display    "CDL interfaces implemented by this hardware"
>         flavor    none
>     }
>     # And possibly, in future, something like:
>         display    "Hardware characteristics"
>         flavor     none
>         # These would usually be in the architectural HAL. They might
>         # depend on HAL configuration options such as whether to run
>         # a chip in 32-bit or 64-bit mode.
>         cdl_option CYGNUM_TARGET_TYPES_SIZEOF_INT {
>             calculated 4
>         }
>         # This allows packages to provide sensible stack size options.
>             ...
>         }
>         ...
>     }
> }
> CYGHWR_TARGET_CHARACTERISTICS would be defined by the common HAL. A
> device driver would define an interface reparented below
> CYGHWR_TARGET_INTERFACES, and a platform HAL would implement it.
> The device driver can now have active_if dependencies on the interface
> without problems.
> For this to work cleanly I think we would need a guideline that
> everything below CYGHWR_TARGET is calculated, not configurable. It
> would be as if CYGHWR_TARGET was provided by a separate hardware
> definition tool. If e.g. a HAL allows you to set the processor
> endianness then there would be an option in the HAL to control this,
> and a calculated option below CYGHWR_TARGET which reflects the current
> setting. The HAL contains code so you can configure its behaviour. The
> hardware is basically fixed.

So, could you recommend how we might restructure things for a real 
target?  I'm afraid that generalities are a bit confusing to me at
this point.

Take the FRV400 for example.  It has an onboard DP83902 network 
controller.  This is one of the drivers that has these funny

Gary Thomas <>
MLB Associates

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]