[ECOS] package definition with CDL

[ECOS] package definition with CDL

[Jörg Rapka]

Hello

I'm about to port eCos to M68k. My target uses the M68331 microcontroller.

I have defined a package "M68k" as architecture HAL and I have defined
a package "my_target" as platform HAL.

I try to find out what are the HAL packages between.

The M68331 microcontroller is one of the M683xx family. So the M683xx is a
variant
of the M68k architecture. My first idea was to define the package "M683xx"
as
architecture variant HAL. Within this package the current used
microcontroller should
be selectable (e.g. M68331, M68332,...). Since my target board need the
M68331 (e.g. the
M68332 is not compatible with the M68331), the M68331 should be active in
the "M683xx"
architecture variant HAL package, if "my_target" platform HAL is used.
How can I implement this dependency in CDL?

Summary:
My target "my_target" is defined by the following packages:
- M68k architecture HAL
- M683xx architecture variant HAL (microcontroller M68331 must be selected)
- my_target platform HAL

Or any other idea how to define the packages for the M68k?

Best regards
Joerg

Re: [ECOS] package definition with CDL

[Bart Veer]

>>>>> "Joerg" == =?iso-8859-1?B?SvZyZyBSYXBrYQ==?=  <iso-8859-1> writes:

    Joerg> Hello
    Joerg> I'm about to port eCos to M68k. My target uses the M68331
    Joerg> microcontroller.

    Joerg> I have defined a package "M68k" as architecture HAL and I
    Joerg> have defined a package "my_target" as platform HAL.

    Joerg> I try to find out what are the HAL packages between.

    Joerg> The M68331 microcontroller is one of the M683xx family. So
    Joerg> the M683xx is a variant of the M68k architecture. My first
    Joerg> idea was to define the package "M683xx" as architecture
    Joerg> variant HAL. Within this package the current used
    Joerg> microcontroller should be selectable (e.g. M68331,
    Joerg> M68332,...). Since my target board need the M68331 (e.g.
    Joerg> the M68332 is not compatible with the M68331), the M68331
    Joerg> should be active in the "M683xx" architecture variant HAL
    Joerg> package, if "my_target" platform HAL is used. How can I
    Joerg> implement this dependency in CDL?

    Joerg> Summary:
    Joerg> My target "my_target" is defined by the following packages:

    Joerg> - M68k architecture HAL
    Joerg> - M683xx architecture variant HAL (microcontroller M68331
    Joerg>   must be selected) 
    Joerg> - my_target platform HAL

    Joerg> Or any other idea how to define the packages for the M68k?

This combination of M68k architectural HAL, M683xx variant HAL, and
target-specific platform HAL sounds right.

In the variant HAL you will want one or more configuration options to
control the specific microcontroller. This could be a single option,
e.g.:

  cdl_option xxxHWR_HAL_M683XX_VARIANT {
      flavor data
      legal_values { M68331 M68332 }
  }

(The CDL naming conventions allow you to pick a suitable xxx prefix.
If you intend to contribute the port and assign copyright then feel
free to use CYG, but that is not required).

In the variant HAL code you can then use
"#ifdef xxxHWR_HAL_M683XX_VARIANT_M68331" for 68331-specific code,
and so on. In the platform HAL you can have a "requires" property of
the form:

  requires { xxxHWR_HAL_M683XX_VARIANT == "M68331" }

and everything should work pretty much as expected. If the default
value for the variant HAL configuration option is M68331 then
everything is fine. If the default value is something else then the
configuration tools will detect the conflict and the inference engine
should resolve it automatically (as long as there are no complicated
dependencies in this area). If the user explicitly changes the
variant to something else then the configuration tools will detect and
report the conflict - the user can still proceed, but there are no
guarantees that anything will work.

There is one small problem with this approach: what happens if a third
party wants to add support for another variant by adding another
package. There is no way for this new package to extend the
legal_values property for xxxM683XX_HAL_M68K_VARIANT. Theoretically
the CDL language could be extended to allow package A to override
properties of another package B, but then the maintainer of package B
would no longer have any idea about what is going to end up in that
package's configuration header file and anything could happen.

Instead each microprocessor variant is controlled by a separate
boolean configuration option, implementing a common interface, and
that interface has a constraint that there is only one implementation
(i.e. that only one microprocessor variant has been selected).

  cdl_interface xxxINT_HAL_M683XX_VARIANT {
      requires { 1 == xxxINT_HAL_M683XX_VARIANT }
      ...
  }

  cdl_option xxxHWR_HAL_M683XX_M68331 {
      implements xxxINT_HAL_M683XX_VARIANT
      ...
  }

  cdl_option xxxHWR_HAL_M683XX_M68332 {
      implements xxxINT_HAL_M683XX_VARIANT
      ...
  }

A third party packages could then define additional variant options
without having to change an existing package.

The platform-specific HAL can require a particular variant:

  requires xxxHWR_HAL_M683XX_M68331

