This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM port architecture questions


On Mon, Nov 25, 2002 at 11:14:15AM -0500, Patrick Doyle wrote:
> I have a couple of questions about the eCos port to the ARM architecture.
> As I wander through vectors.S, I noticed a few things...
> 
> 1) It appears that the 8 (well, 7 actually, plus one undefined) exception
> vectors at address 0 .. 0x20 are duplicated at address 0x20..0x40.  Am I
> interpreting this correctly?  Why is this?


Not duplicates. The code at 0-0x20 load the PC with the value
contained at 0x20-0x40. Its done like this because with a 32 bit
instruction you cannot jump to any arbitrary location in a 32 bit
address space. You need the indirection. It also makes it easier to
dynamically change the address to jump to. This is what happens when
you install a VSR. You just need to put in the location. Otherwise you
would need to build the machine code instruction from the address.

> 2) It also appears that vectors.S his hard wired to expect the exception
> vectors at address 0.  I can understand why this is the case, since the
> processor is hard wired to find its vectors at this address, but some
> processors offer a means to change the default vector location to high
> memory.  Or, in my case, I might have a ROM at address 0 that branches to a
> RAM vector table.  (Yes, I know this is more expensive than having RAM at
> address 0 and less correct/elegant than using the MMU to map RAM to address
> 0, but it's what I have today).  How difficult would it be for me to add a
> CDL option to allow the vectors to be remapped to an arbitrary (correctly
> aligned) address?  Am I setting myself up for failure if I attempt this?

The ROM has to be at 0 to boot. You then have to move it somewhere
else so that you can change the vectors. There are generally two ways
to do this. The hardware can remap it. The EBSA285 does this. The
first write causes the ROM to be remapped of 0x41000000. The second
way it to use the MMU map the virtual memory address 0 to a physical
address which is in RAM.

Before doing what you want to do, i would make sure the two ways above
are not possible. The ARM HAL already supports this, so it will be
less effort to get it working for your hardware than doing something
new.

        Andrew

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]