[ECOS] ARM Vectors.S Question

[ECOS] ARM Vectors.S Question

[Michael Jones]

I am having some trouble understanding the ARM startup. I am not using one the existing HAL, so I can't get in a debugger to see how things work. I am doing a new HAL.

The code that sets up the exception table does not have enough space so when virtual vectors are turned on, hal_if is stepping on the vectors. 

The Vectors.S file has the following code:

        .global __exception_handlers
__exception_handlers:
#ifdef CYGSEM_HAL_ROM_RESET_USES_JUMP
// Assumption:  ROM code has these vectors at the hardware reset address.
// A simple jump removes any address-space dependencies [i.e. safer]
        b       reset_vector                    // 0x00
#else        
        ldr     pc,.reset_vector                // 0x00
#endif        
        ldr     pc,.undefined_instruction       // 0x04
        ldr     pc,.software_interrupt          // 0x08 start && software int
        ldr     pc,.abort_prefetch              // 0x0C
        ldr     pc,.abort_data                  // 0x10
#ifdef CYGNUM_HAL_ARM_VECTOR_0x14
        .word   CYGNUM_HAL_ARM_VECTOR_0x14
#else
        .word   0                               // unused
#endif
        ldr     pc,.IRQ                         // 0x18
        ldr     pc,.FIQ                         // 0x1C

// The layout of these pointers should match the vector table above since
// they are copied in pairs.
        .global vectors
vectors:
UNMAPPED_PTR(reset_vector)                      // 0x20
PTR(undefined_instruction)                      // 0x24
PTR(software_interrupt)                         // 0x28
PTR(abort_prefetch)                             // 0x2C
PTR(abort_data)                                 // 0x30
        .word   0                               // 0x34
PTR(IRQ)                                        // 0x38
PTR(FIQ)                                        // 0x3c
#ifdef CYGSEM_HAL_ARM_PID_ANGEL_BOOT         
PTR(start) // This is copied to 0x28 for bootup // 0x40
#endif        
           // location 0x40 is used for storing DRAM size if known
           // for some platforms.
        
//
// "Vectors" - fixed location data items
//    This section contains any data which might be shared between
// an eCos application and any other environment, e.g. the debug
// ROM.                        
//
        .section ".fixed_vectors"
        // Interrupt/exception VSR pointers
        .globl  hal_vsr_table
hal_vsr_table:
        .rept   8               
        .long   0
        .endr

        .globl  hal_dram_size
hal_dram_size:  
        .long   0
	// what, if anything, hal_dram_type means is up to the platform
        .globl  hal_dram_type
hal_dram_type:  
        .long   0

        .balign 16
#ifdef CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT
	// Vectors used to communicate between eCos and ROM environments
        .globl  hal_virtual_vector_table
hal_virtual_vector_table:
        .rept   CYGNUM_CALL_IF_TABLE_SIZE
        .long   0
        .endr
#endif

The hal_vsr_table allocates 8 longs. But the vector table requires 16 longs, 8 are the exception handlers (load the pc), and 8 are vectors.

The 16 longs are copied in place in pairs with code like this:

        ldr     r2,[r1,#HAL_ARM_IRQ_VECTOR]   // IRQ
        str     r2,[r0,#HAL_ARM_IRQ_VECTOR]
        ldr     r2,[r1,#HAL_ARM_IRQ_VECTOR_ADDR]
        str     r2,[r0,#HAL_ARM_IRQ_VECTOR_ADDR]


Because hal_virtual_vector_table is near the hal_vsr_table, hal_if steps on the vectors.

The only way I can imagine this every worked with virtual vectors would be if if the table were based on 2 byte instructions and address, which does not make any sense to me. The addresses are all 32 bits, at least in my case.

Can someone either confirm this is incorrectly coded and should be like this:

        .globl  hal_vsr_table
hal_vsr_table:
        .rept   16       <========              
        .long   0
        .endr

Or explain why this works on typical ARM platforms so I know what is different than my platform.

Thanks,

Mike

--
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 vectors.S question

[Gary Thomas]

On 27-Oct-99 Grant Edwards wrote:
>> Firstly, you should consider working from the public CVS repository.  This
>> has the latest stuff in it, including much work that lets items such as
>> this be specified in platform specific files, not directly in "vectors.S".
> 
> OK, I'll take a look at the CVS tree -- having to modify what were
> supposed to be platform-independant files made me think that I was
> headed in the wrong direction.  Are there semi-stable CVS snapshots,
> or is a guy pretty much rolling the dice when using sources from the
> CVS tree?
> 

The public version of the CVS tree is updated from our working CVS about
once a week.  We try to keep the CVS tree in a constant working state since
we have so much parallel development (the *!@# really flies when the tree
gets broken :-)  If you grab it today, you'll have a good version that
shouldn't be more than a few days old.

>> I'll try and provide help/guidance with whatever changes you need.
>> Note that there are other places than "vectors.S" that expect low memory
>> to be writeable so vectors can be updated.  Unless you can take the
>> "remap" route, there will be other considerations.
> 
> Thanks.  That's a very useful tip.  I should be able to go either way:
> remapping ROM/RAM in startup code or having ROM vectors go through
> RAM.  Initially I was thinking of sticking with the ROM vectors, but
> it sounds like remapping might be a better idea.
> 

Absolutely, remapping is the best [lowest cost/risk] way to do this.

>> > I must say that the ARM load/store instructions are about the coolest
>> > I've seen since the PDP-11.
>> 
>> I shudder to think what you've been working with...
> 
> Mostly the usual crop of embedded architectures (8086, 8051, 68HC11,
> 68332) and the TI TMS32C320 DSP for a while [it was wierd having
> sizeof (everyting) == 1].
> 

Yeuch!

Let me (via the list) know if you have questions or problems.

Re: [ECOS] ARM vectors.S question

[Grant Edwards]

On Wed, Oct 27, 1999 at 06:21:41AM -0600, Gary Thomas wrote:

> > Perhaps my prejudices from doing 15 years of embedded systems are
> > showing, but I don't see how any system could be laid out this way.
> > Perhaps I don't understand how the power-up reset works in the CPU?
> 
> No, we would never assume that RAM survives a reset :-)
> 
> Most hardware that has RAM at 0x0 and the ROM somewhere else has shadow
> magic that makes the ROM appear at 0x0, either for a fixed number of cycles
> after reset or until a control latch is reset.

Ah yes, about 20 years ago I had an S-100 bus Z-80 bus system that did
the shadow rom for X cycles after reset trick.  I had forgotten about that.

> Firstly, you should consider working from the public CVS repository.  This
> has the latest stuff in it, including much work that lets items such as
> this be specified in platform specific files, not directly in "vectors.S".

OK, I'll take a look at the CVS tree -- having to modify what were
supposed to be platform-independant files made me think that I was
headed in the wrong direction.  Are there semi-stable CVS snapshots,
or is a guy pretty much rolling the dice when using sources from the
CVS tree?

> Are you using the CVS version, or some other source release?

I'm using the 1.2.1 official release.

> I'll try and provide help/guidance with whatever changes you need.
> Note that there are other places than "vectors.S" that expect low memory
> to be writeable so vectors can be updated.  Unless you can take the
> "remap" route, there will be other considerations.

Thanks.  That's a very useful tip.  I should be able to go either way:
remapping ROM/RAM in startup code or having ROM vectors go through
RAM.  Initially I was thinking of sticking with the ROM vectors, but
it sounds like remapping might be a better idea.

> > I must say that the ARM load/store instructions are about the coolest
> > I've seen since the PDP-11.
> 
> I shudder to think what you've been working with...

Mostly the usual crop of embedded architectures (8086, 8051, 68HC11,
68332) and the TI TMS32C320 DSP for a while [it was wierd having
sizeof (everyting) == 1].

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] ARM vectors.S question

[Gary Thomas]

On 27-Oct-99 Grant Edwards wrote:
> On Tue, Oct 26, 1999 at 04:12:25PM -0600, Gary Thomas wrote:
> 
>> > For example, it assumes that there is RAM at address 0 so the
>> > startup code initializes the exception vectors that are at address 0.
>> > 
>> > After reset, the SNDS board has ROM at address 0, as will any embedded
>> > system (if I understand the processor startup sequence).  There are
>> > two ways to deal with this:
>> > 
>> >  1) The SNDS ROM vectors interrupts via a table of addresses that is
>> >     in RAM, so user code can install pointers to ISRs in RAM at a
>> >     particular address (0x13fffd0, FWIW).
>> > 
>> >  2) The memory configuration can be altered after startup to re-map RAM
>> >     to address 0 and ROM to somewhere else.
>> > 
>> > Either of these would require changes to "platform independent"
>> > sections of eCOS. 
>> > 
>> > Am I missing something?
>> 
>> Not at all.  To date, we have assumed that the environment on ARM platforms
>> will have RAM at zero.  This is the most flexible and easiest setup for us.
> 
> I can see that it would be easiest, but I don't see how you can build
> a useful system with RAM at zero.  Since the reset vector is at 0,
> that location has to be non-volatile memory or the system will start
> up by jumping to a location dependant on the power-up state of the
> RAM.  Some types of RAM ahve a pretty consistent state at power-up,
> but I don't think anybody ever depends on that trait. ;)
> 
>> However, as you note, there are some platforms that are not laid out
>> this way.
> 
> Perhaps my prejudices from doing 15 years of embedded systems are
> showing, but I don't see how any system could be laid out this way.
> Perhaps I don't understand how the power-up reset works in the CPU?
> 

No, we would never assume that RAM survives a reset :-)

Most hardware that has RAM at 0x0 and the ROM somewhere else has shadow
magic that makes the ROM appear at 0x0, either for a fixed number of cycles
after reset or until a control latch is reset.

>> For the ones of these that we have already encountered, we chose to
>> implement solution (2) above.
>>
>> There certainly will be some situations where only (1) will do.
>> If/when that becomes the case, we'll have to adopt a "vectored"
>> approach.
>>
>> Does your hardware have a MMU or some other way to alter the memory
>> layout?
> 
> Yes, there's programmable chip-select logic that can be modified by
> software.
> 
> The third option is to run from ROM, in which case the vectors are there
> at power up, and don't need to be initialized by the startup code.
>

Absolutely.
 
> In any case, I have to change the platform independent portion of the
> ARM hal to suit my platform, right?  (he asked with a grin).  I've got
> no problem with that,  I just wanted to make sure that I was headed in
> the right direction before I started hacking on assembly language for
> a processor I've only been playing with for a week.
> 

Firstly, you should consider working from the public CVS repository.  This
has the latest stuff in it, including much work that lets items such as
this be specified in platform specific files, not directly in "vectors.S".

Are you using the CVS version, or some other source release?

I'll try and provide help/guidance with whatever changes you need.
Note that there are other places than "vectors.S" that expect low memory
to be writeable so vectors can be updated.  Unless you can take the
"remap" route, there will be other considerations.

> I must say that the ARM load/store instructions are about the coolest
> I've seen since the PDP-11.
> 

I shudder to think what you've been working with...

Re: [ECOS] ARM vectors.S question

[Hugo Tyson]

Grant Edwards <grante@visi.com> writes:
> On Tue, Oct 26, 1999 at 04:12:25PM -0600, Gary Thomas wrote:
> > > Am I missing something?
> > 
> > Not at all.  To date, we have assumed that the environment on ARM platforms
> > will have RAM at zero.  This is the most flexible and easiest setup for us.
> 
> I can see that it would be easiest, but I don't see how you can build
> a useful system with RAM at zero.  Since the reset vector is at 0,
> that location has to be non-volatile memory or the system will start
> up by jumping to a location dependant on the power-up state of the
> RAM.  Some types of RAM ahve a pretty consistent state at power-up,
> but I don't think anybody ever depends on that trait. ;)

Correct; what the designers intended, and what ARM systems generally do is:

At hard reset, ROM is mapped at zero and also at 0xe0000000 or whatever its
"real" address is.  (Implementation may be brutal: for example, A16-A31
ignored, so you have to fit this boot code in only 64k - not so tough...)

During bootup, the code running in low memory jumps to addresses in high
memory, so it is executing out of ROM at its "real" address.
(This is easy: you can even do something like:
	orr pc,pc,#0xe0000000; nop; nop; nop; nop; nop
and you'll be OK; ARMs are like that!)

That code then performs some action to cause RAM to be at zero instead, and
copies appropriate jump code into the RAM vectors to allow the system to
take traps.  "Some action" might involve the MMU or an explicit hardware
control register poke, or with some support chips, the first ever external
write op does this automagically.


The jump to lightspeed^W "real" ROM addresses is achieved in the ARM
vectors.S *either* by means of the indirect jump in the reset vector being
a "true" ROM address (eg. ebsa285, CYGHWR_HAL_ARM_HAS_MMU is not defined)
or by special code in PLATFORM_SETUP1, which is defined in the
hal_platform_setup.h file for the appropriate platform HAL (eg. cl7211).


> > However, as you note, there are some platforms that are not laid out
> > this way.
> 
> Perhaps my prejudices from doing 15 years of embedded systems are
> showing, but I don't see how any system could be laid out this way.
> Perhaps I don't understand how the power-up reset works in the CPU?

See above.  Making the ROM code use RAM vectors for all traps except reset
is another way to go.  But this loses you the intended advantage of being
able to place extensive FIQ handling code at 0x1c *in RAM* - not that eCos
supports this, we place address-type vectors just after the
instruction-type vectors as it happens.

> > Does your hardware have a MMU or some other way to alter the memory
> > layout?
> 
> Yes, there's programmable chip-select logic that can be modified by
> software.

That fits nicely with the model, then, so long as you can wire it so that
ROM is at 0 after reset, where-ever else it was before.
 
> The third option is to run from ROM, in which case the vectors are there
> at power up, and don't need to be initialized by the startup code.

Yup.

HTH,
	- Huge

Re: [ECOS] ARM vectors.S question

[Dan Hovang]

Grant Edwards wrote:
> 
> I'm in the process of getting eCOS to run on a Samsung SNDS eval board
> (ARM7TDMI core w/ a bunch of on-chip Samsung peripherals).  The file
> ecos-1.2.1/packages/hal/arm/arch/v1_2_1/src/vectors.S claims to be
> platform independent, yet it seems to make assumptions about the
> memory map that are platform-dependent.
> 
> For example, it assumes that there is RAM at address 0 so the
> startup code initializes the exception vectors that are at address 0.
> 
> Am I missing something?

I'm using eCos in two different (allthough similar) StrongARM designs.
Both of theese start from FlashROM and works fine. When creating the
buildtree I use the option --startup=rom to define CYG_HAL_STARTUP_ROM
and undefine CYG_HAL_STARTUP_RAM. The default option is --startup=ram.

-- 
Dan Hovang (dh@cpen.com)
CTechnologies AB
Ideon Research Park
Scheelev 15
223 70 Lund
Sweden

Re: [ECOS] ARM vectors.S question

[Grant Edwards]

On Tue, Oct 26, 1999 at 04:12:25PM -0600, Gary Thomas wrote:

> > For example, it assumes that there is RAM at address 0 so the
> > startup code initializes the exception vectors that are at address 0.
> > 
> > After reset, the SNDS board has ROM at address 0, as will any embedded
> > system (if I understand the processor startup sequence).  There are
> > two ways to deal with this:
> > 
> >  1) The SNDS ROM vectors interrupts via a table of addresses that is
> >     in RAM, so user code can install pointers to ISRs in RAM at a
> >     particular address (0x13fffd0, FWIW).
> > 
> >  2) The memory configuration can be altered after startup to re-map RAM
> >     to address 0 and ROM to somewhere else.
> > 
> > Either of these would require changes to "platform independent"
> > sections of eCOS. 
> > 
> > Am I missing something?
> 
> Not at all.  To date, we have assumed that the environment on ARM platforms
> will have RAM at zero.  This is the most flexible and easiest setup for us.

