From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10964 invoked by alias); 11 Jul 2009 09:36:25 -0000 Received: (qmail 10955 invoked by uid 22791); 11 Jul 2009 09:36:24 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 11 Jul 2009 09:36:15 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1MPZ02-0007mX-00; Sat, 11 Jul 2009 11:36:06 +0200 Date: Sat, 11 Jul 2009 09:36:00 -0000 From: Andrew Lunn To: Stanislav Meduna Cc: eCos Discussion Message-ID: <20090711093606.GI8175@lunn.ch> Mail-Followup-To: Stanislav Meduna , eCos Discussion References: <4A5858BE.9000005@meduna.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A5858BE.9000005@meduna.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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] How to write a complicated bootloader? X-SW-Source: 2009-07/txt/msg00067.txt.bz2 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