[ECOS] Recommodation for start of new chip-family support

[ECOS] Recommodation for start of new chip-family support

[Manuel Borchers]

Hi all,

I'm in the process of starting a research-project at the Technical
University in Berlin together with a SoC firm located in Berlin
(Hilscher SoC Technology [hilscher.com] where I've already been working
and designing some modules in that processor family).

The first part of the research project is porting eCos to this
processor-family. So I'll try to give a quick overview of the problem
I'm currently facing.

The processor-family has 4 (main) members as of today. They share
some/many periphherals but are also somewhat different in some aspects.
All relevant members incorporate ARM9 system CPUs.

The processors:
netX500 / netX100  use an ARM926 with cache and MMU
netX50             uses an ARM966 (without any cache and MMU)
netX10             uses an ARM966 (with tightly coupled memory)

Hilscher (located in Hattersheim) is designen products / software in the
automation area. They have a lot of different boards for each of the
processors in the portfolio which differ in what is placed (amount of
SDRAM, type of flash, used UART channels, etc).

I'd like to support as much as possible or better said, I'd like to
establish a starting point to add many boards without doing too much
coding and sharing the same codebase.

I started with the HAL port for one of the boards. I chose to do a
board-level port to use the ARM9 variant infrastructure. But I'm getting
the feeling, that this isn't the right way to go, because the UART
(code) for example is the same on all the boards for all the processors.

So, I'd like to have some inputs from people that do know the eCos
codebase better than I or may already have been at a similar point as I
am now.

Any pointers and hints are very welcome! I guess I will be sticking
around and asking a LOT of questions in the future ;)


Cheers,
Manuel

-- 
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] Recommodation for start of new chip-family support

[Manuel Borchers]

[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]

Hi again,

first of all thanks jerzy for your quick answer (did your message arrive
at the list?)

I'm replying to myself to refine my thoughts a bit in reaction to
jerzy's answer.

Am Donnerstag, den 22.04.2010, 15:33 +0200 schrieb Manuel Borchers:
> Hilscher (located in Hattersheim) is designen products / software in the
> automation area. They have a lot of different boards for each of the
> processors in the portfolio which differ in what is placed (amount of
> SDRAM, type of flash, used UART channels, etc).
> 
> I'd like to support as much as possible or better said, I'd like to
> establish a starting point to add many boards without doing too much
> coding and sharing the same codebase.
> 
> I started with the HAL port for one of the boards. I chose to do a
> board-level port to use the ARM9 variant infrastructure. But I'm getting
> the feeling, that this isn't the right way to go, because the UART
> (code) for example is the same on all the boards for all the processors.

What I wanted to stress here is the hugh amount of boards that are
available. I'll tyr to show a small hierarchy:

netX-Family
-> netX500 -> NXHX500-RE
           -> NXHX500-FB
           -> NXHX500-ETM
           -> NXSB100
           -> NDSB
           -> NXBB-HMI
           -> ...
-> netX50  -> NXHX50-RE
           -> NXHX50-ETM
           -> ...
-> netX10  -> NXHX10-RE
           -> ...

I guess you get the point.
So, why don't I want to make board-level ports? Because there is much
common board-level init stuff (configuring multiplex options for IOs,
the simple polles UART code most ARM ports are using, ...) that
sometimes depends on the chip type, sometimes it's even common to all
chips (i.e. UART). Often it only depends on things like how many UARTs
are there on the board.

When I would do board-level ports, I would have to have the board-init
stuff (that is mostly common) for each of these boards. When something
needs to be corrected/added, I would have to do this for ALL boards.

That's the reason, why I'm asking the list. Wouldn't be a variant port
be better in this scenario? I.e. I would implement the init stuff,
polled serial driver in the common variant port and just use defines by
the board selection to do the specifics in the variant code?

Or are there other/better aproaches to my problem?


Cheers,
Manuel


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [ECOS] Recommodation for start of new chip-family support

[Ross Younger]

