[ECOS] ARM architectural HAL questions (related to porting)

Mike Sweeney msweeney77@gmail.com
Mon Jun 4 21:28:00 GMT 2007


On 6/4/07, Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, Jun 03, 2007 at 09:33:54PM -0400, Mike Sweeney wrote:
> > I am porting eCos to a new platform and XScale variant so I have some
> > questions related to the ARM architectural HAL. I have a custom board
> > and have NAND flash that I am going to burn my eCos image into. I have
> > my own loader that copies the complete image from NAND flash into the
> > image's load address in RAM. Since the RAM on my board is not located
> > at 0x0, early in the eCos HAL startup code I am going to enable the
> > MMU and locate RAM at 0x0(seems like PLATFORM_SETUP1 is the right
> > place). My code will be linked to address 0x0 so the initial startup
> > code will need to be position independent before the MMU kicks in.
> > Hopefully this will help provide context in answering my questions
> > below.
> >
> > My intended mode of startup seems to correspond to the RAM startup
> > type but it doesn't seem to fit perfectly into this characterization
> > based on the ARM architectural HAL implementation (vectors.S).
>
> >
> > 3) In vectors.S there is then code to copy the vector table and fixed
> > vectors to address 0x0. In my linker script couldn't I just link the
> > ".vectors" section to address 0x0 and then there would be no need for
> > "hal_vsr_table" in the fixed_vectors section? Basically my loader
> > would copy my entire flash image into RAM at some load address and
> > when I turn the MMU on .vectors would now be located at 0x0 without
> > the need for a copy operation. It seems I can get by without doing
> > what I suggest here and just using the default implementation in
> > vectors.S here but I am more curious as to whether my approach is
> > technically feasible.
>
> It might even be easier to actually build a ROM application, but run
> it in RAM. ROM applications are used to munging the MMU to put RAM in
> the right place and all this stub stuff should just work. You just
> need to be careful of your SDRAM controller initialization code. If
> the initialization code finds the SDRAM controller is already
> initialized, leave it alone. Reinitializing while running from SDRAM
> generally does not work...
>
>           Andrew

Andrew,

I appreciate your response. The problem with building a ROM
application is that the initialized data section is copied to RAM in
vectors.S. The linker-defined symbols it uses to do the copying will
point to memory that it can't access using a simple load instruction.
I think I can get this to work without messing with vectors.S but
there will be some unnecessary/redundant code that will run in
vectors.S. I'm not concerned with this though.

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



More information about the Ecos-discuss mailing list