RE: [ECOS] Axiom CMD561 (was - RE: [ECOS] MPC 555/565 Status)

[Ian Gilmour <ian dot gilmour at ffei dot co dot uk>]

Bob,

Thanks again for the prompt reply.

> -----Original Message-----
> From: Bob Koninckx [mailto:bob.koninckx@mech.kuleuven.ac.be]
> Sent: Thursday, January 09, 2003 2:40 PM
> To: Ian Gilmour
> Cc: ecos-discuss@sources.redhat.com
> Subject: RE: [ECOS] Axiom CMD561 (was - RE: [ECOS] MPC 555/565 Status)
> 
> Please always copy the list. The more people know
> about your problems, the better your chances are to get them solved
> quickly.

Will do.

> > 
> > I've disabled the internal flash and dual mapping of the 
> internal flash (in
> > hal_powerpc_mpc_5xx.cdl),
> 
> I don't follow ? You should not be changing anything in the cdl files.
> Just disable the option for your build. Also check that the effect is
> correct for the mpc561 (variant.inc). If not, I am afraid you'll have
> to create a new variant (mpc6xx ??) which will involve more work.
> 

OK. I've gone back to the original hal_powerpc_mpc_5xx.cdl file and now
disabled the same options in my ecos.ecc file (user_value set to 0).

Specifically I'm now doing the following,

   /home/iag/work/ecos/gdb_stub>ecosconfig new cmd561 stubs
   U CYGPKG_HAL_POWERPC_MPC555, new inferred value 1
   U CYG_HAL_STARTUP, new inferred value ROM
   U CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1
   /home/iag/work/ecos/gdb_stub>ecosconfig remove CYGPKG_IO
   /home/iag/work/ecos/gdb_stub>ecosconfig remove CYGPKG_IO_SERIAL
   /home/iag/work/ecos/gdb_stub>ecosconfig remove CYGPKG_ERROR

   --- edit ecos.ecc in here to disable internal flash and dual  ---
   --- mapping, together with setting CYG_HAL_STARTUP to "RAM"   ---
   --- and setting to 0 CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT,      ---
   --- CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT, and                   ---
   --- CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT. I also changed any   ---
   --- user defined baud rates to 9600 rather than 38400 since   ---
   --- this is what the Axiom monitor uses. Then....             ---

   /home/iag/work/ecos/gdb_stub>ecosconfig check
   Target: cmd561
   Template: stubs
   Removed:
    CYGPKG_IO
    CYGPKG_IO_SERIAL
    CYGPKG_ERROR
   1 conflict(s):
   C CYGSEM_HAL_ROM_MONITOR, "requires" constraint not satisfied:
CYG_HAL_STARTUP == "ROM" 
   /home/iag/work/ecos/gdb_stub>ecosconfig resolve
   U CYGSEM_HAL_ROM_MONITOR, new inferred value 0
   /home/iag/work/ecos/gdb_stub>ecosconfig check
   Target: cmd561
   Template: stubs
   Removed:
    CYGPKG_IO
    CYGPKG_IO_SERIAL
    CYGPKG_ERROR
   No conflicts
   /home/iag/work/ecos/gdb_stub>ecosconfig tree
   make

and this gives me a gdb_module.img file that I'm converting to S3-records
and downloading.

Step 7 of
http://sources.redhat.com/ecos/docs-latest/porting/hal-plf-process.html
talks of implementing a simple serial driver and making sure the
initialisation function properly hooks the procedures up in the virtual
vector IO channel tables. I'm currently not doing this. I'm assuming
(perhaps wrongly, that this is done for me in carrying out the steps
described above). hal_diag.c is being compiled in to the target and I
assumed this provided the polled i/o routines - correct?

> 
> Did you apply the patch I posted on the patches list about a 
> month ago ?
> I did some rework in this area. But then again, I do not 
> think this will
> solve your problems as it only contains fixes to have these things
> working if you enable the options.
> 

I haven't applied the patch - but I am using a Jan 6 cvs snapshot. Should
your patch be included in that?

