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

[Bob Koninckx <bob dot koninckx at mech dot kuleuven dot ac dot be>]

On Fri, 2003-01-10 at 11:11, Ian Gilmour wrote:
> 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


This could be it! Seems that there is a conflict making a ram-based
monitor which is resolved by removing the monitor. I'd dig into this
deeper and find out what's going on here.


>    /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?

I don't think so.

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

You could always replace the stubs startup code (at cyg_user_start or
cyg_start) with something of your own ...

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

That's also strange. If it is really RAM startup, I would expect it at
0x800000 (look at vectors.S)

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

That was a long time ago. If I find the time this WE, but I am trying to
buy a house, so I really don't make any promises here :-), I'll try to
make one for ec555 and tell you how I did it once it succeeds. Notice
however that I definitely _never_ build only stubs, but always redboot.
That, for sure, has been running out of RAM

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

Bob

> 
> 
> Ian
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven       
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------