Re: [ECOS] Alert: SPARClite gdb bux (and fix)

[Hugo Tyson <hmt@cygnus.co.uk>]

> From: "Gene Kozin" <gkozin@c-cube.com>

> > From: Hugo Tyson <hmt@cygnus.co.uk>

> > Use the CygMon image provided with the release and talk to it using
> > "target remote ..." (which does support network as well as serial
> > comms) and all will be well.  That's what we tested.
> 
> This _would_ be nice.  Unfortunately, the CygMon image you provide only
> works with Fujitsu SPARClite engineering board, which is not available
> commercially (at least not in the U.S.).  The SPARClite evaluation kit
> available from Fujitsu (http://www.fujitsumicro.com/pdf/831ek.pdf),
> although similar, doesn't have ethernet port and what's worse, has
> different serial controller and timer chips.

That's a great pity.  When choosing how to use the features of the boards
we had, we used the 86940 companion as much as possible, because Fujitsu's
documentation implies that the 86940 is *the* way to get a standard set of
peripherals with a SPARClite.  And now they ship (only!) a dev board
without it!

> Now, don't get me wrong.  So far I like eCos very much!  My only
> humble suggestion would be to use commercially available boards for
> your future ports to make it possible to evaluate eCos on the real
> hardware.

A very valid point, and it has left our distribution looking, um, less
useful than it might be... unfortunately this was one of these "who pays
the piper" situations.

For now, all I can do to help is point you to the section of the SPARClite
configuration file hal_sparclite_sleb.h, which controls how the HAL "plays
nice" with CygMon (if running in that environment).  I've copied the
relevant section at the end of this message.  Disabling the #define of
CYG_HAL_USE_ROM_MONITOR_CYGMON ensures that eCos (a) takes over *all* the
trap vectors, and (b) writes diagnostic output directly, rather than using
vectored calls into the ROM.

HTH,
	- Huge

/* -------------------------------------------------------------------*/
// The following are NOT config options for now: support for the native
// Fujitsu ROMs is not a requirement, just a handy thing to have:

#ifdef CYG_HAL_STARTUP_RAM
// then there is a ROM Monitor of some sort:

// CYG_HAL_USE_ROM_MONITOR_CYGMON:
// This is defined by default to allow interworking with CygMon and thus
// GDB so that Breakpoints and ^C interrupts and the like work.
//
// Undefine it if building to run with the native Fujitsu boot proms (NOT
// CYGMON) ie. a "load-and-go" type startup by means of 
//      (gdb) target sparclite udp sleb0
// or
//      (gdb) target sparclite serial /dev/ttyS0
// as opposed to the CygMon way:
//      (gdb) set remotebaud 19200
//      (gdb) target remote /dev/ttyS0
//
// Such builds will load-and-go when using CygMon, but load-and-go is all
// the interaction you get.

#define CYG_HAL_USE_ROM_MONITOR_CYGMON

// If using CygMon it's generally helpful to wrap output characters in the
// GDB protocol as $O packets; CYG_KERNEL_DIAG_GDB enables this by means of
// calling into CygMon through the vectors provided; this therefore also
// works with eg. ethernet debugging.
// 
// Disable CYG_KERNEL_DIAG_GDB and output goes direct, in clear, to
// serial port 0 (CON1).

#ifdef CYG_HAL_USE_ROM_MONITOR_CYGMON
#define CYG_KERNEL_DIAG_GDB
#endif

// However, you might want to force GDB-encoded output to the serial port
// NOT using CygMon to perform the formatting; this is really only here as
// a debugging option, in case GDB is behaving oddly.  Define
// CYG_KERNEL_DIAG_GDB_SERIAL_DIRECT + CYG_KERNEL_DIAG_GDB to make GDB $O
// packets come out the serial port (CON1)

#ifdef CYG_KERNEL_DIAG_GDB
#undef CYG_KERNEL_DIAG_GDB_SERIAL_DIRECT
#endif


#endif // CYG_HAL_STARTUP_RAM

/* -------------------------------------------------------------------*/
#endif  /* CYGONCE_PKGCONF_HAL_SPARCLITE_SIM_H */
/* EOF hal_sparclite_sim.h */