[ECOS] Porting question

[ECOS] Porting question

[Bob Koninckx]

Hi list,

I got stuck when porting ecos to motorola's mpc565 processor. This
variant is very similar to the mpc555, main differences lie in the on-
chip peripherals (3 vs 2 CAN controllers, different MIOS etc...). At
present, knowledge of on-chip peripherals is dealt with in the mpc5xx
variant code. Apparently, it does not belong there ...

I was thinking of introducing subvariants of mpc5xx for mpc555 and
mpc565 (similar to the quicc subvariant of mpc8xx). Considering the
similarities between mpc555 and mpc565, this would imply duplication of
lots of code.

Ideal would be to provide separate HALs for on-chip peripherals like
TouCAN, MIOS, QADC etc ... These HALs could then provide

 * interrupt vector definitions
 * interrupt mask / unmask / configure definitions

All the subvariants should do then is include the necessary device HALs
and no code duplication would be necessary any more. I see however also
some drawbacks with this approach:

 * the HAL directory is now processor / board oriented. Having a
directory TouCAN at the same level as e.g. mpc8xx does not seem logical.
Placing the device HALs in

 packages/hal/motorola/toucan
 packages/hal/motorola/mios
 packages/hal/motorola/qadc

is probably a better solution, especially since motorola uses the same
devices with other cores than powerpc.

 * How to generate unique interrupt vector definitions if it is no
longer done in one single location ?


All suggestions, comments are more than welcome,
Bob


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

Re: [ECOS] Porting question

[Gary Thomas]

On Fri, 2005-05-06 at 13:16 +0200, Bob Koninckx wrote:
> Hi list,
> 
> I got stuck when porting ecos to motorola's mpc565 processor. This
> variant is very similar to the mpc555, main differences lie in the on-
> chip peripherals (3 vs 2 CAN controllers, different MIOS etc...). At
> present, knowledge of on-chip peripherals is dealt with in the mpc5xx
> variant code. Apparently, it does not belong there ...
> 
> I was thinking of introducing subvariants of mpc5xx for mpc555 and
> mpc565 (similar to the quicc subvariant of mpc8xx). Considering the
> similarities between mpc555 and mpc565, this would imply duplication of
> lots of code.
> 
> Ideal would be to provide separate HALs for on-chip peripherals like
> TouCAN, MIOS, QADC etc ... These HALs could then provide
> 
>  * interrupt vector definitions
>  * interrupt mask / unmask / configure definitions
> 
> All the subvariants should do then is include the necessary device HALs
> and no code duplication would be necessary any more. I see however also
> some drawbacks with this approach:
> 
>  * the HAL directory is now processor / board oriented. Having a
> directory TouCAN at the same level as e.g. mpc8xx does not seem logical.
> Placing the device HALs in
> 
>  packages/hal/motorola/toucan
>  packages/hal/motorola/mios
>  packages/hal/motorola/qadc
> 
> is probably a better solution, especially since motorola uses the same
> devices with other cores than powerpc.
> 
>  * How to generate unique interrupt vector definitions if it is no
> longer done in one single location ?

Have you looked at how the SH HAL is structured?  Those processors
are similar in nature (lots of shared peripherals with a given
chip using some subset thereof).  It might be a way to go.

Also, if the differences are just number/type of peripherals, you
could use methods similar to what is used by 8xx/8xxx.  There, a 
given platform (CPU) will "implement" certain functionality.  The
generic code (quicc, etc) then knows how to support that.  

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

Re: [ECOS] Porting question

[Andrew Lunn]

On Fri, May 06, 2005 at 01:16:37PM +0200, Bob Koninckx wrote:
> Hi list,
> 
> I got stuck when porting ecos to motorola's mpc565 processor. This
> variant is very similar to the mpc555, main differences lie in the on-
> chip peripherals (3 vs 2 CAN controllers, different MIOS etc...). At
> present, knowledge of on-chip peripherals is dealt with in the mpc5xx
> variant code. Apparently, it does not belong there ...
> 
> I was thinking of introducing subvariants of mpc5xx for mpc555 and
> mpc565 (similar to the quicc subvariant of mpc8xx). Considering the
> similarities between mpc555 and mpc565, this would imply duplication of
> lots of code.
> 
> Ideal would be to provide separate HALs for on-chip peripherals like
> TouCAN, MIOS, QADC etc ... These HALs could then provide
> 
>  * interrupt vector definitions
>  * interrupt mask / unmask / configure definitions
> 
> All the subvariants should do then is include the necessary device HALs
> and no code duplication would be necessary any more. I see however also
> some drawbacks with this approach:
> 
>  * the HAL directory is now processor / board oriented. Having a
> directory TouCAN at the same level as e.g. mpc8xx does not seem logical.
> Placing the device HALs in
> 
>  packages/hal/motorola/toucan
>  packages/hal/motorola/mios
>  packages/hal/motorola/qadc
> 
> is probably a better solution, especially since motorola uses the same
> devices with other cores than powerpc.
> 
>  * How to generate unique interrupt vector definitions if it is no
> longer done in one single location ?

You could put the device drivers under the devs directory. eg

packages/devs/can/motorola/toucan
packages/devs/adc/motorola/qadc
packages/devs/io/motorola/mios

The HAL provides all the definitions for where the devices live in
memory, the interupts etc. 

        Andrew

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