RE: [ECOS] RedBoot porting

[Jesper Skov <jskov@redhat.com>]

>>>>> "Doug" == Doug Fraser <dfraser@photuris.com> writes:

Doug> Then RedBoot becomes a chunk of the application at that
Doug> point. What I want then, I guess, is two copies of 'RedBoot'.
Doug> An immutable copy in FLASH that provides recovery of a dead
Doug> board and a runtime copy that contains the callbacks for the OS.
Doug> The runtime copy is normally copied to RAM and run there. The
Doug> FLASH copy is just used to network boot an image if the rest of
Doug> my FLASH is dead (for development). I plan on two application
Doug> regions of FLASH to provide failsafe remote updates. The
Doug> bootstrap picks the image to load based on CRC sanity. Updates
Doug> load and verify one section before erasing the second.

Doug> Does the above sound reasonable?

Yes. But the reason for making RedBoot run out of RAM is to avoid any
clashes with the flash programming due to interrupts or exceptions
(which may (in part) be serviced by RedBoot).

And RedBoot does not become a part of the application. There can only
ever be one application (task) in an eCos system.

What you're after is something like:

 FLASH
   boot block:  RedBoot ROMRAM startup
   blocks n-m:  application area 1
   blocks x-y:  application area 2
   last blocks: FIS directory

 RAM
   bottom-whatever: RedBoot code and data space
   whatever-top:    application code and data space


On reset RedBoot will reloc to RAM and execute from there. Now we need
to load the appropriate image. I'd suggest each image to have:

 CRC     - for the image
 version - image version

RedBoot will (after a timeout) select the highest version with a valid
CRC and load it into RAM, then jump to it. RedBoot already has all but
the magic to select which image to use - which is something I think
would be good to add as a standard feature.

OK, after the image has been loaded to RAM, both ReBoot and
application run out of RAM, and you can update the flash without
risking it to fry because there's an unexpected exception or
something.


To get this totally failsafe, I think we'd also need to add an extra
FIS directory, also using CRC+version, so that a power outage during
programming does not invalidate anything.

And for failsafe RedBoot updating, we'd have this:

 FLASH
  RedBoot - bootstrapper
  RedBoot image1
  RedBoot image2
  Application image1
  Application image2

RedBoot bootstrapper just loads the highest versionend (and CRC
checked) RedBoot RAM image, which then does the application loading.


Neat. But I'm sure it's unusable for all sorts of reasons :)

Jesper