This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: ARM port architecture questions
- From: Gary Thomas <gthomas at ecoscentric dot com>
- To: Patrick Doyle <wpd at delcomsys dot com>
- Cc: Andrew Lunn <andrew dot lunn at ascom dot ch>,eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 25 Nov 2002 12:10:06 -0700
- Subject: RE: [ECOS] ARM port architecture questions
- References: <NFBBJAJICAKJPMMKDAGBIEOCDGAA.wpd@delcomsys.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