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

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

[Mike Sweeney]

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).

1) In vectors.S there is this code:

        // Come here to reset board
warm_reset:

#if defined(CYG_HAL_STARTUP_RAM) && \
    !defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)
        mrs     r7,cpsr                 // move back to IRQ mode
        and     r7,r7,#CPSR_MODE_BITS
        cmp     r7,#CPSR_SUPERVISOR_MODE
        beq     start
#endif

        // We cannot access any LED registers until after PLATFORM_SETUP1
        LED 7

        mov     r0,#0           // move vectors
        ldr     r1,=__exception_handlers

</snip>

        ldr     r2,[r1,#0x08]   // software interrupt
        str     r2,[r0,#0x08]

start:

I don't understand what this code is doing. The comment says "move
back to IRQ mode". If the processor is not in Supervisor mode then it
does some stuff as you can see above, but I don't see how it is
changing any mode here. What is the purpose of this code?

2) In this code from vectors.S:

        // Reset software interrupt pointer
        mov     r0,#0           // move vectors
        ldr     r1,.__exception_handlers
#if defined(CYG_HAL_STARTUP_RAM) && \
    !defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)
        cmp     r7,#CPSR_SUPERVISOR_MODE
        beq     10f
#endif
        ldr     r2,[r1,#0x28]   // software interrupt
        str     r2,[r0,#0x28]
10:

Why is the software interrupt vector only relocated if you are not in
supervisor mode, similar to the code snippet posted in question 1
above?

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.

I know this is long but I appreciate any answers!

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

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

[Andrew Lunn]

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).

Well, RAM startup does not remap memory around. It assumes that the
ROM redboot or what ever loader has already done this. So you might
need to make some changes in vector.S
 
> 1) In vectors.S there is this code:
> 
>        // Come here to reset board
> warm_reset:
> 
> #if defined(CYG_HAL_STARTUP_RAM) && \
>    !defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)
>        mrs     r7,cpsr                 // move back to IRQ mode
>        and     r7,r7,#CPSR_MODE_BITS
>        cmp     r7,#CPSR_SUPERVISOR_MODE
>        beq     start
> #endif
> 
>        // We cannot access any LED registers until after PLATFORM_SETUP1
>        LED 7
> 
>        mov     r0,#0           // move vectors
>        ldr     r1,=__exception_handlers
> 
> </snip>
> 
>        ldr     r2,[r1,#0x08]   // software interrupt
>        str     r2,[r0,#0x08]
> 
> start:
> 
> I don't understand what this code is doing. The comment says "move
> back to IRQ mode". If the processor is not in Supervisor mode then it
> does some stuff as you can see above, but I don't see how it is
> changing any mode here. What is the purpose of this code?

Sorry, i cannot figure it out either!
 
> 2) In this code from vectors.S:
> 
>        // Reset software interrupt pointer
>        mov     r0,#0           // move vectors
>        ldr     r1,.__exception_handlers
> #if defined(CYG_HAL_STARTUP_RAM) && \
>    !defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)
>        cmp     r7,#CPSR_SUPERVISOR_MODE
>        beq     10f
> #endif
>        ldr     r2,[r1,#0x28]   // software interrupt
>        str     r2,[r0,#0x28]
> 10:
> 
> Why is the software interrupt vector only relocated if you are not in
> supervisor mode, similar to the code snippet posted in question 1
> above?

Guess: it is to do with Redboot. If CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
is not defined i assume it assumes that Redboot is acting as a GDB
stub. For single stepping to work, redboot needs to keep hold of the
software interrupt vector. A single step works be inserting a software
interrupt instruction which traps into redboot which still has the
vector hooked. 

Since you don't have RedBoot, is suggest you define If
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS so your application contains the
stubs.

> 
> 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

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

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

[Mike Sweeney]

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

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

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Sweeney wrote:
> 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.
> 

You could just pretend that some portion of your RAM, e.g. the top
end, is "ROM" and set up the mappings that way.  Your NAND loader
could unpack the code into the "ROM" space.  It could then setup
the MMU, map memory the way eCos wants it (just like other platforms
do in ROM mode) and then start execution.

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGZImfmaKbSsQGV8ARAuT2AJ9wuIIifJK6gqfJz8/UjSke3SiAxACePlYO
K0XjuAeZOcXctUD7RKEYRGk=
=zECa
-----END PGP SIGNATURE-----

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