public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Stanislav Meduna <stano@meduna.org>
Cc: eCos Discussion <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] How to write a complicated bootloader?
Date: Sat, 11 Jul 2009 09:36:00 -0000	[thread overview]
Message-ID: <20090711093606.GI8175@lunn.ch> (raw)
In-Reply-To: <4A5858BE.9000005@meduna.org>

On Sat, Jul 11, 2009 at 11:17:50AM +0200, Stanislav Meduna wrote:
> Hi,
> 
> I have a hardware with a complicated ethernet device that
> is not usable in a polled mode (or at least I don't have enough
> documentation to be able to use it in such a way). There
> is an OEM driver needing all kind of stuff (including eCos
> kernel) to run, that works fine in a regular application.
> 
> The hardware has a serial port, which is enough for debugging,
> but pain in the you know where for downloading our 2+ MB large
> binary over max. 115200 bps. In the field this serial port
> won't be available at all, so the only way to upgrade the device
> is via ethernet.
> 
> What I'd like to have is some kind of bootloader, that
> is able to
> - load the application via ethernet
> - manipulate the flash (application upgrade and at least
>   initialize the jffs, even better to access it filewise)
> - start the loaded application
> - support debugging the application at least over serial
>   line including the asynchronous ctrl-c support
>   (ethernet in a way of gdbserver would be nice, but
>   I imagine this can't be achieved in the eCos architecture
>   where the application and OS can't be really separated)

If your flash is big enough, which it probably is if you are using
jffs2, it might make sense to have two eCos applications, plus
redboot. One of your applications is your real applications. The other
is a "loader" application, which uses full eCos so you have access to
your ethernet via its poor driver. The loader application loads your
real application into RAM using tftp etc, and then writes it to flash.

> Is there any special magic in loading an application somewhere
> into memory and transfer control to it, while leaving the
> GDB stubs in the bootloader?

This should just work for any RAM applications, using the default
configuration. Basically, a ROM application, eg Redboot provides the
gdb stubs. A RAM application uses the 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:[~2009-07-11  9:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-11  9:18 Stanislav Meduna
2009-07-11  9:36 ` Andrew Lunn [this message]
2009-07-11 11:33 ` Gary Thomas
2009-07-11 12:11   ` Stanislav Meduna
2009-07-11 15:02     ` Chris Holgate

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=20090711093606.GI8175@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=stano@meduna.org \
    /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).