This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot porting
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