Re: [ECOS] ARM vectors.S question

[Gary Thomas <gthomas at cygnus dot co dot uk>]

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