This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: RedBoot porting
- To: Doug Fraser <dfraser at photuris dot com>
- Subject: RE: [ECOS] RedBoot porting
- From: Jesper Skov <jskov at redhat dot com>
- Date: Mon, 8 Jan 2001 13:54:01 +0100
- Cc: "'Jesper Skov'" <jskov at redhat dot com>,Andrew Lunn <andrew dot lunn at ascom dot ch>, Grant Edwards <grante at visi dot com>,ecos-discuss at sources dot redhat dot com, gthomas at cambridge dot redhat dot com
- References: <E2D27064CD59574F88D05AEF5728396D01E5E2@PH01SRV02.photuris.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