Re: [ECOS] ARM vectors.S question

[Hugo Tyson <hmt@cygnus.co.uk>]

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