Re: [ECOS] interrupt/virtual vectors confusion

[Andrew Lunn <andrew@lunn.ch>]

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