Re: [ECOS] ARM vectors.S question

[Gary Thomas <gthomas@cygnus.co.uk>]

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.