This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM architectural HAL questions (related to porting)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]