RE: [ECOS] RedBoot porting

RE: [ECOS] RedBoot porting

[Doug Fraser]

Then RedBoot becomes a chunk of the application at that
point. What I want then, I guess, is two copies of 'RedBoot'.
An immutable copy in FLASH that provides recovery of a dead board
and a runtime copy that contains the callbacks for the OS.
The runtime copy is normally copied to RAM and run there. The
FLASH copy is just used to network boot an image if the rest
of my FLASH is dead (for development). I plan on two application
regions of FLASH to provide failsafe remote updates. The
bootstrap picks the image to load based on CRC sanity. Updates
load and verify one section before erasing the second.

Does the above sound reasonable?

Doug

> -----Original Message-----
> From: Jesper Skov [ mailto:jskov@redhat.com ]
> Sent: Monday, January 08, 2001 6:05 AM
> To: Andrew Lunn
> Cc: Jesper Skov; Grant Edwards; ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] RedBoot porting
> 
<snip>

> This should work already for targets that support it. Adding the
> support to new targets it relatively simple (only really requires PIC
> startup code that initializes the system, copies everything to RAM and
> jumps there). Remember, RedBoot _is_ just an application (as far as I
> know, anyway).
> 
> Jesper
> 

RE: [ECOS] RedBoot porting

[Jesper Skov]

>>>>> "Doug" == Doug Fraser <dfraser@photuris.com> writes:

Doug> Then RedBoot becomes a chunk of the application at that
Doug> point. What I want then, I guess, is two copies of 'RedBoot'.
Doug> An immutable copy in FLASH that provides recovery of a dead
Doug> board and a runtime copy that contains the callbacks for the OS.
Doug> The runtime copy is normally copied to RAM and run there. The
Doug> FLASH copy is just used to network boot an image if the rest of
Doug> my FLASH is dead (for development). I plan on two application
Doug> regions of FLASH to provide failsafe remote updates. The
Doug> bootstrap picks the image to load based on CRC sanity. Updates
Doug> load and verify one section before erasing the second.

Doug> Does the above sound reasonable?

Yes. But the reason for making RedBoot run out of RAM is to avoid any
clashes with the flash programming due to interrupts or exceptions
(which may (in part) be serviced by RedBoot).

And RedBoot does not become a part of the application. There can only
ever be one application (task) in an eCos system.

What you're after is something like:

 FLASH
   boot block:  RedBoot ROMRAM startup
   blocks n-m:  application area 1
   blocks x-y:  application area 2
   last blocks: FIS directory

 RAM
   bottom-whatever: RedBoot code and data space
   whatever-top:    application code and data space


On reset RedBoot will reloc to RAM and execute from there. Now we need
to load the appropriate image. I'd suggest each image to have:

 CRC     - for the image
 version - image version

RedBoot will (after a timeout) select the highest version with a valid
CRC and load it into RAM, then jump to it. RedBoot already has all but
the magic to select which image to use - which is something I think
would be good to add as a standard feature.

OK, after the image has been loaded to RAM, both ReBoot and
application run out of RAM, and you can update the flash without
risking it to fry because there's an unexpected exception or
something.


To get this totally failsafe, I think we'd also need to add an extra
FIS directory, also using CRC+version, so that a power outage during
programming does not invalidate anything.

And for failsafe RedBoot updating, we'd have this:

 FLASH
  RedBoot - bootstrapper
  RedBoot image1
  RedBoot image2
  Application image1
  Application image2

RedBoot bootstrapper just loads the highest versionend (and CRC
checked) RedBoot RAM image, which then does the application loading.


Neat. But I'm sure it's unusable for all sorts of reasons :)

Jesper

Re: [ECOS] RedBoot porting

[Grant Edwards]

On Mon, Jan 08, 2001 at 07:30:22AM -0500, Doug Fraser wrote:

> Then RedBoot becomes a chunk of the application at that
> point. What I want then, I guess, is two copies of 'RedBoot'.
> An immutable copy in FLASH that provides recovery of a dead board
> and a runtime copy that contains the callbacks for the OS.

I don't see any reason why you can't run the "immutable" copy
from RAM also.  You just need your start-up code to decide
which copy of RedBoot to copy/run.

-- 
Grant Edwards
grante@visi.com

[ECOS] redboot porting

[yu weiping]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 1291 bytes --]

