RE: [ECOS] interrupt/virtual vectors confusion

["Matt Sartori" <msartori at hanoverdisplays dot com>]

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