This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot porting
> > 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. What are
you going to do after the OS has been upgraded? The RAM layout is almost
certainly going to be different in the new OS, so you just can't jump into
the new code willy-nilly, you need to reboot the machine which is going to
take a finite time with no interrupts serviced anyway (and potentially a
lot of startup latency, leasing an IP address, establishing routing tables,
whatever it is your appliance needs to do).
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.
I agree with the comment about big flash block sizes, I don't want to waste
vast amounts of flash space on a tiny bootloader. And I definitely do want
to be able to upgrade any startup boot code.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/
"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."