I'm trying to port redboot for ixdp425 to my custom board based on ixp425, 
but ixp425 seems halt every time when redboot trying to switch from boot 
address (0x000000000) to the actual flash runtime address. the code is:

	// value to load into pc to jump to real runtime address
	ldr     r0, =1f

	// Setup EXP_CNFG0 value to switch EXP bus out of low memory
	ldr 	r2, =IXP425_EXP_CFG_BASE
	ldr     r1, [r2, #IXP425_EXP_CNFG0]
	bic     r1, r1, #EXP_CNFG0_MEM_MAP
	ldr     r3, =0xFFFF
	ldr     r4, =IXDP425_LED_DATA

	b       icache_boundary
	.p2align 5
icache_boundary:
	// Here is where we switch from boot address (0x000000000) to the
	// actual flash runtime address. We align to cache boundary so we
        // execute from cache during the switchover. Cachelines are 8 
words.
        str     r1, [r2, #IXP425_EXP_CNFG0]    // make the EXP bus switch


I can light LED before the last code, but can't light LED after it.

Plesae give me some advince. Thanks!

yuwp

_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com  


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] RedBoot porting

[Andrew Lunn]

> I hadn't thought about this exactly.  What I've been thinking about is
> the framework withing RedBoot to allow for an update in a single command,
> with backout magic to make it safe.

I assume this makes the assumption that an application is made of one
image? Mine is affectivly multiple images. I have a DSP and two FPGAs
on the board which have code downloaded to them at startup. To do a
field upgrade you may need to upgrade all these images at once. 

My opinion is that redboot is the wrong place to do upgrades
from. Redboot is designed to be dumb. It does not have a kernel, its
not easy to add new functionality based on standard application code
etc. Field upgrades need flexiability. Maybe the image comes from
removable media, maybe it comes over the network, maybe it uses some
other communication method which is what the eCos application
provides. This cannot be done in redboot. The application has to be in
control of software upgrades because thats where we the developers
have the flexibility to implement it how we want it to work for our
specific application, customer requirements and backward compatibility
etc.

At the moment the design of redboot stops the application doing the
upgrade. Since it runs from FLASH and can be invoked at any time as
soon as you start a write to the flash your application could die at
any time. Its actually worse than that, you cannot use the FLASH for
anything, eg local configuration information.

In my opinion redboot has to be made FLASH safe and upgradable in the
field. This should take priority over adding new commands etc.

What do other people on the list think?

        Andrew

Re: [ECOS] RedBoot porting

[Grant Edwards]

On Tue, Jan 09, 2001 at 09:50:31AM +0100, Andrew Lunn wrote:

> > I hadn't thought about this exactly.  What I've been thinking
> > about is the framework withing RedBoot to allow for an update
> > in a single command, with backout magic to make it safe.

> At the moment the design of redboot stops the application doing
> the upgrade. Since it runs from FLASH and can be invoked at any
> time as soon as you start a write to the flash your application
> could die at any time. Its actually worse than that, you cannot
> use the FLASH for anything, eg local configuration information.

That's one of my concerns about running RedBoot from ROM: If I
run RedBoot from ROM, then I can't allow the application to use
any of the virtual vector stuff.  The application needs to be
able to write to flash, and if RedBoot is running from flash
it's not going to be available during a flash burn.

> In my opinion redboot has to be made FLASH safe and upgradable
> in the field. This should take priority over adding new
> commands etc.

Running RedBoot from RAM solves these problems, doesn't it?

BTW, how big is RedBoot for a typical ARM implimentation?  (I
haven't gotten to the point where I can build it yet.)

> What do other people on the list think?

I think I'm going to have to run RedBoot from RAM.  ;)

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot porting

[Andrew Lunn]

> Running RedBoot from RAM solves these problems, doesn't it?

Yes. It just needs to be made to do that. At the moment it cannot do
it on its own. At least the EBSA does not have a ROMRAM start option
in its HAL.
 
        Andrew

Re: [ECOS] RedBoot porting

[Grant Edwards]

On Tue, Jan 09, 2001 at 06:04:41PM +0100, Andrew Lunn wrote:

> > Running RedBoot from RAM solves these problems, doesn't it?
> 
> Yes. It just needs to be made to do that. At the moment it cannot do
> it on its own. At least the EBSA does not have a ROMRAM start option
> in its HAL.

Does RedBoot use the same vectors.S start-up code that eCos
uses?  

I currently tuck some memory configurator code in the first
100H bytes in my ARM eCos apps (the space where the interrupt
vector table and the VSR tables go).  I was planning on doing
something similar with RedBoot: A block of code starting at
address 0 (where the interrupt vectors will later reside) will
reconfigure memory and copy RedBoot into RAM, then jump to it.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot porting

[Gary Thomas]

On 09-Jan-2001 Grant Edwards wrote:
> On Tue, Jan 09, 2001 at 09:50:31AM +0100, Andrew Lunn wrote:
> 
>> > I hadn't thought about this exactly.  What I've been thinking
>> > about is the framework withing RedBoot to allow for an update
>> > in a single command, with backout magic to make it safe.
> 
>> At the moment the design of redboot stops the application doing
>> the upgrade. Since it runs from FLASH and can be invoked at any
>> time as soon as you start a write to the flash your application
>> could die at any time. Its actually worse than that, you cannot
>> use the FLASH for anything, eg local configuration information.
> 
> That's one of my concerns about running RedBoot from ROM: If I
> run RedBoot from ROM, then I can't allow the application to use
> any of the virtual vector stuff.  The application needs to be
> able to write to flash, and if RedBoot is running from flash
> it's not going to be available during a flash burn.
> 

This is only a  problem if interrupts can occur while you're actually
writing/erasing the flash (not a good idea in my mind).  Otherwise,
what would the flash access functions be doing calling virtual vector
stuff?

>> In my opinion redboot has to be made FLASH safe and upgradable
>> in the field. This should take priority over adding new
>> commands etc.
> 
> Running RedBoot from RAM solves these problems, doesn't it?
> 

Yes.

> BTW, how big is RedBoot for a typical ARM implimentation?  (I
> haven't gotten to the point where I can build it yet.)
> 
>> What do other people on the list think?
> 
> I think I'm going to have to run RedBoot from RAM.  ;)
>

On the ARM, RedBoot is ~64k TEXT + 128k DATA (mostly networking buffers)

Re: [ECOS] RedBoot porting

[Grant Edwards]

On Tue, Jan 09, 2001 at 10:09:23AM -0700, Gary Thomas wrote:

> > That's one of my concerns about running RedBoot from ROM: If I
> > run RedBoot from ROM, then I can't allow the application to use
> > any of the virtual vector stuff.  The application needs to be
> > able to write to flash, and if RedBoot is running from flash
> > it's not going to be available during a flash burn.
> 
> This is only a problem if interrupts can occur while you're
> actually writing/erasing the flash (not a good idea in my
> mind).  

I suppose it would be simpler to just shut down the whole thing
for several seconds, but that's not a good option.  It's a
multitasking system: even though one task is busy burning
something into flash, the other tasks (miscellaneous network
stuff, background diagnostics, data transfer, web server) all
need to keep running.

I might have to pause the web server since it's pages are in
flash and I don't want to copy them into RAM.  That's
sub-optimal, but tolerable.  The other tasks have to keep
running.

> Otherwise, what would the flash access functions be doing
> calling virtual vector stuff?

Printing status info on the diagnostic output channel mainly.
My flash burn routine displays diagnostic info as it burns
flash.  Other tasks that are still running also need to display
status output, and I presume the network stack may need to call
virtual vector stuff for debug purposes.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot porting

[Andrew Lunn]

> This is only a  problem if interrupts can occur while you're actually
> writing/erasing the flash (not a good idea in my mind).  Otherwise,
> what would the flash access functions be doing calling virtual vector
> stuff?

Grants comment is spot on. eCos is a multi-tasking system. Do we realy
what to stop all other tasks while doing an erase/write
option. Erase's on the EBSA can take a couple of seconds. In my
application i cannot disable interupts for that long. All sorts of
nasty things happen which can take a long time to recover from.

        Andrew

Re: [ECOS] RedBoot porting

[Lewin A.R.W. Edwards]

> > This is only a  problem if interrupts can occur while you're actually
> > writing/erasing the flash (not a good idea in my mind).  Otherwise,
>
>Grants comment is spot on. eCos is a multi-tasking system. Do we realy
>what to stop all other tasks while doing an erase/write
>option. Erase's on the EBSA can take a couple of seconds. In my
>application i cannot disable interupts for that long. All sorts of
>nasty things happen which can take a long time to recover from.

This is strictly my $0.02 and could be totally irrelevant to everyone 
else's situations, but:

We are talking here about upgrading the bootable OS on the unit. What are 
you going to do after the OS has been upgraded? The RAM layout is almost 
certainly going to be different in the new OS, so you just can't jump into 
the new code willy-nilly, you need to reboot the machine which is going to 
take a finite time with no interrupts serviced anyway (and potentially a 
lot of startup latency, leasing an IP address, establishing routing tables, 
whatever it is your appliance needs to do).

When reprogramming a device's boot ROM, I feel much much safer if all 
interrupts are disabled and I would feel safer still if I could legally 
electrify the power switch and cable so that the user couldn't touch them 
;) But then I am working with consumer electronics, and high availability 
is not a priority; preventing a return-to-factory with erased boot flash IS 
a prority.

I agree with the comment about big flash block sizes, I don't want to waste 
vast amounts of flash space on a tiny bootloader. And I definitely do want 
to be able to upgrade any startup boot code.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] RedBoot porting

[Grant Edwards]

On Tue, Jan 09, 2001 at 01:08:29PM -0500, Lewin A.R.W. Edwards wrote:

> > > This is only a problem if interrupts can occur while you're
> > > actually writing/erasing the flash (not a good idea in my
> > > mind).  Otherwise,
> >
> >Grants comment is spot on. eCos is a multi-tasking system. Do we realy
> >what to stop all other tasks while doing an erase/write
> >option. Erase's on the EBSA can take a couple of seconds. In my
> >application i cannot disable interupts for that long. All sorts of
> >nasty things happen which can take a long time to recover from.
> 
> This is strictly my $0.02 and could be totally irrelevant to
> everyone else's situations, but:
> 
> We are talking here about upgrading the bootable OS on the
> unit.

Ah. That's not what I was talking about.  I was talking about
the general case of burning flash.  My board has a single 4MB
(later to be 8MB) flash rom that contains a bunch of stuff in
addition to RedBoot: application image(s), IP configuraiton,
Ethernet MAC configuration, board model/revision info,
application configuration info, web pages (possibly in a
filesystem), Java applets, etc.

> When reprogramming a device's boot ROM, I feel much much safer
> if all interrupts are disabled and I would feel safer still if
> I could legally electrify the power switch and cable so that
> the user couldn't touch them ;) But then I am working with
> consumer electronics, and high availability is not a priority;
> preventing a return-to-factory with erased boot flash IS a
> prority.

Sure, it would be ideal if I could disable interrupts and
insure uninterruptible power while burning flash.  I can't.

FWIW, we don't plan on allowing the user to upgrade the
bootloader (RedBoot) in the field.  However, if I'm going to
take advantage of the virtual vector stuff, RedBoot needs to
remain usable while all that other stuff that resides in flash
is being burned by a running eCos application.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot porting

[Andrew Lunn]

> This is strictly my $0.02 and could be totally irrelevant to everyone 
> else's situations, but:

Thats one of the things with a RTOS and its boot loader. Everyone has
a different situation and it has to be able to handle it. My 0.02CHF
says that Redboot is not yet flexiable enough when FLASH is used by
the application.

        Andrew

Re: [ECOS] RedBoot porting

[Grant Edwards]

On Tue, Jan 09, 2001 at 07:39:03PM +0100, Andrew Lunn wrote:

> > This is strictly my $0.02 and could be totally irrelevant to everyone 
> > else's situations, but:
> 
> Thats one of the things with a RTOS and its boot loader. Everyone has
> a different situation and it has to be able to handle it. My 0.02CHF
> says that Redboot is not yet flexiable enough when FLASH is used by
> the application.

As a boot loader it's fine.  The problem occurs when you try to
use it as a "BIOS" service provider for application code. Since
my application needs to burn flash with interrupts enabled, I
have to be extremely careful about how my application accesses
flash.  That probably means I either run RedBoot in RAM, or
don't use virtual vectors.  No matter how sophistacted you make
RedBoot, there aren't really any other ways around that problem.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] RedBoot porting

[Doug Fraser]

Jesper,

Thanks, see my comments in-line below.

Doug

> -----Original Message-----
> From: Jesper Skov [ mailto:jskov@redhat.com ]
> Sent: Monday, January 08, 2001 7:54 AM
> To: Doug Fraser
> Cc: 'Jesper Skov'; Andrew Lunn; Grant Edwards;
> ecos-discuss@sources.redhat.com; gthomas@cambridge.redhat.com
> Subject: RE: [ECOS] RedBoot porting
> 
<snip>

> What you're after is something like:
> 
>  FLASH
>    boot block:  RedBoot ROMRAM startup
>    blocks n-m:  application area 1
>    blocks x-y:  application area 2
>    last blocks: FIS directory
> 
>  RAM
>    bottom-whatever: RedBoot code and data space
>    whatever-top:    application code and data space
> 
> 
> On reset RedBoot will reloc to RAM and execute from there. Now we need
> to load the appropriate image. I'd suggest each image to have:
> 
>  CRC     - for the image
>  version - image version
> 
> RedBoot will (after a timeout) select the highest version with a valid
> CRC and load it into RAM, then jump to it. RedBoot already has all but
> the magic to select which image to use - which is something I think
> would be good to add as a standard feature.

I have done something like this before. I will give a quick
overview. Because FLASH is inherently block oriented, you
will find images on block boundries. Starting at that boundary,
put enough info to quickly locate and verify the image.
For example (all fields are long words):

'@@@@'                at offset zero, easy to see in memory dumps.
CRC32                 offset one, covers all remaining fields and image.
length of image       offset two
load address          offset three
start address         offset four
option word           offset five

The option word only ever had one use. Was the image compressed (RFC1951)
or was it uncompressed? You could add version information. I never
considered
that, and it could be autotragic. The updater could read the current
release and add one to it. A 32 bit version would give more update versions
than the FLASH would survive.

> 
> OK, after the image has been loaded to RAM, both ReBoot and
> application run out of RAM, and you can update the flash without
> risking it to fry because there's an unexpected exception or
> something.

Correct. That is what I am looking for.


> To get this totally failsafe, I think we'd also need to add an extra
> FIS directory, also using CRC+version, so that a power outage during
> programming does not invalidate anything.

I am not sure. Can this be recovered by the application?
It probably is implementation dependent.

> 
> And for failsafe RedBoot updating, we'd have this:
> 
>  FLASH
>   RedBoot - bootstrapper
>   RedBoot image1
>   RedBoot image2
>   Application image1
>   Application image2
> 
> RedBoot bootstrapper just loads the highest versionend (and CRC
> checked) RedBoot RAM image, which then does the application loading.

And this is what I am looking for. The only problem being that the
RedBoot image is so small and my FLASH blocks so big. So I would
recommend carrying RedBoot with the application as follows.

FLASH
 RedBoot - bootstrapper
 RedBoot + Application image 1
 RedBoot + Application image 2

I that case, the bootstrap would choose and load RedBoot, which
would then choose and load its companion OS. Optionally, the block
header could contain two sub headers that located and loaded the
contained images. In that way, the FIS could be co-located if desired.
One of the header values could be a count of subheaders:

@@@@
CRC32
length
version
subheader cnt
length <- start of first subheader
load address
start address
control word

 .
 .
 .

length <- start of second subheader
ladder
saddr
ctrl

 .
 .
 .

length <- start of Nth subheader
laddr
saddr
ctrl

 .
 .

end....


> 
> 
> Neat. But I'm sure it's unusable for all sorts of reasons :)

