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 Thu, 2003-01-09 at 11:38, Ian Gilmour wrote:
> Bob,

Hi Ian,

> 
> After a long Christmas break I'm back on the case, trying to get my
> Axiom-CMD561 board up a running with ECOS.
> 
> Thanks for your response to my earlier e-mail.

You're wellcome :-) Please always copy the list. The more people know
about your problems, the better your chances are to get them solved
quickly.

> 
> Assuming I get it working - I'll certainly be trying to get anything I do
> contributed back in to the ECOS archive.
> 
> 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 affraid you'll have
to create a new variant (mpc6xx ??) which will involve more work.

>  and changed the initialisation to be similar to
> that used in the Axiom monitor (so chip selects and wait states, etc. should
> be correct).

That's the first thing to check ! Check it again. If you're not able to
access memory, things obviously wont work.

> 
> I'm trying to follow the porting guide but I'm not having much success in
> getting it working to date.
> 
> I have managed to get a powerpc-eabi-gcc compiled version of the hello.c
> file they ship with the board working on the board so I'm reasonably happy
> that the powerpc-eabi-xxx toolset itself works as required.

Looks like it.

> 
> But when I try to compile a RAM version of the GDB stub it builds fine,

That's already good !

>  but
> doesn't run and I'm at a loss to work out where it's going wrong at present.
> 
> The stages I'm going through are as per
> http://sources.redhat.com/ecos/docs-latest/porting/hal-plf-process.html.
> 
> I'm disabling CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT,
> CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT, and CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
> by uncommenting the user_default value in ecos.ecc and setting the
> user_value to 0, which I think is what's required? And I've changed the
> default baud rates defined in ecos.ecc to 9600 for now - since that's the
> baud rate used by the Axiom monitor (do I need to reflect this change
> elsewhere as well?).

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.

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

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

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

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

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

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.


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.
* Check the memory map
everything I wrote expects

Internal flash at 0x00000000
Internal Ram   at 0x003f9800
External Flash at 0x00400000


Bob

> 
> 
> Thanks in advance,
> 
> 
> Ian
> 
> 
> > -----Original Message-----
> > From: Bob Koninckx [mailto:bob.koninckx@mech.kuleuven.ac.be]
> > Sent: Wednesday, December 18, 2002 3:54 PM
> > To: Ian Gilmour
> > Cc: 'ecos-discuss@sources.redhat.com'
> > Subject: Re: [ECOS] Axiom CMD561 (was - RE: [ECOS] MPC 555/565 Status)
> > 
> > 
> > On Wed, 2002-12-18 at 13:25, Ian Gilmour wrote:
> > > OK my Axiom CMD561 just turned up. And no-one replied to my 
> > initial email -
> > > so I'm assuming I need to perform the port myself.
> > 
> > Don't forget to, if possible, contribute it back ;-)
> > 
> > > 
> > > Looking at the CME555 description it looks as though I'm 
> > going to have to
> > > massage the existing CME555 port to get it working on a 
> > CMD561 (For one, the
> > > CMD561 doesn't have the internal flash, which the CME555 
> > port appears to
> > > use).
> > 
> > The cme555 port does not really "use" the internal flash. I 
> > just linked
> > the ROM version of redboot to addresses of the internal flash and
> > internal ram. All of the external RAM and and flash remains 
> > available to
> > applications. This is however not imperative. All you should do is
> > change the memory map according to your board. Also look for options
> > that enable / disable internal flash or dual map it to somewhere else.
> > 
> > > 
> > > As I don't yet have a BDM debugger any tips on how to go 
> > about getting
> > > started with this in the mean time would be much appreciated?
> > 
> > Depends on which BDM you want to use and which OS you're going to use
> > for your development. I used a "wiggler" from Macraigor which 
> > turned out
> > to be completely incompatible with Linux. So we ended up 
> > writing our own
> > gateway (running on a windows PC) between GDB-remote protocol and the
> > wiggler. Unfortunately, I can not release this tool, sorry.
> > 
> > Macraigor has BDM interfaces that are claimed to be linux 
> > compatible. I
> > never tried them, so I am not able to comment on them. I also 
> > heard very
> > positive things about Abatron. Again, others on this list are probably
> > better placed to comment on them.
> > 
> > If you look on the patches list, I recently posted some changes that
> > make serial debugging 100% operational. Ctrl-C, thread listings etc. I
> > used it for a while now, and apart from beeing slower than BDM, i did
> > not notice any errors.
> > 
> > > 
> > > I'm still slightly confused as to how you go about getting 
> > going with a port
> > > to a new target board.
> > 
> > There is a porting guide.
> > 
> > > 
> > > Once I've got the appropriate cmd561 directories setup and 
> > populated in my
> > > ECOS_REPOSITORY and I've updated ecos.db, should,
> > > 
> > >    ecosconfig new cmd561 redboot 
> > >    ecosconfig tree
> > >    make
> > > 
> > > give me a simple ROM-based monitor? 
> > > Do I need to massage the ecos.ecc file before generating 
> > the tree and
> > > performing the make? 
> > > Or should I be specifying some other (more basic) 
> > configuration initially?
> > > 
> > > i.e. What's the minimum config that gives my something out 
> > on the serial
> > > port to prove it's working?
> > > 
> > > Host M/C - Linux (so I've got configtool if required).
> > > PS. Anyone else finding configtool crashes fairly regularily? 
> > 
> > Never seen that happen.
> > 
> > > Would having access to the MS-Windows GUI tool make things simpler?
> > > 
> > > Thanks in advance for any tips.
> > > 
> > > 
> > > cheers,
> > > 
> > > 
> > > Ian 
> > 
> > Regards,
> > Bob
> > 
-- 
----------------------------------------------------------------------
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
----------------------------------------------------------------------