RE: [ECOS] ARM port architecture questions

[Gary Thomas <gthomas at ecoscentric dot com>]

On Mon, 2002-11-25 at 12:00, Patrick Doyle wrote:
> > > 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.

Getting the MMU going should take you less time than it took to write
this explanation :-)  Just look at (i.e. copy) the setup code from a 
working platform, such as the iPAQ or one of the ARM9 platforms.  Fill
in the specifics in the hal_mmu_init() function and you're done.

-- 
------------------------------------------------------------
Gary Thomas                  |
eCosCentric, Ltd.            |  
+1 (970) 229-1963            |  eCos & RedBoot experts
gthomas@ecoscentric.com      |
http://www.ecoscentric.com/  |
------------------------------------------------------------


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