Maybe, but not unreasonable to think about...

> 
> Jesper
> 

[ECOS] RedBoot porting

[Grant Edwards]

I've decided to try to get RedBoot running on our custom
platform to see if it would make a suitable basis for a boot
loader.  After reading through the RedBoot porting docs, I'm a
bit confused.

Is the virtual vector table used to make calls in both
directions (user-app calling ROM and ROM calling user-app)?

Once an eCos app is running, are there one or two virtual
vector tables?

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.]

There are several statements in hal-calling-if.html from which
I infer that eCos is headed towards dependence on RedBoot (or a
similar ROM monitor) for various services and that in the
future eCos apps will not be stand-alone as they are now:

  "The use of this service is controlled by the option
   CYGSEM_HAL_VIRTUAL_VECTOR_DIAG which is disabled per default
   on most older platforms (thus preserving backwards
   compatibility with older stubs). On newer ports, this option
   should always be set."

  "Note: On old ports the hardwired HAL_DIAG_INIT,
   HAL_DIAG_WRITE_CHAR and HAL_DIAG_READ_CHAR implementations
   will also contain code to O-packetize the output for GDB.
   This should not be adopted for new ports! On new ports the
   ROM monitor is guaranteed to provide the necessary mangling
   via the vector table."

I don't know that I can guarantee that a ROM monitor will be
available for use by my eCos applications. If eCos must be
guaranteed a ROM monitor, this could be a serious problem for
me.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot porting

