From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25486 invoked by alias); 13 Apr 2003 00:51:49 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 25459 invoked from network); 13 Apr 2003 00:51:47 -0000 From: "Joakim Langlet" To: Subject: I want to contribute with a port to the Atmel EB55 board but..... Date: Sun, 13 Apr 2003 00:51:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2003-04/txt/msg00035.txt.bz2 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