This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot porting
- To: Grant Edwards <grante at visi dot com>
- Subject: Re: [ECOS] RedBoot porting
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Mon, 08 Jan 2001 08:42:05 -0700 (MST)
- Cc: ecos-discuss at sources dot redhat dot com
- Organization: Red Hat, Inc.
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.