Re: [ECOS] RedBoot porting

[Grant Edwards <grante@visi.com>]

On Mon, Jan 08, 2001 at 08:42:05AM -0700, Gary Thomas wrote:

> >> Even if you could try to upgrade the boot loader in the field,
> >> its hard to do. In my case the boot loader is in FLASH. My code
> >> has a TFTP server running that allows me to download new images
> >> into the FLASH. The problem with redboot is that you have no
> >> control when it tries to jump into the ROM.
> > [...]
> > 
> > That's the main reason I'm thinking about running RedBoot from
> > RAM (copy from ROM on startup).  Updating flash while you're
> > running from it is a royal pain.
> 
> Have you looked at the flash drivers we already have?  They have 
> techniques (running just the flash access functions in RAM) for this.

I didn't look at it in any detail, but I did notice it.  IIRC,
the flash routines are compiled with different options so that
position independant code is generated by the compiler.

> The only complication is when trying to [re]program the flash that
> is actually executing, i.e. the RedBoot code itself.  For that, we
> use a version of RedBoot designed to run from RAM.

That sounds like a pretty reasonable approach.  I don't think
we're going to give customers the option of updating RedBoot
itself, so it's OK if that is a bit more complicated.

> This approach, although certainly not the only one, allows us to
> use pure ROM based code the majority of the time.  This lets the
> RedBoot code use less RAM and also provides the possibility of
> exporting services to all applications in a fairly safe manner.

-- 
Grant Edwards
grante@visi.com