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

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

[Ian Gilmour]

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

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

[Bob Koninckx]

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

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

[Bob Koninckx]

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

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

[Bob Koninckx]

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

> 
> > -----Original Message-----
> > From: Ian Gilmour 
> > Sent: Friday, December 06, 2002 9:43 AM
> > To: 'Bob Koninckx'; Henning Baldersheim
> > Cc: ecos-discuss@sources.redhat.com
> > Subject: RE: [ECOS] MPC 555/565 Status
> > 
> > 
> > 
> > Hi,
> > 
> > On a similar thread. 
> > 
> > Is anyone working on an ECOS port to the Axiom CMD561 board?
> > 
> > Anyone know if the CME555 port will just run - as is?
> > 
> > Or what needs to be changed, if not?
> > 
> > 
> > cheers,
> > 
> > 
> > Ian
> > 
> > 
> > > -----Original Message-----
> > > From: Bob Koninckx [mailto:bob.koninckx@mech.kuleuven.ac.be]
> > > Sent: Friday, December 06, 2002 9:11 AM
> > > To: Henning Baldersheim
> > > Cc: ecos-discuss@sources.redhat.com
> > > Subject: Re: [ECOS] MPC 555/565 Status
> > > 
> > > 
> > > On Thu, 2002-12-05 at 16:22, Henning Baldersheim wrote:
> > > > Hi
> > > > 
> > > > I have been looking around for OS with MPC 555/565 support. 
> > > ECOS seem to 
> > > > have the basic stuff. I have downloaded and got it up and 
> > > running on my 
> > > > Phytec MPC555 card. So far so good. However I have a couple 
> > > of questions.
> > > > 
> > > > 1 - I find an ec555extras.epk file, but I get some errors. 
> > > > (xxx/ecos/packages/pkgadd.txt : missing) and 
> > > > (io/ioencoder/v0_1/include/encoderconfig_keys.h : 
> > > permission denied). How 
> > > 
> > > I do not know how to solve that. Never used the epk as I have the
> > > original code myself.
> > > 
> > > > do I solve that ? Is this soon to be added to cvs ? Is it 
> > > possible to 
> > > > ignore the errors so I can have a look at the code.
> > > 
> > > I do not think it will ever appear into cvs. If you do not manage to
> > > have a look at the code, I can send you a copy of what is missing.
> > > Basically it is a device driver for reading out incremental emcoders
> > > using the TPU devices.
> > > 
> > > > 2 - I see that both the ec555 and cme555 boards have 
> > > different serial 
> > > > drivers. Is that necessary ? Should there not be a 555/565 
> > > common package 
> > > > containing all those drivers.
> > > 
> > > That's something you could argue about. You could say that the
> > > integrated peripherals of the 555/565 processors are part of the
> > > processor architecture. You could also say that the cme555 and ec555
> > > boards use the same serial devices.
> > > 
> > > I am more in favor of this last approach since motorola 
> > > integrates lots
> > > of their peripherals into other processors as well.
> > > 
> > > Maybe the cleanest way to go would be to split the driver in 
> > > a "device"
> > > part and a "board part". Look at how the cs8900a ethernet controller
> > > (the device part) is used on multiple boards as a example.
> > > 
> > > I suppose Gary or Jifl can comment on this as well ?
> > > 
> > > 
> > > > 3 - I want to make a package for the phytec 555 and 565 
> > > cards. Should they 
> > > > be organized the same way as the ec and cme package ? I 
> > > would hope common 
> > > > stuff could go in a common place.
> > > 
> > > See my comment above. The cs8900a ethernet driver is probably 
> > > an example
> > > of the cleanest approach.
> > > 
> > > > 4 - From the previous mails I see that there might be a 
> > > patch coming soon. 
> > > > What is contained and when will it be available ?
> > > 
> > > That patch is ready. It does not change anything major, 
> > just some bug
> > > fixes for serial debugging (ctrl-c stuff) and some documentation. It
> > > however also contains redboot images for the ec555 and cme555 
> > > boards, so
> > > it became an email with a "big" attachment. That's the reason 
> > > why it did
> > > not appear on the patches-list. The eCos maintainers got it 
> > though. If
> > > you want, I can send you a copy as well. I can not guarantee that it
> > > will ever make it into the cvs tree though.
> > > 
> > > 
> > > I'll post the patch without the images to the patches list this WE.
> > > 
> > > > 
> > > > Henning 
> > > 
> > > 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
> > > 
> > ----------------------------------------------------------------------
> > > 
> > > 
> > > -- 
> > > Before posting, please read the FAQ: 
> > > http://sources.redhat.com/fom/ecos
> > > and search the list archive: 
> > http://sources.redhat.com/ml/ecos-discuss
> > > 
> > 
-- 
----------------------------------------------------------------------
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
----------------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

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

[Ian Gilmour]

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.

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

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?

I'm still slightly confused as to how you go about getting going with a port
to a new target board.

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? 
Would having access to the MS-Windows GUI tool make things simpler?

Thanks in advance for any tips.


cheers,


Ian 

> -----Original Message-----
> From: Ian Gilmour 
> Sent: Friday, December 06, 2002 9:43 AM
> To: 'Bob Koninckx'; Henning Baldersheim
> Cc: ecos-discuss@sources.redhat.com
> Subject: RE: [ECOS] MPC 555/565 Status
> 
> 
> 
> Hi,
> 
> On a similar thread. 
> 
> Is anyone working on an ECOS port to the Axiom CMD561 board?
> 
> Anyone know if the CME555 port will just run - as is?
> 
> Or what needs to be changed, if not?
> 
> 
> cheers,
> 
> 
> Ian
> 
> 
> > -----Original Message-----
> > From: Bob Koninckx [mailto:bob.koninckx@mech.kuleuven.ac.be]
> > Sent: Friday, December 06, 2002 9:11 AM
> > To: Henning Baldersheim
> > Cc: ecos-discuss@sources.redhat.com
> > Subject: Re: [ECOS] MPC 555/565 Status
> > 
> > 
> > On Thu, 2002-12-05 at 16:22, Henning Baldersheim wrote:
> > > Hi
> > > 
> > > I have been looking around for OS with MPC 555/565 support. 
> > ECOS seem to 
> > > have the basic stuff. I have downloaded and got it up and 
> > running on my 
> > > Phytec MPC555 card. So far so good. However I have a couple 
> > of questions.
> > > 
> > > 1 - I find an ec555extras.epk file, but I get some errors. 
> > > (xxx/ecos/packages/pkgadd.txt : missing) and 
> > > (io/ioencoder/v0_1/include/encoderconfig_keys.h : 
> > permission denied). How 
> > 
> > I do not know how to solve that. Never used the epk as I have the
> > original code myself.
> > 
> > > do I solve that ? Is this soon to be added to cvs ? Is it 
> > possible to 
> > > ignore the errors so I can have a look at the code.
> > 
> > I do not think it will ever appear into cvs. If you do not manage to
> > have a look at the code, I can send you a copy of what is missing.
> > Basically it is a device driver for reading out incremental emcoders
> > using the TPU devices.
> > 
> > > 2 - I see that both the ec555 and cme555 boards have 
> > different serial 
> > > drivers. Is that necessary ? Should there not be a 555/565 
> > common package 
> > > containing all those drivers.
> > 
> > That's something you could argue about. You could say that the
> > integrated peripherals of the 555/565 processors are part of the
> > processor architecture. You could also say that the cme555 and ec555
> > boards use the same serial devices.
> > 
> > I am more in favor of this last approach since motorola 
> > integrates lots
> > of their peripherals into other processors as well.
> > 
> > Maybe the cleanest way to go would be to split the driver in 
> > a "device"
> > part and a "board part". Look at how the cs8900a ethernet controller
> > (the device part) is used on multiple boards as a example.
> > 
> > I suppose Gary or Jifl can comment on this as well ?
> > 
> > 
> > > 3 - I want to make a package for the phytec 555 and 565 
> > cards. Should they 
> > > be organized the same way as the ec and cme package ? I 
> > would hope common 
> > > stuff could go in a common place.
> > 
> > See my comment above. The cs8900a ethernet driver is probably 
> > an example
> > of the cleanest approach.
> > 
> > > 4 - From the previous mails I see that there might be a 
> > patch coming soon. 
> > > What is contained and when will it be available ?
> > 
> > That patch is ready. It does not change anything major, 
> just some bug
> > fixes for serial debugging (ctrl-c stuff) and some documentation. It
> > however also contains redboot images for the ec555 and cme555 
> > boards, so
> > it became an email with a "big" attachment. That's the reason 
> > why it did
> > not appear on the patches-list. The eCos maintainers got it 
> though. If
> > you want, I can send you a copy as well. I can not guarantee that it
> > will ever make it into the cvs tree though.
> > 
> > 
> > I'll post the patch without the images to the patches list this WE.
> > 
> > > 
> > > Henning 
> > 
> > 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
> > 
> ----------------------------------------------------------------------
> > 
> > 
> > -- 
> > Before posting, please read the FAQ: 
> > http://sources.redhat.com/fom/ecos
> > and search the list archive: 
> http://sources.redhat.com/ml/ecos-discuss
> > 
> 

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss