This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Memory Map conventions
- From: Grant Likely <glikely at gmail dot com>
- To: Grant Likely <glikely at gmail dot com>, ecos-discuss <ecos-discuss at sources dot redhat dot com>, kevin dot cabral at gdcanada dot com
- Date: Tue, 18 Jan 2005 10:22:47 -0700
- Subject: Re: [ECOS] Memory Map conventions
- References: <528646bc0501180856c62333c@mail.gmail.com> <20050118170743.GA26060@lunn.ch>
- Reply-to: Grant Likely <glikely at gmail dot com>
On Tue, 18 Jan 2005 18:07:43 +0100, Andrew Lunn <andrew@lunn.ch> wrote:
> > However, the PXA reset code (at least for the uE250) does something
> > different. Rather than a one to one mapping from virtual address to
> > physical address, the MMU setup goes through contortions to remap
> > SDRAM from 0xA0000000 to 0x00000000 and remap FLASH from 0x00000000 to
> > 0x50000000. This makes the ROM/RAM addresses look the same as on the
> > IXP platform. However, it makes the bootup code complex and the
> > current code cannot support ROMRAM images. (In fact, from what I
> > understand it doesn't look like ROM images will work properly either
> > because I cannot find the copy from ROM to RAM).
> >
>
> You need RAM where the vectors is, ie at 0. If you don't do this, you
> cannot install interrupt handler etc. So all ARM targets will somehow
> get RAM at address 0 and FLASH somewhere else.
Ahh, I did not know that you could not relocate the vector table on the ARM.
>
> The ROM image will work, otherwise REDBOOT would not work, which is a
> ROM image. ROM means it runs from ROM, so there is no need to do a
> copy. The ROM image is linked to run at the higher address. The
> startup code should be position independant so that it can run at the
> low address and continue to run at the high address when the remap
> occurs.
Sorry, brain failure on my end; I should have written "because I
cannot figure out how the PC traverses from running the physical
address of 0x00000000 to the virtual address when the MMU is enabled."
I just went back and looked at it again and now I see the jump that
allows the PC to follow FLASH when it moves from the physical address
to the virtual address. I assume that pipelining allows the "mov pc,
r2" instruction to be executed after the MMU is enabled. Is that
correct?
>
> ROMRAM startup copies itself from ROM into RAM.
>
> So best practice is to put RAM at 0. It does not realy matter where
> ROM goes after its remapped, but if you do put it at the same place as
> some other HAL, it means you can copy the linker scripts etc.
>
Thanks, that's a huge help.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss