From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: Gary Thomas , Andrew Lunn , eCos Disuss Subject: Re: [ECOS] RedBoot porting Date: Tue, 09 Jan 2001 08:57:00 -0000 Message-id: <20010109110044.A12235@visi.com> References: <20010108171508.U10158@biferten.ma.tech.ascom.ch> <20010109095031.W10158@biferten.ma.tech.ascom.ch> X-SW-Source: 2001-01/msg00120.html On Tue, Jan 09, 2001 at 09:50:31AM +0100, Andrew Lunn wrote: > > I hadn't thought about this exactly. What I've been thinking > > about is the framework withing RedBoot to allow for an update > > in a single command, with backout magic to make it safe. > At the moment the design of redboot stops the application doing > the upgrade. Since it runs from FLASH and can be invoked at any > time as soon as you start a write to the flash your application > could die at any time. Its actually worse than that, you cannot > use the FLASH for anything, eg local configuration information. That's one of my concerns about running RedBoot from ROM: If I run RedBoot from ROM, then I can't allow the application to use any of the virtual vector stuff. The application needs to be able to write to flash, and if RedBoot is running from flash it's not going to be available during a flash burn. > In my opinion redboot has to be made FLASH safe and upgradable > in the field. This should take priority over adding new > commands etc. Running RedBoot from RAM solves these problems, doesn't it? BTW, how big is RedBoot for a typical ARM implimentation? (I haven't gotten to the point where I can build it yet.) > What do other people on the list think? I think I'm going to have to run RedBoot from RAM. ;) -- Grant Edwards grante@visi.com