RE: [ECOS] RedBoot porting

[Doug Fraser <dfraser@photuris.com>]

Jesper,

Thanks, see my comments in-line below.

Doug

> -----Original Message-----
> From: Jesper Skov [ mailto:jskov@redhat.com ]
> Sent: Monday, January 08, 2001 7:54 AM
> To: Doug Fraser
> Cc: 'Jesper Skov'; Andrew Lunn; Grant Edwards;
> ecos-discuss@sources.redhat.com; gthomas@cambridge.redhat.com
> Subject: RE: [ECOS] RedBoot porting
> 
<snip>

> 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.

I have done something like this before. I will give a quick
overview. Because FLASH is inherently block oriented, you
will find images on block boundries. Starting at that boundary,
put enough info to quickly locate and verify the image.
For example (all fields are long words):

'@@@@'                at offset zero, easy to see in memory dumps.
CRC32                 offset one, covers all remaining fields and image.
length of image       offset two
load address          offset three
start address         offset four
option word           offset five

The option word only ever had one use. Was the image compressed (RFC1951)
or was it uncompressed? You could add version information. I never
considered
that, and it could be autotragic. The updater could read the current
release and add one to it. A 32 bit version would give more update versions
than the FLASH would survive.

> 
> 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.

Correct. That is what I am looking for.


> 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.

I am not sure. Can this be recovered by the application?
It probably is implementation dependent.

> 
> 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.

And this is what I am looking for. The only problem being that the
RedBoot image is so small and my FLASH blocks so big. So I would
recommend carrying RedBoot with the application as follows.

FLASH
 RedBoot - bootstrapper
 RedBoot + Application image 1
 RedBoot + Application image 2

I that case, the bootstrap would choose and load RedBoot, which
would then choose and load its companion OS. Optionally, the block
header could contain two sub headers that located and loaded the
contained images. In that way, the FIS could be co-located if desired.
One of the header values could be a count of subheaders:

@@@@
CRC32
length
version
subheader cnt
length <- start of first subheader
load address
start address
control word

 .
 .
 .

length <- start of second subheader
ladder
saddr
ctrl

 .
 .
 .

length <- start of Nth subheader
laddr
saddr
ctrl

 .
 .

end....


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

Maybe, but not unreasonable to think about...

> 
> Jesper
>