I can see that it would be easiest, but I don't see how you can build
a useful system with RAM at zero.  Since the reset vector is at 0,
that location has to be non-volatile memory or the system will start
up by jumping to a location dependant on the power-up state of the
RAM.  Some types of RAM ahve a pretty consistent state at power-up,
but I don't think anybody ever depends on that trait. ;)

> However, as you note, there are some platforms that are not laid out
> this way.

Perhaps my prejudices from doing 15 years of embedded systems are
showing, but I don't see how any system could be laid out this way.
Perhaps I don't understand how the power-up reset works in the CPU?

> For the ones of these that we have already encountered, we chose to
> implement solution (2) above.
>
> There certainly will be some situations where only (1) will do.
> If/when that becomes the case, we'll have to adopt a "vectored"
> approach.
>
> Does your hardware have a MMU or some other way to alter the memory
> layout?

Yes, there's programmable chip-select logic that can be modified by
software.

The third option is to run from ROM, in which case the vectors are there
at power up, and don't need to be initialized by the startup code.

In any case, I have to change the platform independent portion of the
ARM hal to suit my platform, right?  (he asked with a grin).  I've got
no problem with that,  I just wanted to make sure that I was headed in
the right direction before I started hacking on assembly language for
a processor I've only been playing with for a week.

I must say that the ARM load/store instructions are about the coolest
I've seen since the PDP-11.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] ARM vectors.S question

[Gary Thomas]

On 26-Oct-99 Grant Edwards wrote:
> 
> I'm in the process of getting eCOS to run on a Samsung SNDS eval board
> (ARM7TDMI core w/ a bunch of on-chip Samsung peripherals).  The file
> ecos-1.2.1/packages/hal/arm/arch/v1_2_1/src/vectors.S claims to be
> platform independent, yet it seems to make assumptions about the
> memory map that are platform-dependent.
> 
> For example, it assumes that there is RAM at address 0 so the
> startup code initializes the exception vectors that are at address 0.
> 
> After reset, the SNDS board has ROM at address 0, as will any embedded
> system (if I understand the processor startup sequence).  There are
> two ways to deal with this:
> 
>  1) The SNDS ROM vectors interrupts via a table of addresses that is
>     in RAM, so user code can install pointers to ISRs in RAM at a
>     particular address (0x13fffd0, FWIW).
> 
>  2) The memory configuration can be altered after startup to re-map RAM
>     to address 0 and ROM to somewhere else.
> 
> Either of these would require changes to "platform independent"
> sections of eCOS. 
> 
> Am I missing something?
> 

Not at all.  To date, we have assumed that the environment on ARM platforms
will have RAM at zero.  This is the most flexible and easiest setup for us.

However, as you note, there are some platforms that are not laid out this
way.  For the ones of these that we have already encountered, we chose
to implement solution (2) above.

There certainly will be some situations where only (1) will do.  If/when
that becomes the case, we'll have to adopt a "vectored" approach.

Does your hardware have a MMU or some other way to alter the memory layout?

[ECOS] ARM vectors.S question

[Grant Edwards]

I'm in the process of getting eCOS to run on a Samsung SNDS eval board
(ARM7TDMI core w/ a bunch of on-chip Samsung peripherals).  The file
ecos-1.2.1/packages/hal/arm/arch/v1_2_1/src/vectors.S claims to be
platform independent, yet it seems to make assumptions about the
memory map that are platform-dependent.

For example, it assumes that there is RAM at address 0 so the
startup code initializes the exception vectors that are at address 0.

After reset, the SNDS board has ROM at address 0, as will any embedded
system (if I understand the processor startup sequence).  There are
two ways to deal with this:

 1) The SNDS ROM vectors interrupts via a table of addresses that is
    in RAM, so user code can install pointers to ISRs in RAM at a
    particular address (0x13fffd0, FWIW).

 2) The memory configuration can be altered after startup to re-map RAM
    to address 0 and ROM to somewhere else.

Either of these would require changes to "platform independent"
sections of eCOS. 

Am I missing something?

-- 
Grant Edwards
grante@visi.com