Manuel Borchers wrote:
> So, why don't I want to make board-level ports? Because there is much
> common board-level init stuff (configuring multiplex options for IOs,
> the simple polles UART code most ARM ports are using, ...) 
> [...]
> Wouldn't be a variant port be better in this scenario?

I'm not sure variants are the right answer here, but I'm prepared to be
proven wrong.

You could create a single board HAL to cope with all the boards, with
appropriate CDL options to select between them. You would still create
multiple target entries in ecos.db - they would set_value appropriately as
well as pulling in the right set of hardware packages.

Also, you might put common code like the UART drivers into their own
package(s) and pull them in from the relevant targets. It can be tricky to
judge whether this is better than putting the code in a single board HAL -
might the code be reusable on other CPUs of the same family on different boards?


Ross

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  www.ecoscentric.com

-- 
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] Recommodation for start of new chip-family support

[jerzy dyrda]

Hi Manuel,
On Thursday 22 April 2010 22:22:43 Manuel Borchers wrote:
> first of all thanks jerzy for your quick answer (did your message arrive
> at the list?)
I suppose wrong account I used.

> > I started with the HAL port for one of the boards. I chose to do a
> > board-level port to use the ARM9 variant infrastructure. But I'm getting
> > the feeling, that this isn't the right way to go, because the UART
> > (code) for example is the same on all the boards for all the processors.
>
> What I wanted to stress here is the hugh amount of boards that are
> available. I'll tyr to show a small hierarchy:
> netX-Family
> -> netX500 -> NXHX500-RE
>            -> NXHX500-FB
>            -> NXHX500-ETM
>            -> NXSB100
>            -> NDSB
>            -> NXBB-HMI
>            -> ...
> -> netX50  -> NXHX50-RE
>            -> NXHX50-ETM
>            -> ...
> -> netX10  -> NXHX10-RE
>            -> ...

My suggestion is :
hal/arm/netx/netx500 <- all board variant based on netx500 controller i.e.
-> NXHX500-RE
-> NXHX500-FB
-> NXHX500-ETM
-> NXSB100
-> NDSB
-> NXBB-HMI
the same scenario for other controller
hal/arm/netx/netx50
hal/arm/netx/netx10

hal/arm/netx/var <- common code like initialization of PLL, IO, memory what 
ever which doesn't fit to /devs location will be placed here

> So, why don't I want to make board-level ports? Because there is much
> common board-level init stuff (configuring multiplex options for IOs,
> the simple polles UART code most ARM ports are using, ...) that
> sometimes depends on the chip type, sometimes it's even common to all
> chips (i.e. UART). Often it only depends on things like how many UARTs
> are there on the board.
UART and other driver will be located in /devs in turn proper hal variant e.g. 
NXHX50-RE will provide such information like number of UARTs

-- 
Miłego dnia / Best regards
jerzy 

--
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] Recommodation for start of new chip-family support

[Manuel Borchers]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

Hi Ross,
hi jerzy,

Am Freitag, den 23.04.2010, 10:43 +0100 schrieb Ross Younger: 
> Manuel Borchers wrote:
> You could create a single board HAL to cope with all the boards, with
> appropriate CDL options to select between them. You would still create
> multiple target entries in ecos.db - they would set_value appropriately as
> well as pulling in the right set of hardware packages.

Thank you both for your suggestions. I'm going to try Ross way, so I'm
doing platform-level ports and will try to support the different boards
using CDL options (will do and try that later on, first the porting is
more important for me).


> Also, you might put common code like the UART drivers into their own
> package(s) and pull them in from the relevant targets. It can be tricky to
> judge whether this is better than putting the code in a single board HAL -
> might the code be reusable on other CPUs of the same family on different boards?

I was referring to the polling-based simple UART driver, that seems to
be somewaht common to ARM9 ports. The driver is implemented on the
platform level. But I'll write about that in a second mail.

Thanks for your suggestions and help!
Cheers,
Manuel

-- 
manuel@matronix.de
http://www.matronix.de

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]