[Jonathan Larmour]

Grant Edwards wrote:
> 
> I've decided to try to get RedBoot running on our custom
> platform to see if it would make a suitable basis for a boot
> loader.  After reading through the RedBoot porting docs, I'm a
> bit confused.
> 
> Is the virtual vector table used to make calls in both
> directions (user-app calling ROM and ROM calling user-app)?

It can be. Most uses are for the app calling into ROM. But the point is
that it also allows a way for the app to override the virtual vector table
entry to make it point into itself, if need be. e.g. to override the choice
of diagnostic port. If the app changes the diagnostic port, the ROM monitor
should also then use it, if the monitor comes into play again.
 
> Once an eCos app is running, are there one or two virtual
> vector tables?

One.

> 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.]

No HAL _has_ to use virtual vectors. But then you won't be able to use
things like ethernet debugging, ctrl-c support, etc. unless you want to
support them yourself the way they used to happen.

But what you could easily do is make your app override all the virtual
vectors it cares about itself if need be.
 
> There are several statements in hal-calling-if.html from which
> I infer that eCos is headed towards dependence on RedBoot (or a
> similar ROM monitor) for various services and that in the
> future eCos apps will not be stand-alone as they are now:
> 
>   "The use of this service is controlled by the option
>    CYGSEM_HAL_VIRTUAL_VECTOR_DIAG which is disabled per default
>    on most older platforms (thus preserving backwards
>    compatibility with older stubs). On newer ports, this option
>    should always be set."
> 
>   "Note: On old ports the hardwired HAL_DIAG_INIT,
>    HAL_DIAG_WRITE_CHAR and HAL_DIAG_READ_CHAR implementations
>    will also contain code to O-packetize the output for GDB.
>    This should not be adopted for new ports! On new ports the
>    ROM monitor is guaranteed to provide the necessary mangling
>    via the vector table."
> 
> I don't know that I can guarantee that a ROM monitor will be
> available for use by my eCos applications. If eCos must be
> guaranteed a ROM monitor, this could be a serious problem for
> me.

