This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RedBoot porting



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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]