From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Thomas To: Grant Edwards Cc: eCos Disuss , Andrew Lunn Subject: Re: [ECOS] RedBoot porting Date: Tue, 09 Jan 2001 09:09:00 -0000 Message-id: References: <20010109110044.A12235@visi.com> X-SW-Source: 2001-01/msg00122.html On 09-Jan-2001 Grant Edwards wrote: > 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. > This is only a problem if interrupts can occur while you're actually writing/erasing the flash (not a good idea in my mind). Otherwise, what would the flash access functions be doing calling virtual vector stuff? >> 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? > Yes. > 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. ;) > On the ARM, RedBoot is ~64k TEXT + 128k DATA (mostly networking buffers)