[ECOS] How to write a complicated bootloader?

[ECOS] How to write a complicated bootloader?

[Stanislav Meduna]

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)


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? For the development cycle
I imagine something like:

- connect with the gdb over serial
- connect with a telnet-like interface over ethernet
- initiate a tftp load
- run the application
- the application loads, runs and breaks into the gdb
  as soon as the basic initialization is done (everything
  else in the bootloader is now dead, only the vectors
  needed for serial comm remain)

Is there information (and examples) available on how to approach
this?


Many thanks for hints
-- 
                                   Stano

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] How to write a complicated bootloader?

[Andrew Lunn]

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

Re: [ECOS] How to write a complicated bootloader?

[Gary Thomas]

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)
> 
> 
> 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? For the development cycle
> I imagine something like:
> 
> - connect with the gdb over serial
> - connect with a telnet-like interface over ethernet
> - initiate a tftp load
> - run the application
> - the application loads, runs and breaks into the gdb
>   as soon as the basic initialization is done (everything
>   else in the bootloader is now dead, only the vectors
>   needed for serial comm remain)
> 
> Is there information (and examples) available on how to approach
> this?
> 
> 
> Many thanks for hints

Rather than reinvent the wheel (or maybe fire...), I think you'd
be better off just getting your ethernet device driver running
with RedBoot.  eCos network drivers use the same API whether they
are running in a full eCos application (using interrupts) or as
part of RedBoot (polled), so it should be pretty easy to get it
to work if you already have code that runs with a full eCos system.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] How to write a complicated bootloader?

[Stanislav Meduna]

Gary Thomas wrote:

> Rather than reinvent the wheel (or maybe fire...), I think you'd
> be better off just getting your ethernet device driver running
> with RedBoot.

This is a realtime ethernet processor with integrated
switch, capable of doing things like isochronous transfers
on its own. The driver itself is 6 MB source (after me
throwing away things we won't need for sure, which itself
took nearly a week), there are some 64 interrupt
sources etc.

The vendor obviously thinks that a good documentation
is something that should not be available - same old game :(

So while I'd much prefer to get the driver working with
RedBoot (I've already looked into this), my gut feeling
is that in the end reinventing the wheel will be cheaper.
And I can estimate the work needed quite reliably, compared
to trying to estimate reverse-engineering some ugly poorly
documented 3rd-party code... this is a project with deadline
that has to be met.

Andrew Lunn wrote:

> 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.

Okay, that's what I also thought of as one of the possibilities.

Thanks
-- 
                                 Stano

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] How to write a complicated bootloader?

[Chris Holgate]

Stanislav Meduna wrote:
> Andrew Lunn wrote:
> 
>> 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.
> 
> Okay, that's what I also thought of as one of the possibilities.

An alternative which I'm using for my current project is to make the
bootloader as dumb as possible - just capable of verifying a new
firmware image in a local SPI flash and then copying it over to the main
flash area when requested.  That way the new firmware can be transferred
to the device under control of the application (using the fully featured
driver).  My particular SPI bootloader is coded 'on the metal' for the
STM32, but I'm sure it wouldn't be too hard to get Redboot to provide
the same functionality.

Chris.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss