This is the mail archive of the ecos-maintainers@sources.redhat.com 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]

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


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





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