RE: [ECOS] ARM port architecture questions

["Patrick Doyle" <wpd at delcomsys dot com>]

> > 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.
>
Oh, Of course... Sorry 'bout that chief.  If I had just spent two more
minutes looking at the code and using the stuff God put between my ears, I
should have realized that.  Instead, I saw two copies every time there was
one copy, and I thought, "Gee, that seems odd, I'll have to ask somebody
about that"

> > 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
I was hoping to get things going without enabling the MMU (in the interest
of a quick turn -- all I really need is to get RedBoot up enough to enable
loading in arbitrary programs).  So, what I was thinking about was putting
"Branch to PC + 0x400000" instructions in the vectors at address 0 and then
telling the HAL that it should expect to find RAM and the interrupt vectors
starting at address 0x400000.  I know I can enable the MMU and place RAM
wherever I want.  I also know that I can remap the interrupt vectors to a
different address through a coprocessor register.  (Unfortunately, I don't
have RAM at that address either... sigh).

Ultimately, I am trying to figure out what will get things going the
quickest... learning about the MMU or changing the ARM9 HAL to allow for
interrupt vectors at a different location.  Both sound like opportunities to
get tripped up for a few days over some silly little detail.  Ultimately, if
all I want to run is RedBoot, (so I can load other programs on the device)
then it doesn't really matter, since RedBoot doesn't use any interrupts.
But if I want to enable debugging, or want to run the rest of eCos on the
platform (which I will want to do eventually), I need to pick one approach
over the other.  The MMU approach has the most long term advantages (I'll
have to do it someday, no matter what).  But the CDL option to support an
alternative vector base feels like it ought to be easier to implement...
unless I am missing something.

--wpd


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