> Do you see _anything_ coming out ? If you see complete 
> rubbish, it could
> be that the values for programming the baudrate are different on your
> board than on mine. Check hal_diag.c
> 

Nope nothing appears. The Axiom monitor runs at 9600 baud and I'm using this
to jump to the downloaded RAM stub. Is there a simply way of getting the
stub to repeat the string once it's been started? Then I can try changing
baud rates, etc. after the stubs running and see if anything appears.

> > 
> > I'm converting the gdb-module.img to S3-records (S2 records 
> aren't supported
> > by the Axiom monitor - that cost me 1/2 a day to discover!)
> 
> And if its the same monitor they ship with the cme555, make sure that
> Srecords do not contain more than 16 (if I remember well) data bytes.
> Older versions of the binary tools did this and the axiom 
> monitor chokes
> on it.

I doubt this is the problem - I'm using the same process I used to generate
the simple powerpc-eabi-gcc version of the Axiom 'hello world' program and
that downloads and runs successfully so I don't think I have a problem here.

> >  and downloading
> > it into RAM using the Axiom monitor on the board and the 
> AxIDE supplied on
> > the CD. It downloads ok. But when I run it I don't see the expected
> > $T0540:fff05cd8;01:00004664;#92 string.
> 
> Do you have any BDM debugger at your disposal ? That's certainly the
> easyest way to trace what's going on. At what addresses did 
> you link it

Unfortunately I don't currently have a BDM debugger. I can see how one might
be useful :-)

> ? What address did you jump to from the monitor ? Generate a 
> memory map
> and make sure that the symbol __exception_reset is at a valid ram
> address and that you jump to there from the monitor.

__exception_reset is located at 800100 and that's the address I'm jumping
to.

> 
> > 
> > If I've configured everything correctly can you confirm 
> that this should
> > this work as advertised?
> 
> Hard to say, I don't have your hardware.
> 

Fair enough. But have you ever use the above steps (replacing CMD561 with
CME555 obviously) to generate a RAM gdb stub for a CME555 board? Did it
work? If not can you give me a sequence of steps that definitely do produce
something that executes correctly on a CME555 and I'll try repeating those
for my board. This would at least give me a sequence of steps that "should"
work if I've made the correct changes.

I don't currently have confidence that the steps I'm carrying out should
produce something that works, even if I've made all the correct porting
changes. 

> > 
> > Is there an alternative test that has more chance of succeeding?
> > 
> > Is there any other documentation that describes the process 
> of bringing up a
> > board better. I assume my aim is to get Redboot into the 
> external flash on
> > the board and that then gives me the ability to download and debug
> > application code on the board using gdb/insight - correct?
> > 
> > Any recommendations would be much appreciated.
> 
> I suppose either something is wrong with your board initialization, or
> your memory map is not OK. 
> 

For a RAM target what board initialisation is being performed by the stub?
Doesn't it just use the Axiom monitor initialisation?

> Since you have have the axiom monitor running, I would try to remove
> everything that has to do with board initialization from the 
> build. The
> monitor initialized the board already. Once things start 
> working you can
> add them again later.
 
I'll try looking into this - thanks.

> 
> Things to check
> 
> * CYGARC_REG_IMM_BASE is defined as0x2fc000 on the mpc5xx. 
> Maybe this is
> different on the mpc561 in which case the macro belongs to board
> specific files rather than to the variant ones. If this value is not
> correct, nothing will work.

It's the same address on the MPC561.

> * Check the memory map
> everything I wrote expects
> 
> Internal flash at 0x00000000
> Internal Ram   at 0x003f9800
> External Flash at 0x00400000
>  

I'm currently building with a memory map of,
  Internal Ram   at 0x003f9800
  External Ram   at 0x00800000
  External Flash at 0x00c00000
  
(and locating everything starting at 800000) since that's what the Axiom
monitor configures on powerup (the MPC561 has no internal flash).

Again, thanks for your patience and for any more pointers you can give me.


cheers,


Ian