and everything should get sorted out by the configuration tools as
before.

There should be some examples of this sort of thing in the existing
HAL sources - the PowerPC MPC8xx support might be a good starting
point.

Bart

Re: [ECOS] package definition with CDL

[Robin Kirkham]

On Tuesday, 4 July 2000, joerg.rapka@duagon.com wrote:

> I'm about to port eCos to M68k. My target uses the M68331 microcontroller.
> 
> I have defined a package "M68k" as architecture HAL and I have defined
> a package "my_target" as platform HAL.
> 
> I try to find out what are the HAL packages between.
> 
> The M68331 microcontroller is one of the M683xx family. So the M683xx is a
> variant
> of the M68k architecture. My first idea was to define the package "M683xx"
> ...
>
> Or any other idea how to define the packages for the M68k?

Beware, the 68k family is complicated. Many people assume, for instance, 
that all the 683xx have the same CPU, but different IO peripherals.
This is not true.

Motorola use at least three different CPU cores in the 683xx series
microcontrollers:

    EC68000
    CPU32
    CPU32+

These are in addition to the cores of their standard microprocessor line,
68000, 68010, 68020, 68030, 68040, 68060. The EC68000 is maybe the
same as the 68000, but the CPU32 and CPU32+ are both unique.

[There is also the Coldfire line to consider. gcc regards this as part of
the 68k family.]

This suggests to me a four-level HAL structure:

    + architecture 68k HAL
    + architecture variant HAL
	(for each of the 68000, 68010, 68020, ..., EC68000, CPU32,
	    and CPU32+ cores)
    + chip variant HAL
	(for each of the 68000, 68010, 68020, ..., 68300, 68331, 68332,
	    68333, ..., chips)
    + platform HAL
    
I don't know enough about eCos and in particular its HALs to comment further.

I would, however, hope that an eCos HAL structure could be developed that
fits the whole 68k family (even if not all tartgets are initially supported)
without lots of "the same but different" code.


Robin Kirkham			CSIRO Manufacturing Science and Technology
Project Engineer		Locked Bag 9, Preston 3072, Australia
robin.kirkham@cmst.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7853

Re: [ECOS] package definition with CDL

[Bart Veer]

>>>>> "Robin" == Robin Kirkham <Robin.Kirkham@cmst.csiro.au> writes:

    <snip>

    Robin> Beware, the 68k family is complicated. Many people assume,
    Robin> for instance, that all the 683xx have the same CPU, but
    Robin> different IO peripherals. This is not true.

    Robin> Motorola use at least three different CPU cores in the
    Robin> 683xx series microcontrollers:

    Robin>     EC68000
    Robin>     CPU32
    Robin>     CPU32+

    Robin> These are in addition to the cores of their standard
    Robin> microprocessor line, 68000, 68010, 68020, 68030, 68040,
    Robin> 68060. The EC68000 is maybe the same as the 68000, but the
    Robin> CPU32 and CPU32+ are both unique.

    Robin> [There is also the Coldfire line to consider. gcc regards this as part of
    Robin> the 68k family.]

    Robin> This suggests to me a four-level HAL structure:

    Robin>     + architecture 68k HAL
    Robin>     + architecture variant HAL
    Robin> 	(for each of the 68000, 68010, 68020, ..., EC68000, CPU32,
    Robin> 	    and CPU32+ cores)
    Robin>     + chip variant HAL
    Robin> 	(for each of the 68000, 68010, 68020, ..., 68300, 68331, 68332,
    Robin> 	    68333, ..., chips)
    Robin>     + platform HAL
    
    Robin> I don't know enough about eCos and in particular its HALs
    Robin> to comment further.

    Robin> I would, however, hope that an eCos HAL structure could be
    Robin> developed that fits the whole 68k family (even if not all
    Robin> tartgets are initially supported) without lots of "the same
    Robin> but different" code.

I am fairly confident that the eCos configuration technology can cope
with whatever HAL structure is needed to support the 68K family - but
it may not be possible to figure out the optimal organization just
yet. 

Increasing the number of packages has both advantages and
disadvantages. It makes it easier to add support for more variants,
hopefully without having to change any existing packages. It reduces
the need for #ifdef's or similar techniques in any particular package
because there are fewer possibilities to cope with. The main
disadvantage is the risk of code duplication. This is not just for the
C source code, you also need to consider the other files involved such
as the CDL scripts. Some sort of balance needs to be struck.

Since the work is being done by a net contributor, I would be happy to
see any reasonable 68K support added to the system. There may well be
problems with the initial implementation, which can be sorted out in
time. In fact the first eCos release had no support for architectural
variants at all, but gradually Red Hat has been adding such support to
the appropriate HAL's as the need arises.

Don't get me wrong: if people want to discuss the best way to organize
68K HAL packages that is fine - as long as it does not interfere too
much with actually getting the code written and usable by the various
people who want it.

Bart Veer // eCos net maintainer