Virtual vector support is included in GDB stub ROMs in eCos too - it's not
specific to Redboot. And virtual vectors only really apply to debugging
activities - ctrl-c, source level debugging, breakpoints, diagnostic
output, etc.

It should also not stop you blowing your app into ROM if that's what you'd
prefer. But I'm not entirely sure about what you actually _want_ to go into
ROM.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] RedBoot porting

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> I've decided to try to get RedBoot running on our custom
Grant> platform to see if it would make a suitable basis for a boot
Grant> loader.  After reading through the RedBoot porting docs, I'm a
Grant> bit confused.

Jifl already addressed your questions, I think, but I just want to add
something.

Grant> There are several statements in hal-calling-if.html from which
Grant> I infer that eCos is headed towards dependence on RedBoot (or a
Grant> similar ROM monitor) for various services and that in the
Grant> future eCos apps will not be stand-alone as they are now:

I'll be rewriting that part of the docs. We've just had a good and
enlightening discussion on this very subject. 

In short, the present implementation is too rigid - it requires either
the ROM monitor or the RAM application to provide all of the services
in the virtual vector table.

That's silly for a lot of reasons - and I'll be making some changes
shortly to address that, so the RAM application can easily provide a
subset of the services, for instance the IO routines, while still
relying on other services provided by the ROM monitor such as reset.

