Re: [ECOS] RedBoot porting

[Grant Edwards <grante@visi.com>]

On Tue, Jan 09, 2001 at 01:08:29PM -0500, Lewin A.R.W. Edwards wrote:

> > > 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,
> >
> >Grants comment is spot on. eCos is a multi-tasking system. Do we realy
> >what to stop all other tasks while doing an erase/write
> >option. Erase's on the EBSA can take a couple of seconds. In my
> >application i cannot disable interupts for that long. All sorts of
> >nasty things happen which can take a long time to recover from.
> 
> This is strictly my $0.02 and could be totally irrelevant to
> everyone else's situations, but:
> 
> We are talking here about upgrading the bootable OS on the
> unit.

Ah. That's not what I was talking about.  I was talking about
the general case of burning flash.  My board has a single 4MB
(later to be 8MB) flash rom that contains a bunch of stuff in
addition to RedBoot: application image(s), IP configuraiton,
Ethernet MAC configuration, board model/revision info,
application configuration info, web pages (possibly in a
filesystem), Java applets, etc.

> When reprogramming a device's boot ROM, I feel much much safer
> if all interrupts are disabled and I would feel safer still if
> I could legally electrify the power switch and cable so that
> the user couldn't touch them ;) But then I am working with
> consumer electronics, and high availability is not a priority;
> preventing a return-to-factory with erased boot flash IS a
> prority.

Sure, it would be ideal if I could disable interrupts and
insure uninterruptible power while burning flash.  I can't.

FWIW, we don't plan on allowing the user to upgrade the
bootloader (RedBoot) in the field.  However, if I'm going to
take advantage of the virtual vector stuff, RedBoot needs to
remain usable while all that other stuff that resides in flash
is being burned by a running eCos application.

-- 
Grant Edwards
grante@visi.com