[ECOS] Problem with ECOS vectors.o code

[ECOS] Problem with ECOS vectors.o code

[Brenda Spaur]

I'm porting ECOS to a board based on the MPC850.  I can now
compile and run simple test programs built using the ECOS software 
tools.  I'm running into problems though if I try to use the startup 
code defined in vectors.[So].  The target.ld linker script defines the 
program start entry as reset_vector.  I looked at this code and it appears
to simply branch to _start which actually does the set up.  If
I remove the STARTUP(vectors.o) and ENTRY(reset_vector) from the
linker script then my test code runs fine (but then of course I'm not 
actually initializing or linking in any of the ECOS code).  If I use 
reset_vector as the start entry though, my program never returns.

It is not clear if the problem is in the _start code or in the
reset_vector code itself (or both) ... or perhaps even in defining
a different start entry.  A couple of things I've tried:

- I copied vectors.S and removed all code except the reset_vector code, 
  as in:
        .globl  reset_vector
      reset_vector:
        lwi     r3,_start
        mtlr    r3
        blr
  I first tried defining an _start that simply called main.  I also tried
  changing the lwi opcode above to "lwi r3,main".  Neither one of these
  allowed my main program to be called.  The main program simply
  sets a status register and returns (and works fine if reset_vector
  is not called).
- I tried using the vectors.o that was built when I built ecos-1.1 and 
  instead of defining reset_vector as the start entry using ENTRY(_start).  
  The test program built with this change in the linker script also does not 
  return.

Any ideas what is going on or what to try?

Thanks,
Brenda Spaur
brenda@FieldHand.com

Re: [ECOS] Problem with ECOS vectors.o code

[Jesper Skov]

You may want to consider some of the following suggestions:

1) the reset_vector routine resides in the .vectors section which has
   to be placed at a specific location in memory. I do not know
   exactly how the 850 differs from the 860 (the relevant manuals have
   now been ordered). The linker script controls such details, and
   it is possible to use tools like powerpc-eabi-objdump to make
   sure that the linker output is actually appropriate for your board.

   This would not explain all of the problems. _start is in the .text
   section, just like main(), so if it is possible to have main() as
   the entry point then _start should work as well. 

2) _start performs some hardware initializations, and the 850 may well
   need some slightly different code there. In particular, is
   the code still being compiled with CYG_HAL_POWERPC_MPC860?

   A useful experiment would be to call main() from the beginning of
   _start (especially after making that the entry point). If that
   works then it is possible to move the call to _main() around inside
   the startup code and figure out what part of this code is causing
   the problem on your hardware.

3) you do not say how you are booting the application into the board.
   If you are using some sort of ROM monitor then it is possible that
   the processor is in user mode when control gets transferred to the
   application. eCos expects to start up in supervisor state.

Bart & Jesper