RE: [ECOS] interrupt/virtual vectors confusion

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

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