From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: Gary Thomas Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] RedBoot porting Date: Mon, 08 Jan 2001 07:57:00 -0000 Message-id: <20010108100101.A10415@visi.com> References: <20010108093453.D10230@visi.com> X-SW-Source: 2001-01/msg00083.html 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