[ECOS] RedBoot porting

[Gary Thomas]

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)