I want to contribute with a port to the Atmel EB55 board but.....

I want to contribute with a port to the Atmel EB55 board but.....

[Joakim Langlet]

Dear maintainers,

To start with, I want to say that I think eCos is great. I have seen a lot
of software since I started to work in this industry back in 1977 and I
couldn't have done this better myself. Great job! Still, I have a problem
with some aspects of it.

There is something wrong with the hierarchy currently present in eCos
package definitions.

I want to contribute with some patches for the ATMEL EB55 board, but there
is a problem with the current structure. The AT91 branch is represented by
the EB40 board, rather than the processor on the board.
The AT91 family of processors consists of a number of processors and they
are *not* compatible.

Since a board is a processor with some memories and peripherals, this should
be reflected in the package structure of eCos. A board should be "built" by
referring to a processor definition and some description of the other
properties of the board.

The ATMEL EB55 board contains an AT91M55800A processor, other memories and
peripherals.

How should I make the build process, the source tree and "configtool" tell
the difference?

I could start putting "#ifdef AT91M55800A"-stuff in there, but it is not a
clean solution in the current structure.

There are also references to "EB40" all over the code. "EB40" is just one of
many boards that could re-use large parts of the AT91 code. The code is
actually currently written for the AT91R40807 processor.

It would be much better if the code did not refer to evaluation boards at
all, but had "#ifdef"s for the processors in the families. Then there should
be some means to package the processor with definitions of the circuits
surrounding the processor so that a "board" can be defined. I think the
board specific definitions should be kept in packages added to the build
process, but separate from the selection of processor or something like
that.

At some point in time, most developers will leave their development boards
and aim for their own hardware. A structure where the processor is defined,
rather than a board, makes it easier to make the configtool build eCos for
the new hardware.

Do you have any suggestion how I should get the AT91M55800A into the
structure for AT91 in the source-tree and in the build process in the short
term without destroying the current structure?

Best regards,

  Joakim Langlet
  Seaview AB
  Box 79
  SE-179 04 Sweden
  +46-70-621 05 62

Re: I want to contribute with a port to the Atmel EB55 board but.....

[Nick Garnett]

"Joakim Langlet" <Joakim.Langlet@seaview.se> writes:

> 
> Do you have any suggestion how I should get the AT91M55800A into the
> structure for AT91 in the source-tree and in the build process in the short
> term without destroying the current structure?

First, take a look at the patches submitted by Thomas Koeller and Tim
Drury (search for EB40 in the ecos-patches list archive). These do
exactly what you suggest and split the AT91 HAL into a variant part
and a platform part. So an EB55 port should now be easy to do.

However, I am currently in the process of sorting these patches out,
ensuring that they are up to date and function in the current source
tree, are documented and tested etc. In addition to EB40 and EB40A
boards, I also have an EB42 and an EB55 here, so I'll be adding
platform HALs for those two boards too.

This is something of a background task at present, so gets interrupted
for more important jobs, but if you are prepared to wait a while then
there will be an EB55 port eventually. Alternatively, if you want to
contribute and do the EB55 port yourself then go ahead. Take a look at
how Tim added the EB40A port for pointers. Let me know if you are
going to do this -- but bear in mind that given a clear run this week
I'll probably be ready to do the EB55 port in a few days time.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts