RE: [ECOS] interrupt/virtual vectors confusion

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

Ok, I've got it working the bad & naughty way; in Redboot's interrupt
vector (0x18) I place the address of my own app's vector interrupt
entry. 

Thus when first an interrupt occurs the hardware jumps to 0x18 which now
contains a jump to a RAM location which (I have ensured) is the IRQ
entry in my app's vector table. From there it proceeds as expected.

It works for now but if Redboot's size changes the app is going to be
loaded to a slightly different location and it'd broken again. I had
hoped that Redboot itself would have considered this issue and provided
a mode (at least as an option) where it would create a jump table in RAM
that any app could then modify. I can and probably will do this myself,
but I will end up with a modified Redboot which I then need to maintain
in addition to my own app.


-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: 16 August 2005 16:21
To: Matt Sartori
Cc: eCos Disuss
Subject: Re: [ECOS] interrupt/virtual vectors confusion

> >You probably need to change this so that it runs in user flash boot
> >mode. If you don't have RAM at 0x0 there is no way to change the
> >vectors. I expect if you run the eCos tests which test interrupts
they
> >will fail.
> >
> 
> And booting in RAM mode Redboot would still work because the first
thing
> it does is copy itself into RAM? My current Redboot setup is running
in
> ROM mode (CYG_HAL_STARTUP == ROM). Presumably that would need changing
> to ROMRAM then?

It should still be able to run in ROM. It just need to take care when
the ROM is remapped out from 0x0 that it is already running from the
mapping at the higher address space. You will find the existing ARM
platforms do this. What is actually quite common is that the reset
vector jumps straight into the high address mapping. 

        Andrew

--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

Fantastic! I didn't know you could do that in software since my board
has switches on to change modes. A quick focused search through the
reference manual did indeed reveal the ability to switch modes on the
fly and even mentions that this is useful for managing interrupt
vectors. Finally the answer I was looking for :)
Thanks Andrew.

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: 17 August 2005 10:09
To: Matt Sartori
Cc: eCos Disuss
Subject: Re: [ECOS] interrupt/virtual vectors confusion

On Wed, Aug 17, 2005 at 08:40:25AM +0100, Matt Sartori wrote:
> I'm not sure I understand how this would work. Switching my board into
> RAM boot mode means that it maps internal RAM (0x20000000) to
> 0x00000000. On reset it always start execution from 0x0 but will in
this
> case find nothing there to execute. On the other hand if booting in
the
> boards normal mode (USER mode with flash mapped to 0x0) it will boot
> fine but when your app wants to change the vector at 0x18 it, as you
> pointed out, fail to do so.
> Jumping into high address mapping (by that I understand that when an
> exception/interrupt occurs all the instructions in the vector at 0x0
> jump to another vector in RAM) is what I want to do but still haven't
> quite worked out where to do - presumably by changing the vector setup
> of Redboot.

Can you change the mode on the fly? Normally you start with ROM at
address 0x0 and them move it out of the way and put RAM there. See if
this is possible with you hardware.

        Andrew

--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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

Re: [ECOS] interrupt/virtual vectors confusion

[Andrew Lunn]

On Wed, Aug 17, 2005 at 08:40:25AM +0100, Matt Sartori wrote:
> I'm not sure I understand how this would work. Switching my board into
> RAM boot mode means that it maps internal RAM (0x20000000) to
> 0x00000000. On reset it always start execution from 0x0 but will in this
> case find nothing there to execute. On the other hand if booting in the
> boards normal mode (USER mode with flash mapped to 0x0) it will boot
> fine but when your app wants to change the vector at 0x18 it, as you
> pointed out, fail to do so.
> Jumping into high address mapping (by that I understand that when an
> exception/interrupt occurs all the instructions in the vector at 0x0
> jump to another vector in RAM) is what I want to do but still haven't
> quite worked out where to do - presumably by changing the vector setup
> of Redboot.

Can you change the mode on the fly? Normally you start with ROM at
address 0x0 and them move it out of the way and put RAM there. See if
this is possible with you hardware.

        Andrew

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

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

I'm not sure I understand how this would work. Switching my board into
RAM boot mode means that it maps internal RAM (0x20000000) to
0x00000000. On reset it always start execution from 0x0 but will in this
case find nothing there to execute. On the other hand if booting in the
boards normal mode (USER mode with flash mapped to 0x0) it will boot
fine but when your app wants to change the vector at 0x18 it, as you
pointed out, fail to do so.
Jumping into high address mapping (by that I understand that when an
exception/interrupt occurs all the instructions in the vector at 0x0
jump to another vector in RAM) is what I want to do but still haven't
quite worked out where to do - presumably by changing the vector setup
of Redboot.

m@

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: 16 August 2005 16:21
To: Matt Sartori
Cc: eCos Disuss
Subject: Re: [ECOS] interrupt/virtual vectors confusion

> >You probably need to change this so that it runs in user flash boot
> >mode. If you don't have RAM at 0x0 there is no way to change the
> >vectors. I expect if you run the eCos tests which test interrupts
they
> >will fail.
> >
> 
> And booting in RAM mode Redboot would still work because the first
thing
> it does is copy itself into RAM? My current Redboot setup is running
in
> ROM mode (CYG_HAL_STARTUP == ROM). Presumably that would need changing
> to ROMRAM then?

It should still be able to run in ROM. It just need to take care when
the ROM is remapped out from 0x0 that it is already running from the
mapping at the higher address space. You will find the existing ARM
platforms do this. What is actually quite common is that the reset
vector jumps straight into the high address mapping. 

        Andrew

--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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

Re: [ECOS] interrupt/virtual vectors confusion

[Andrew Lunn]

> >You probably need to change this so that it runs in user flash boot
> >mode. If you don't have RAM at 0x0 there is no way to change the
> >vectors. I expect if you run the eCos tests which test interrupts they
> >will fail.
> >
> 
> And booting in RAM mode Redboot would still work because the first thing
> it does is copy itself into RAM? My current Redboot setup is running in
> ROM mode (CYG_HAL_STARTUP == ROM). Presumably that would need changing
> to ROMRAM then?

It should still be able to run in ROM. It just need to take care when
the ROM is remapped out from 0x0 that it is already running from the
mapping at the higher address space. You will find the existing ARM
platforms do this. What is actually quite common is that the reset
vector jumps straight into the high address mapping. 

        Andrew

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

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

>-----Original Message-----
>From: Andrew Lunn [mailto:andrew@lunn.ch] 
>Sent: 16 August 2005 15:54
>To: Matt Sartori
>Cc: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] interrupt/virtual vectors confusion
>
>On Tue, Aug 16, 2005 at 03:39:57PM +0100, Matt Sartori wrote:
>> >-----Original Message-----
>> >From: Andrew Lunn [mailto:andrew@lunn.ch] 
>> >Sent: 16 August 2005 15:25
>> >To: Matt Sartori
>> >Cc: ecos-discuss@ecos.sourceware.org
>> >Subject: Re: [ECOS] interrupt/virtual vectors confusion
>> >
>> >On Tue, Aug 16, 2005 at 03:06:39PM +0100, Matt Sartori wrote:
>> >> 
>> >> >Is Blinky an eCos RAM program? If so it should of taken over the
>> >> >interrupt vectors from Redboot. Redboot should no longer be
active
>> >> >unless blinky actually calls into Redboot via the virtual
vectors.
>> >> 
>> >> Blinky is just a standalone program I decided to use as a test.
The
>> only
>> >> change I've made to it to make it run is to link it directly into
>> free
>> >> ram so that I can run it after having loaded it from Redboot (with
a
>> >> load -r -m ymodem -b 0x20005b68). 
>> >> The reason I know that Redboot is handling (or at least that
Redboot
>> >> code is being called) the IRQ is that I put while(1){flash an led
>> every
>> >> second} at the top of hal_IRQ_handler and that it gets stuck there
>> when
>> >> I run Blinky.
>> >
>> >Well if you have not taken over the vector it will still be Redboot
>> >that controls it. If blinky needs to handle the vector simply take
it
>> >over. 
>> >
>> >> >The vectors will be in RAM, not ROM. On ARM architectures what
>> >> >normally happens is that at startup ROM is mapped to address 0x0.
>> Once
>> >> >the program is running is remaps the memory so that ROM is moved
to
>> >> >higher addresses and RAM is mapped to address 0x0. The vectors
can
>> >> >then be changed by the application. 
>> >> 
>> >> Hmm. I know that my board maps Flash ROM (0x40000000) to
0x00000000.
>> It
>> >> also puts something in RAM because when I run Redboot I get the 
>> >> 	RAM: 0x20000000-0x20010000, [0x20005b68-0x20010000] available 
>> >> Message. On an interrupt the PC goes to 0x00000018 which is where
>> >> Redboot's vector sits (having been mapped by the board) and that's
>> why
>> >> (I think) the Redboot ends up handling my interrupts. Do you mean
>> that
>> >> Redboot also remaps it's vector to 0x20000000? 
>> >
>> >The RAM could be mapped into two locations in the address space at
the
>> >same time. You need to read the datasheet for you processor to find
>> >out what it actually does. 
>> 
>> A quick look at my datasheet mentions that RAM is mapped both to
>> 0x20000000 and 0x00000000, but only in RAM boot mode. I am currently
>> running in user flash boot mode.
>
>You probably need to change this so that it runs in user flash boot
>mode. If you don't have RAM at 0x0 there is no way to change the
>vectors. I expect if you run the eCos tests which test interrupts they
>will fail.
>

And booting in RAM mode Redboot would still work because the first thing
it does is copy itself into RAM? My current Redboot setup is running in
ROM mode (CYG_HAL_STARTUP == ROM). Presumably that would need changing
to ROMRAM then?


--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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

Re: [ECOS] interrupt/virtual vectors confusion

[Andrew Lunn]

> > A quick look at my datasheet mentions that RAM is mapped both to
> > 0x20000000 and 0x00000000, but only in RAM boot mode. I am currently
> > running in user flash boot mode.
> 
> You probably need to change this so that it runs in user flash boot
> mode. If you don't have RAM at 0x0 there is no way to change the
> vectors. I expect if you run the eCos tests which test interrupts they
> will fail.

Arg! I ment to say RAM boot mode......

        Andrew

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

Re: [ECOS] interrupt/virtual vectors confusion

[Andrew Lunn]

On Tue, Aug 16, 2005 at 03:39:57PM +0100, Matt Sartori wrote:
> >-----Original Message-----
> >From: Andrew Lunn [mailto:andrew@lunn.ch] 
> >Sent: 16 August 2005 15:25
> >To: Matt Sartori
> >Cc: ecos-discuss@ecos.sourceware.org
> >Subject: Re: [ECOS] interrupt/virtual vectors confusion
> >
> >On Tue, Aug 16, 2005 at 03:06:39PM +0100, Matt Sartori wrote:
> >> 
> >> >Is Blinky an eCos RAM program? If so it should of taken over the
> >> >interrupt vectors from Redboot. Redboot should no longer be active
> >> >unless blinky actually calls into Redboot via the virtual vectors.
> >> 
> >> Blinky is just a standalone program I decided to use as a test. The
> only
> >> change I've made to it to make it run is to link it directly into
> free
> >> ram so that I can run it after having loaded it from Redboot (with a
> >> load -r -m ymodem -b 0x20005b68). 
> >> The reason I know that Redboot is handling (or at least that Redboot
> >> code is being called) the IRQ is that I put while(1){flash an led
> every
> >> second} at the top of hal_IRQ_handler and that it gets stuck there
> when
> >> I run Blinky.
> >
> >Well if you have not taken over the vector it will still be Redboot
> >that controls it. If blinky needs to handle the vector simply take it
> >over. 
> >
> >> >The vectors will be in RAM, not ROM. On ARM architectures what
> >> >normally happens is that at startup ROM is mapped to address 0x0.
> Once
> >> >the program is running is remaps the memory so that ROM is moved to
> >> >higher addresses and RAM is mapped to address 0x0. The vectors can
> >> >then be changed by the application. 
> >> 
> >> Hmm. I know that my board maps Flash ROM (0x40000000) to 0x00000000.
> It
> >> also puts something in RAM because when I run Redboot I get the 
> >> 	RAM: 0x20000000-0x20010000, [0x20005b68-0x20010000] available 
> >> Message. On an interrupt the PC goes to 0x00000018 which is where
> >> Redboot's vector sits (having been mapped by the board) and that's
> why
> >> (I think) the Redboot ends up handling my interrupts. Do you mean
> that
> >> Redboot also remaps it's vector to 0x20000000? 
> >
> >The RAM could be mapped into two locations in the address space at the
> >same time. You need to read the datasheet for you processor to find
> >out what it actually does. 
> 
> A quick look at my datasheet mentions that RAM is mapped both to
> 0x20000000 and 0x00000000, but only in RAM boot mode. I am currently
> running in user flash boot mode.

You probably need to change this so that it runs in user flash boot
mode. If you don't have RAM at 0x0 there is no way to change the
vectors. I expect if you run the eCos tests which test interrupts they
will fail.

        Andrew

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

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

>-----Original Message-----
>From: Gary Thomas [mailto:gary@mlbassoc.com] 
>Sent: 16 August 2005 15:36
>To: Matt Sartori
>Cc: Andrew Lunn; eCos Discussion
>Subject: RE: [ECOS] interrupt/virtual vectors confusion
>
>On Tue, 2005-08-16 at 15:27 +0100, Matt Sartori wrote:
>> Eeek! But that would mean that Redboot can only properly work as a
>> bootloader for Redboot "enabled" programs. It was my understanding
(and
>> basis for advocating it as a viable alternative to writing our own
>> custom bootloader) that Redboot is able to run any application and
only
>> re-appear when the board is reset.
>
>It absolutely *can* do what you want, but if your hardware does not 
>have an easy way to redirect the VSR handling (where code jumps to when
>an interrupt or exception happens),

Unfortunately I don't think that is the case for my board.

> then you'll have to add some code
>to your HAL to make this work cooperatively.  If that's the case, then
>your application will still have to somehow indicate to RedBoot what it
>wants to do when the interrupt or exception happens.  We're just
talking
>semantic details here - either you invent some mechanism to handle this
>or you run eCos programs (which will also have to have similar 
>mechanisms via the HAL).
>

Indeed. My initial hope was that there was some way of telling Redboot
of a location in RAM where such a table existed. Eg. Interrupt happens,
PC jumps to 0x00000018 which Redboot has set (eg. through a setting when
built) to point to a fixed location in RAM. If that location is
untouched by my app it will, by default, point to Redboot's own ISR,
otherwise, if my app has modified the table, it will point to my app's
ISR. 


>> -----Original Message-----
>> From: Gary Thomas [mailto:gary@mlbassoc.com] 
>> Sent: 16 August 2005 15:18
>> To: Matt Sartori
>> Cc: Andrew Lunn; eCos Discussion
>> Subject: RE: [ECOS] interrupt/virtual vectors confusion
>> 
>> On Tue, 2005-08-16 at 15:06 +0100, Matt Sartori wrote:
>> > >Is Blinky an eCos RAM program? If so it should of taken over the
>> > >interrupt vectors from Redboot. Redboot should no longer be active
>> > >unless blinky actually calls into Redboot via the virtual vectors.
>> > 
>> > Blinky is just a standalone program I decided to use as a test. The
>> only
>> > change I've made to it to make it run is to link it directly into
free
>> > ram so that I can run it after having loaded it from Redboot (with
a
>> > load -r -m ymodem -b 0x20005b68). 
>> > The reason I know that Redboot is handling (or at least that
Redboot
>> > code is being called) the IRQ is that I put while(1){flash an led
>> every
>> > second} at the top of hal_IRQ_handler and that it gets stuck there
>> when
>> > I run Blinky.
>> 
>> Then, this is just as it should be :-)  Unless you make Blinky into
an
>> eCos program, which uses the HAL interrupt mechanisms, RedBoot is
quite
>> happily going to try and handle the interrupt, etc.
>> 
>> -- 
>> ------------------------------------------------------------
>> Gary Thomas                 |  Consulting for the
>> MLB Associates              |    Embedded world
>> ------------------------------------------------------------
>> 
>> 
>>
------------------------------------------------------------------------
--------
>> 
>> 
>> The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.
>> 
>> If you received this in error, please contact the sender or
postmaster (postmaster@hanoverdisplays.com) and delete the material from
any computer.
>> 
>> Although we routinely screen for viruses, addressees should check
this e-mail and any attachment for viruses. We make no warranty as to
absence of viruses in this e-mail or any attachments.
>> 
>> Our Company's email policy is to permit incidental personal use. If
this email is of a personal nature, it must not be relied upon as
expressing the views or opinions of the company.
>> 
>> Visit out website at www.hanoverdisplays.com
>> 
>> 
>> 
>-- 
>------------------------------------------------------------
>Gary Thomas                 |  Consulting for the
>MLB Associates              |    Embedded world
>------------------------------------------------------------
>
>

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

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

>-----Original Message-----
>From: Andrew Lunn [mailto:andrew@lunn.ch] 
>Sent: 16 August 2005 15:25
>To: Matt Sartori
>Cc: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] interrupt/virtual vectors confusion
>
>On Tue, Aug 16, 2005 at 03:06:39PM +0100, Matt Sartori wrote:
>> 
>> >Is Blinky an eCos RAM program? If so it should of taken over the
>> >interrupt vectors from Redboot. Redboot should no longer be active
>> >unless blinky actually calls into Redboot via the virtual vectors.
>> 
>> Blinky is just a standalone program I decided to use as a test. The
only
>> change I've made to it to make it run is to link it directly into
free
>> ram so that I can run it after having loaded it from Redboot (with a
>> load -r -m ymodem -b 0x20005b68). 
>> The reason I know that Redboot is handling (or at least that Redboot
>> code is being called) the IRQ is that I put while(1){flash an led
every
>> second} at the top of hal_IRQ_handler and that it gets stuck there
when
>> I run Blinky.
>
>Well if you have not taken over the vector it will still be Redboot
>that controls it. If blinky needs to handle the vector simply take it
>over. 
>
>> >The vectors will be in RAM, not ROM. On ARM architectures what
>> >normally happens is that at startup ROM is mapped to address 0x0.
Once
>> >the program is running is remaps the memory so that ROM is moved to
>> >higher addresses and RAM is mapped to address 0x0. The vectors can
>> >then be changed by the application. 
>> 
>> Hmm. I know that my board maps Flash ROM (0x40000000) to 0x00000000.
It
>> also puts something in RAM because when I run Redboot I get the 
>> 	RAM: 0x20000000-0x20010000, [0x20005b68-0x20010000] available 
>> Message. On an interrupt the PC goes to 0x00000018 which is where
>> Redboot's vector sits (having been mapped by the board) and that's
why
>> (I think) the Redboot ends up handling my interrupts. Do you mean
that
>> Redboot also remaps it's vector to 0x20000000? 
>
>The RAM could be mapped into two locations in the address space at the
>same time. You need to read the datasheet for you processor to find
>out what it actually does. 

A quick look at my datasheet mentions that RAM is mapped both to
0x20000000 and 0x00000000, but only in RAM boot mode. I am currently
running in user flash boot mode.

>
>> When you say "the
>> program...remaps the memory" is the program Redboot or your own
program?
>
>eCos ROM application will do this. If the vector was in ROM there
>would be no way for an appliction to register its interupt
>handlers....
>
>RedBoot is just an eCos ROM appliction, so it will of done this. When
>you blinky program gets to run this mapping will still be in force. 
>

The root of my problem.

>Just try overwritting the vector at 0x18 and see what happens. If im
>wrong and it is still in ROM it will either throw on exception and
>drop into the gdb stubs, or the value will not change.

I have tried overwriting the vector at 0x00000018 which is just ignored.
I've not tried changing 0x20000018 if that's what you mean.



--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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

RE: [ECOS] interrupt/virtual vectors confusion

[Gary Thomas]

On Tue, 2005-08-16 at 15:27 +0100, Matt Sartori wrote:
> Eeek! But that would mean that Redboot can only properly work as a
> bootloader for Redboot "enabled" programs. It was my understanding (and
> basis for advocating it as a viable alternative to writing our own
> custom bootloader) that Redboot is able to run any application and only
> re-appear when the board is reset.

It absolutely *can* do what you want, but if your hardware does not 
have an easy way to redirect the VSR handling (where code jumps to when
an interrupt or exception happens), then you'll have to add some code
to your HAL to make this work cooperatively.  If that's the case, then
your application will still have to somehow indicate to RedBoot what it
wants to do when the interrupt or exception happens.  We're just talking
semantic details here - either you invent some mechanism to handle this
or you run eCos programs (which will also have to have similar 
mechanisms via the HAL).

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com] 
> Sent: 16 August 2005 15:18
> To: Matt Sartori
> Cc: Andrew Lunn; eCos Discussion
> Subject: RE: [ECOS] interrupt/virtual vectors confusion
> 
> On Tue, 2005-08-16 at 15:06 +0100, Matt Sartori wrote:
> > >Is Blinky an eCos RAM program? If so it should of taken over the
> > >interrupt vectors from Redboot. Redboot should no longer be active
> > >unless blinky actually calls into Redboot via the virtual vectors.
> > 
> > Blinky is just a standalone program I decided to use as a test. The
> only
> > change I've made to it to make it run is to link it directly into free
> > ram so that I can run it after having loaded it from Redboot (with a
> > load -r -m ymodem -b 0x20005b68). 
> > The reason I know that Redboot is handling (or at least that Redboot
> > code is being called) the IRQ is that I put while(1){flash an led
> every
> > second} at the top of hal_IRQ_handler and that it gets stuck there
> when
> > I run Blinky.
> 
> Then, this is just as it should be :-)  Unless you make Blinky into an
> eCos program, which uses the HAL interrupt mechanisms, RedBoot is quite
> happily going to try and handle the interrupt, etc.
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------------------
> 
> 
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
> 
> If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.
> 
> Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.
> 
> Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.
> 
> Visit out website at www.hanoverdisplays.com
> 
> 
> 
-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

Re: [ECOS] interrupt/virtual vectors confusion

[Andrew Lunn]

On Tue, Aug 16, 2005 at 03:27:34PM +0100, Matt Sartori wrote:
> Eeek! But that would mean that Redboot can only properly work as a
> bootloader for Redboot "enabled" programs. It was my understanding (and
> basis for advocating it as a viable alternative to writing our own
> custom bootloader) that Redboot is able to run any application and only
> re-appear when the board is reset.

It can run non redboot aware applications. eg Linux completely takes
over the machine and never uses Redboot. You application can do the
same.  You have complete control of the hardware....

        Andrew


> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com] 
> Sent: 16 August 2005 15:18
> To: Matt Sartori
> Cc: Andrew Lunn; eCos Discussion
> Subject: RE: [ECOS] interrupt/virtual vectors confusion
> 
> On Tue, 2005-08-16 at 15:06 +0100, Matt Sartori wrote:
> > >Is Blinky an eCos RAM program? If so it should of taken over the
> > >interrupt vectors from Redboot. Redboot should no longer be active
> > >unless blinky actually calls into Redboot via the virtual vectors.
> > 
> > Blinky is just a standalone program I decided to use as a test. The
> only
> > change I've made to it to make it run is to link it directly into free
> > ram so that I can run it after having loaded it from Redboot (with a
> > load -r -m ymodem -b 0x20005b68). 
> > The reason I know that Redboot is handling (or at least that Redboot
> > code is being called) the IRQ is that I put while(1){flash an led
> every
> > second} at the top of hal_IRQ_handler and that it gets stuck there
> when
> > I run Blinky.
> 
> Then, this is just as it should be :-)  Unless you make Blinky into an
> eCos program, which uses the HAL interrupt mechanisms, RedBoot is quite
> happily going to try and handle the interrupt, etc.
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------------------
> 
> 
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
> 
> If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.
> 
> Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.
> 
> Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.
> 
> Visit out website at www.hanoverdisplays.com
> 
> 

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

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

Eeek! But that would mean that Redboot can only properly work as a
bootloader for Redboot "enabled" programs. It was my understanding (and
basis for advocating it as a viable alternative to writing our own
custom bootloader) that Redboot is able to run any application and only
re-appear when the board is reset.
-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com] 
Sent: 16 August 2005 15:18
To: Matt Sartori
Cc: Andrew Lunn; eCos Discussion
Subject: RE: [ECOS] interrupt/virtual vectors confusion

On Tue, 2005-08-16 at 15:06 +0100, Matt Sartori wrote:
> >Is Blinky an eCos RAM program? If so it should of taken over the
> >interrupt vectors from Redboot. Redboot should no longer be active
> >unless blinky actually calls into Redboot via the virtual vectors.
> 
> Blinky is just a standalone program I decided to use as a test. The
only
> change I've made to it to make it run is to link it directly into free
> ram so that I can run it after having loaded it from Redboot (with a
> load -r -m ymodem -b 0x20005b68). 
> The reason I know that Redboot is handling (or at least that Redboot
> code is being called) the IRQ is that I put while(1){flash an led
every
> second} at the top of hal_IRQ_handler and that it gets stuck there
when
> I run Blinky.

Then, this is just as it should be :-)  Unless you make Blinky into an
eCos program, which uses the HAL interrupt mechanisms, RedBoot is quite
happily going to try and handle the interrupt, etc.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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

Re: [ECOS] interrupt/virtual vectors confusion

[Andrew Lunn]

On Tue, Aug 16, 2005 at 03:06:39PM +0100, Matt Sartori wrote:
> 
> >Is Blinky an eCos RAM program? If so it should of taken over the
> >interrupt vectors from Redboot. Redboot should no longer be active
> >unless blinky actually calls into Redboot via the virtual vectors.
> 
> Blinky is just a standalone program I decided to use as a test. The only
> change I've made to it to make it run is to link it directly into free
> ram so that I can run it after having loaded it from Redboot (with a
> load -r -m ymodem -b 0x20005b68). 
> The reason I know that Redboot is handling (or at least that Redboot
> code is being called) the IRQ is that I put while(1){flash an led every
> second} at the top of hal_IRQ_handler and that it gets stuck there when
> I run Blinky.

Well if you have not taken over the vector it will still be Redboot
that controls it. If blinky needs to handle the vector simply take it
over. 

> >The vectors will be in RAM, not ROM. On ARM architectures what
> >normally happens is that at startup ROM is mapped to address 0x0. Once
> >the program is running is remaps the memory so that ROM is moved to
> >higher addresses and RAM is mapped to address 0x0. The vectors can
> >then be changed by the application. 
> 
> Hmm. I know that my board maps Flash ROM (0x40000000) to 0x00000000. It
> also puts something in RAM because when I run Redboot I get the 
> 	RAM: 0x20000000-0x20010000, [0x20005b68-0x20010000] available 
> Message. On an interrupt the PC goes to 0x00000018 which is where
> Redboot's vector sits (having been mapped by the board) and that's why
> (I think) the Redboot ends up handling my interrupts. Do you mean that
> Redboot also remaps it's vector to 0x20000000? 

The RAM could be mapped into two locations in the address space at the
same time. You need to read the datasheet for you processor to find
out what it actually does. 

> When you say "the
> program...remaps the memory" is the program Redboot or your own program?

eCos ROM application will do this. If the vector was in ROM there
would be no way for an appliction to register its interupt
handlers....

RedBoot is just an eCos ROM appliction, so it will of done this. When
you blinky program gets to run this mapping will still be in force. 

Just try overwritting the vector at 0x18 and see what happens. If im
wrong and it is still in ROM it will either throw on exception and
drop into the gdb stubs, or the value will not change.

        Andrew

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

RE: [ECOS] interrupt/virtual vectors confusion

[Gary Thomas]

On Tue, 2005-08-16 at 15:06 +0100, Matt Sartori wrote:
> >Is Blinky an eCos RAM program? If so it should of taken over the
> >interrupt vectors from Redboot. Redboot should no longer be active
> >unless blinky actually calls into Redboot via the virtual vectors.
> 
> Blinky is just a standalone program I decided to use as a test. The only
> change I've made to it to make it run is to link it directly into free
> ram so that I can run it after having loaded it from Redboot (with a
> load -r -m ymodem -b 0x20005b68). 
> The reason I know that Redboot is handling (or at least that Redboot
> code is being called) the IRQ is that I put while(1){flash an led every
> second} at the top of hal_IRQ_handler and that it gets stuck there when
> I run Blinky.

Then, this is just as it should be :-)  Unless you make Blinky into an
eCos program, which uses the HAL interrupt mechanisms, RedBoot is quite
happily going to try and handle the interrupt, etc.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

Hi Gary,
Your suggestion is very close to what I want to do, but I have trouble
finding how/where to tell Redboot where the fixed handler is (all I
could find was fixed_vectors as mentioned below) and when the
documentation mentioned that the ARM architecture didn't use the
hal_vsr_table I became worried that I was just going down the wrong
path. Do you (or anyone reading this) know of an ARM port where this is
already done so I can use it for reference?

m@
-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com] 
Sent: 16 August 2005 14:39
To: Matt Sartori
Cc: eCos Discussion
Subject: Re: [ECOS] interrupt/virtual vectors confusion

On Tue, 2005-08-16 at 14:24 +0100, Matt Sartori wrote:
> Hello,
> 
>  
> 
> I am a bit confused as to how(or whether) to use virtual vectors for
> interrupt handling. My situation is as follows:
> 
> I have ported Redboot to run on an ST STR710FZ2 eval board and it is
> running fine. 
> 
> I load a separate binary (good old Blinky for now as a test) which
I've
> linked to sit in the RAM area that is left free by Redboot (for me
> currently 0x20005b68).
> 
> Blinky runs up to the point where an IRQ fires and the interrupt is
> caught and serviced by Redboot's IRQ and handle_IRQ_or_FIQ functions
> defined in vectors.S. That is not what I want.
> 
> What I want to do is to tell Redboot that I want to handle my own
> exceptions, ideally by jumping to my own vector table. 
> 
> The trouble is that, because Redboot runs from ROM, I can't, from
Blinky
> or any other RAM resident program, change the Redboot vector to jump
to
> my own ISRs. 
> 
> I understand that there is a way of telling Redboot to jump to a
second
> table (virtual vector table?) which can be changed to point to
whatever
> you want, but I am not sure how to set this up.
> 
> In vectors.S I can see a fixed_vectors section which defines a
> hal_vsr_table (as 8 nulled longs), but the eCos documentation states
> that the ARM (which is what I'm using) doesn't use the hal_vsr_table.
> 
>  
> 
> Has anyone had a similar problem or know of a good way of approaching
> this?

Yes, this is a common problem that needs to be solved.

Virtual vectors are not the solution - they are used for sharing 
services between the ROM (RedBoot) environment and an application.  
However, the HAL interrupt services is what you need to fix.  The way 
it's normally done is that the hardware interrupt/exceptions jump to 
some fixed  handler (called the VSR by eCos).  This handler then uses 
soft pointers (to the ISR routines) to decide how to further handle the 
interrupt. Most times, the VSR lives in RedBoot, but the ISR routines 
will live within your application.

I'd suggest that you look at how this indirection works on other
architectures (e.g. PowerPC or ARM) and mimic this functionality on
your port.

> 
>  
> 
> Thanks in advance,
> 
>  
> 
> m@
> 
>
------------------------------------------------------------------------
--------
> 
> 
> The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.
> 
> If you received this in error, please contact the sender or postmaster
(postmaster@hanoverdisplays.com) and delete the material from any
computer.
> 
> Although we routinely screen for viruses, addressees should check this
e-mail and any attachment for viruses. We make no warranty as to absence
of viruses in this e-mail or any attachments.
> 
> Our Company's email policy is to permit incidental personal use. If
this email is of a personal nature, it must not be relied upon as
expressing the views or opinions of the company.
> 
> Visit out website at www.hanoverdisplays.com
> 
> 

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

RE: [ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

>Is Blinky an eCos RAM program? If so it should of taken over the
>interrupt vectors from Redboot. Redboot should no longer be active
>unless blinky actually calls into Redboot via the virtual vectors.

Blinky is just a standalone program I decided to use as a test. The only
change I've made to it to make it run is to link it directly into free
ram so that I can run it after having loaded it from Redboot (with a
load -r -m ymodem -b 0x20005b68). 
The reason I know that Redboot is handling (or at least that Redboot
code is being called) the IRQ is that I put while(1){flash an led every
second} at the top of hal_IRQ_handler and that it gets stuck there when
I run Blinky.

>The vectors will be in RAM, not ROM. On ARM architectures what
>normally happens is that at startup ROM is mapped to address 0x0. Once
>the program is running is remaps the memory so that ROM is moved to
>higher addresses and RAM is mapped to address 0x0. The vectors can
>then be changed by the application. 

Hmm. I know that my board maps Flash ROM (0x40000000) to 0x00000000. It
also puts something in RAM because when I run Redboot I get the 
	RAM: 0x20000000-0x20010000, [0x20005b68-0x20010000] available 
Message. On an interrupt the PC goes to 0x00000018 which is where
Redboot's vector sits (having been mapped by the board) and that's why
(I think) the Redboot ends up handling my interrupts. Do you mean that
Redboot also remaps it's vector to 0x20000000? When you say "the
program...remaps the memory" is the program Redboot or your own program?


--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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

Re: [ECOS] interrupt/virtual vectors confusion

[Andrew Lunn]

On Tue, Aug 16, 2005 at 02:24:25PM +0100, Matt Sartori wrote:
> Hello,
> 
>  
> 
> I am a bit confused as to how(or whether) to use virtual vectors for
> interrupt handling. My situation is as follows:
> 
> I have ported Redboot to run on an ST STR710FZ2 eval board and it is
> running fine. 
> 
> I load a separate binary (good old Blinky for now as a test) which I've
> linked to sit in the RAM area that is left free by Redboot (for me
> currently 0x20005b68).
> 
> Blinky runs up to the point where an IRQ fires and the interrupt is
> caught and serviced by Redboot's IRQ and handle_IRQ_or_FIQ functions
> defined in vectors.S. That is not what I want.
> 
> What I want to do is to tell Redboot that I want to handle my own
> exceptions, ideally by jumping to my own vector table. 

Is Blinky an eCos RAM program? If so it should of taken over the
interrupt vectors from Redboot. Redboot should no longer be active
unless blinky actually calls into Redboot via the virtual vectors.

> The trouble is that, because Redboot runs from ROM, I can't, from Blinky
> or any other RAM resident program, change the Redboot vector to jump to
> my own ISRs. 

The vectors will be in RAM, not ROM. On ARM architectures what
normally happens is that at startup ROM is mapped to address 0x0. Once
the program is running is remaps the memory so that ROM is moved to
higher addresses and RAM is mapped to address 0x0. The vectors can
then be changed by the application. 

        Andrew

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

Re: [ECOS] interrupt/virtual vectors confusion

[Gary Thomas]

On Tue, 2005-08-16 at 14:24 +0100, Matt Sartori wrote:
> Hello,
> 
>  
> 
> I am a bit confused as to how(or whether) to use virtual vectors for
> interrupt handling. My situation is as follows:
> 
> I have ported Redboot to run on an ST STR710FZ2 eval board and it is
> running fine. 
> 
> I load a separate binary (good old Blinky for now as a test) which I've
> linked to sit in the RAM area that is left free by Redboot (for me
> currently 0x20005b68).
> 
> Blinky runs up to the point where an IRQ fires and the interrupt is
> caught and serviced by Redboot's IRQ and handle_IRQ_or_FIQ functions
> defined in vectors.S. That is not what I want.
> 
> What I want to do is to tell Redboot that I want to handle my own
> exceptions, ideally by jumping to my own vector table. 
> 
> The trouble is that, because Redboot runs from ROM, I can't, from Blinky
> or any other RAM resident program, change the Redboot vector to jump to
> my own ISRs. 
> 
> I understand that there is a way of telling Redboot to jump to a second
> table (virtual vector table?) which can be changed to point to whatever
> you want, but I am not sure how to set this up.
> 
> In vectors.S I can see a fixed_vectors section which defines a
> hal_vsr_table (as 8 nulled longs), but the eCos documentation states
> that the ARM (which is what I'm using) doesn't use the hal_vsr_table.
> 
>  
> 
> Has anyone had a similar problem or know of a good way of approaching
> this?

Yes, this is a common problem that needs to be solved.

Virtual vectors are not the solution - they are used for sharing 
services between the ROM (RedBoot) environment and an application.  
However, the HAL interrupt services is what you need to fix.  The way 
it's normally done is that the hardware interrupt/exceptions jump to 
some fixed  handler (called the VSR by eCos).  This handler then uses 
soft pointers (to the ISR routines) to decide how to further handle the 
interrupt. Most times, the VSR lives in RedBoot, but the ISR routines 
will live within your application.

I'd suggest that you look at how this indirection works on other
architectures (e.g. PowerPC or ARM) and mimic this functionality on
your port.

> 
>  
> 
> Thanks in advance,
> 
>  
> 
> m@
> 
> --------------------------------------------------------------------------------
> 
> 
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
> 
> If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.
> 
> Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.
> 
> Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.
> 
> Visit out website at www.hanoverdisplays.com
> 
> 

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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

[ECOS] interrupt/virtual vectors confusion

[Matt Sartori]

Hello,

 

I am a bit confused as to how(or whether) to use virtual vectors for
interrupt handling. My situation is as follows:

I have ported Redboot to run on an ST STR710FZ2 eval board and it is
running fine. 

I load a separate binary (good old Blinky for now as a test) which I've
linked to sit in the RAM area that is left free by Redboot (for me
currently 0x20005b68).

Blinky runs up to the point where an IRQ fires and the interrupt is
caught and serviced by Redboot's IRQ and handle_IRQ_or_FIQ functions
defined in vectors.S. That is not what I want.

What I want to do is to tell Redboot that I want to handle my own
exceptions, ideally by jumping to my own vector table. 

The trouble is that, because Redboot runs from ROM, I can't, from Blinky
or any other RAM resident program, change the Redboot vector to jump to
my own ISRs. 

I understand that there is a way of telling Redboot to jump to a second
table (virtual vector table?) which can be changed to point to whatever
you want, but I am not sure how to set this up.

In vectors.S I can see a fixed_vectors section which defines a
hal_vsr_table (as 8 nulled longs), but the eCos documentation states
that the ARM (which is what I'm using) doesn't use the hal_vsr_table.

 

Has anyone had a similar problem or know of a good way of approaching
this?

 

Thanks in advance,

 

m@

--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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