From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Thomas To: Grant Edwards Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] RedBoot porting Date: Mon, 08 Jan 2001 07:42:00 -0000 Message-id: References: <20010108093453.D10230@visi.com> X-SW-Source: 2001-01/msg00082.html On 08-Jan-2001 Grant Edwards wrote: > On Mon, Jan 08, 2001 at 09:29:28AM +0100, Andrew Lunn wrote: > >> > If I do not want RedBoot to provide any services to user >> > applications, do I still need to implement virtual vector >> > support in my HAL? [Having application code depend on services >> > available in the boot loader is way too high-risk, since there >> > isn't going to be any way to upgrade the boot loader in the >> > field.] >> >> 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. 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. 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.