From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13688 invoked by alias); 3 Sep 2007 07:04:19 -0000 Received: (qmail 13660 invoked by uid 22791); 3 Sep 2007 07:04:17 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Sep 2007 07:04:13 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1IS5vQ-00028v-00; Mon, 03 Sep 2007 09:00:44 +0200 Date: Mon, 03 Sep 2007 07:04:00 -0000 From: Andrew Lunn To: "Meiring, H, Mnr " Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20070903070044.GA8185@lunn.ch> Mail-Followup-To: "Meiring, H, Mnr " , ecos-discuss@ecos.sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] eCos info X-SW-Source: 2007-09/txt/msg00012.txt.bz2 On Sun, Sep 02, 2007 at 11:35:47PM +0200, Meiring, H, Mnr wrote: > > Hi all, > > What protection does eCos provide for MMU-less micro controllers, > for example when a process want to do memory altering outside its > permitted allocation area, and for that matter to protect itself > (the OS) eCos performance no memory protection at all. For deeply embedded systems, which eCos is target at, it is considered unnecessary overhead. > I have some simple questions regarding the HAL layer of eCos after > reading A Massa?s book on eCos. Redboot and eCos use the same > HAL. If redboot is compiled for ROM mode it produces a binary image > that is structured as defined on page 187, which include a HAL layer > and device drivers. Now if you compile the eCos default template, it > results in a library that contains the HAL and device drivers as > well? Resulting in 2 identical sets of HAL?s and device drivers? Is > this correct, or do I have the integration of it incorrect? And is > it possible to end with one HAL and device driver set? The ROM mode application and the RAM mode application each are complete. Each has its own eCos. > I want to load ecos and a couple of applications and be allowed at a > later stage to upgrade 1 or more of the applications without having > to load eCos with it again as shown in the example provided (I will > have very limited bandwidth and connection time to do upgrade). > I want to use reboot(purely as a bootloader), what optimization can > be done (with regards to Compiler settings and feature removal) once > the development is done and the system is to be built for production > purposes ? ie no debug. I removed the ?g option from the compiler > options and it reduced the image size significantly, any other > recommendations? Take a read of the man page for size, arm-elf-size. My guess is you are looking at the size of the elf, not the size of the image. -g should only make a small difference. You should be able to remove the GDB stubs. 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