From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Skov To: Doug Fraser Cc: "'Jesper Skov'" , Andrew Lunn , Grant Edwards , ecos-discuss@sources.redhat.com, gthomas@cambridge.redhat.com Subject: RE: [ECOS] RedBoot porting Date: Mon, 08 Jan 2001 04:54:00 -0000 Message-id: <14937.47209.383836.370668@thinktwice.zoftcorp.dk> References: X-SW-Source: 2001-01/msg00072.html >>>>> "Doug" == Doug Fraser 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