The virtual vector table is a method to detach caller from service so
that these can live in different address ranges (e.g., caller is in
RAM, service is implemented in ROM). This is required for
RedBoot. However, virtual vectors do not require RedBoot.

Basically, we want the code to consistently use virtual vectors (even
if both caller and service is in the same address range) so we always
use the same code / mechanism - and thereby ensure it is always
properly tested (i.e., the rare stubs/RedBoot builds do not use
special mechanism that can easily get broken and remain broken for a
long time without anyone finding out).

Um, it's basically a story about our heroes Mechanism and Policy which
I managed to muddle into one big ol' nightmare. I'm on a quest to turn
it into a nice fairy tale with a happy ending and all that. I'll be
sure to post something on the list as I make progress.

Thanks,
Jesper

Re: [ECOS] RedBoot porting

[Andrew Lunn]

> 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. A typical sinario is that i erase a block
and start writing bytes to it. The app then decides to jump into
Redboot, typical for ^C support reasons. The FLASH is currently in
write mode so the first instruction read in ROM returns the status
code of the current write, which the CPU tries to execute and its RIP,
you dead.

What would be nice is being able to tell the app, don't jump into ROM
for a while, i need exclusive access to the FLASH. 

        Andrew

Re: [ECOS] RedBoot porting

[Jesper Skov]

>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

>> 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.]

Andrew> Even if you could try to upgrade the boot loader in the field,
Andrew> its hard to do. In my case the boot loader is in FLASH. My
Andrew> code has a TFTP server running that allows me to download new
Andrew> images into the FLASH. The problem with redboot is that you
Andrew> have no control when it tries to jump into the ROM. A typical
Andrew> sinario is that i erase a block and start writing bytes to
Andrew> it. The app then decides to jump into Redboot, typical for ^C
Andrew> support reasons. The FLASH is currently in write mode so the
Andrew> first instruction read in ROM returns the status code of the
Andrew> current write, which the CPU tries to execute and its RIP, you
Andrew> dead.

Andrew> What would be nice is being able to tell the app, don't jump
Andrew> into ROM for a while, i need exclusive access to the FLASH.

Interesting - presumably you cannot disable interrupts for the
duration of the flash update process?

One way this could be accomplished is by providing a function (in RAM
application) that saves the virtual vector table, fills it with
pointers to NOP functions (in RAM) which count usage.  

Then update the flash [you could still be hit by interrupts that do
rogue access to flash and spoil the programming btw, but nothing short
of disabling interrupts is going to fix bugs of that nature]

Afterward call another function which restores the virtual vector
content. Possibly use usage counts to make some follow up actions (for
instance, instead of NOP functions for the HAL IO routines, one could
put in a function that does limited buffering, and output the buffered
data when the vectors are restored).


Jesper

Re: [ECOS] RedBoot porting

[Andrew Lunn]

> Andrew> What would be nice is being able to tell the app, don't jump
> Andrew> into ROM for a while, i need exclusive access to the FLASH.
> 
> Interesting - presumably you cannot disable interrupts for the
> duration of the flash update process?

Nope, it can take a number of seconds to write the image. 

> One way this could be accomplished is by providing a function (in RAM
> application) that saves the virtual vector table, fills it with
> pointers to NOP functions (in RAM) which count usage.  

Another simpler option is to make the ROM copy itself into RAM and run
from there. Some of the HALs already support this for apps, but has it
been tested for redboot? It also means you can then overwrite the
redboot image in FLASH while its running the copy in RAM. With the app
and the boot loader becoming closer tied together its becoming more
important to be able to upgrade the bootloader in the field as well as
the application.

        Andrew

Re: [ECOS] RedBoot porting

[Jesper Skov]

>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

>> One way this could be accomplished is by providing a function (in
>> RAM application) that saves the virtual vector table, fills it with
>> pointers to NOP functions (in RAM) which count usage.

Andrew> Another simpler option is to make the ROM copy itself into RAM
Andrew> and run from there. Some of the HALs already support this for
Andrew> apps, but has it been tested for redboot? It also means you
Andrew> can then overwrite the redboot image in FLASH while its
Andrew> running the copy in RAM. With the app and the boot loader
Andrew> becoming closer tied together its becoming more important to
Andrew> be able to upgrade the bootloader in the field as well as the
Andrew> application.

This should work already for targets that support it. Adding the
support to new targets it relatively simple (only really requires PIC
startup code that initializes the system, copies everything to RAM and
jumps there). Remember, RedBoot _is_ just an application (as far as I
know, anyway).

Jesper

Re: [ECOS] RedBoot porting

[Grant Edwards]

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.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot porting

[Lewin A.R.W. Edwards]

>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.

Is it even possible? The flash chips I use will only return status while in 
program mode, you can't exec code out of them while programming them.

The way I handle flash updates in the current program is to (on boot) check 
removable media for an upgrade file. If one is found, I load the whole 
caboodle into RAM, verify its checksum, disable all interrupts and other 
things, and then jump right into the loaded program (which is a standalone 
OS of its own). I erase and program the flash as quickly as possible then 
reset the machine. The beauty of this system is that it can be used to 
autoboot other things, e.g. it can be used for very quick tests of new OSs 
and third-party add-on modules on the real hardware platform.

It's akin to booting a PC off floppy :)

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] RedBoot porting

[Grant Edwards]

On Mon, Jan 08, 2001 at 10:40:06AM -0500, Lewin A.R.W. Edwards wrote:

> >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.
> 
> Is it even possible? The flash chips I use will only return
> status while in program mode, you can't exec code out of them
> while programming them.

You're not actually fetching instructions from flash while the
burn takes place. The usual method is to copy a small chunk of
code (the routine that does the actual "burn" command and waits
while flash is busy) into RAM and call it from flash.  The
catch is that you have to disable all interrrupts (or anything
that might access flash) until the burn is finished.  If you
can have interrupts disabled for a second or two, it's not a
problem.

> The way I handle flash updates in the current program is to (on
> boot) check removable media for an upgrade file. If one is
> found, I load the whole caboodle into RAM, verify its checksum,
> disable all interrupts and other things, and then jump right
> into the loaded program (which is a standalone OS of its own).
> I erase and program the flash as quickly as possible then reset
> the machine.

That's pretty similar to the way I upgrade flash (in the lab):
shove a stand-alone application into RAM that burns a new
bootloader into flash.  How you get that application into RAM
and running is the trick: if you've already got a working
bootloader, it can read it from removable media, over the
network, through a serial port, etc.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot porting

[Gary Thomas]

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.

Re: [ECOS] RedBoot porting

[Grant Edwards]

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

Re: [ECOS] RedBoot porting

[Andrew Lunn]

> 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 is ok for development, but not ok for in field upgrades by
customers/installation people. Do you want me to teach my customers
how to run a RAM copy of redboot so that they can then upgrade the ROM
copy? I think not. Customers need something simple like. Boot the
system as normal, TFTP put this image and press the reset button. 

        Andrew

Re: [ECOS] RedBoot porting

[Gary Thomas]

On 08-Jan-2001 Andrew Lunn wrote:
>> 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 is ok for development, but not ok for in field upgrades by
> customers/installation people. Do you want me to teach my customers
> how to run a RAM copy of redboot so that they can then upgrade the ROM
> copy? I think not. Customers need something simple like. Boot the
> system as normal, TFTP put this image and press the reset button. 

I agree that it needs to be simple.  However, there's no reason that
simple [from user's perspective] has to work in any particular fashion.

I could imagine [and I have!] a special RedBoot command which does
all of the steps automatically, including rebooting from the RAM based
version, updating the FLASH and then rebooting the entire system.  This
could be done in a fail-safe fashion such that if any step failed, the
system reverts to totally normal operation [all changes reverted].

Re: [ECOS] RedBoot porting

[Grant Edwards]

I've just started on updating my HAL to be compatible with
RedBoot. I'm modelling my code on the ebsa285 and edb7xxx HALs
(they seem to be fairly similar to each other).

Currently I don't have any GDB stubs in my eCos configuration,
and no code in my hal_diag.c file to generate 'O' packets for
daig output.

I want to add gdb support in my next product -- initially using
gdb stubs in RedBoot with a fallback position of using gdb
stubs built into the eCos app.  The packetizing code in
hal_diag_write_char is still needed if I want to use gdb stubs
built in to the eCos app, right?

I'm still a little fuzzy on how/when the gdb stubs gain
control.  If I build an eCos app with gdb stubs, do the stubs
gain control initially when the app is started, or are they
dormant until a "control-C" is received on the debugging
channel?

I'd like hal_diag_write_char() to not use the packetizing code
unless there's actually a gdb session active. Is there some way
the diag output routine can know?

How do the output routines in RedBoot decide whether to
packetize output?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] RedBoot porting

[Gary Thomas]

On 08-Jan-2001 Grant Edwards wrote:
> 
> I've just started on updating my HAL to be compatible with
> RedBoot. I'm modelling my code on the ebsa285 and edb7xxx HALs
> (they seem to be fairly similar to each other).
> 
> Currently I don't have any GDB stubs in my eCos configuration,
> and no code in my hal_diag.c file to generate 'O' packets for
> daig output.
> 
> I want to add gdb support in my next product -- initially using
> gdb stubs in RedBoot with a fallback position of using gdb
> stubs built into the eCos app.  The packetizing code in
> hal_diag_write_char is still needed if I want to use gdb stubs
> built in to the eCos app, right?

Not if you're using the virtual vector stuff.  It'll come from 
the generic HAL component.  The fact that these routines still
have that support in them is old - i.e. out of date.

> 
> I'm still a little fuzzy on how/when the gdb stubs gain
> control.  If I build an eCos app with gdb stubs, do the stubs
> gain control initially when the app is started, or are they
> dormant until a "control-C" is received on the debugging
> channel?

User programs with stubs included will simply run until they
receive a breakpoint or ^C.  The default stubs, including RedBoot,
simulate this by forcing a breakpoint when they start up.   RedBoot
does this when it sees GDB protocol stuff coming down the serial line.

> 
> I'd like hal_diag_write_char() to not use the packetizing code
> unless there's actually a gdb session active. Is there some way
> the diag output routine can know?

Use the virtual vectors, Luke.

> 
> How do the output routines in RedBoot decide whether to
> packetize output?

It all happens, almost by magic, depending on what's been registered.

Re: [ECOS] RedBoot porting

[Grant Edwards]

> > I'd like hal_diag_write_char() to not use the packetizing code
> > unless there's actually a gdb session active. Is there some way
> > the diag output routine can know?
> 
> Use the virtual vectors, Luke.

I will, but I have to have a contingency plan for what happens
once products have been in the field for a while and the
RedBoot that's in ROM is no longer compatible (or a bug is
found) and can't be used with newer eCos applications.

> > How do the output routines in RedBoot decide whether to
> > packetize output?
> 
> It all happens, almost by magic, depending on what's been
> registered.

And I have to be able to emulate that magic in my HAL output
routines when I get to the point where I can't use RedBoot due
to a bug or compatibility issue.

-- 
Grant Edwards
grante@visi.com