public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Meiring, H, Mnr <meiring@sun.ac.za>" <meiring@sun.ac.za>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] eCos info
Date: Mon, 03 Sep 2007 07:04:00 -0000	[thread overview]
Message-ID: <20070903070044.GA8185@lunn.ch> (raw)
In-Reply-To: <FC829C66C7DA824A96A893C28F1B7AD969E891@STBEVS01.stb.sun.ac.za>

On Sun, Sep 02, 2007 at 11:35:47PM +0200, Meiring, H, Mnr <meiring@sun.ac.za> 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

      reply	other threads:[~2007-09-03  7:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-02 21:36 Meiring, H, Mnr <meiring@sun.ac.za>
2007-09-03  7:04 ` Andrew Lunn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070903070044.GA8185@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=meiring@sun.ac.za \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).