This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: How to write a complicated bootloader?
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Stanislav Meduna <stano at meduna dot org>
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Sat, 11 Jul 2009 05:33:40 -0600
- Subject: Re: [ECOS] How to write a complicated bootloader?
- References: <4A5858BE.9000005@meduna.org>
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