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

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

[Gene Kozin]

The following bug has been found in SPARClite gdb from the
99-03-19 release of eCos tools (ecosSWtools-990319):

Description:
-----------
When connecting to Fujitsu SPARClite evaluation board, gdb
aborts with the following error message: "Magic number of
sparclite target struct wrong".

The said error message is emitted by the function
push_target() (target.c, line 523) if verification of the
target_ops structure fails.  The failure occurs when
function sparclite_open() calls push_target() with
&sparclite_ops as an argument (see sparcl-tdep.c, line 508).

This happens because initialization of the sparclite_ops
structure (see sparcl-tdep.c, line 836) is incorrect.
Particularly, initialization of the to_has_thread_control
field (see target.h, line 318) is missing.  As a result,
OPS_MAGIC (3840) ends up in the wrong field
(to_sections_end instead of to_magic), causing push_target()
to fail.

How to repeat:
--------------
1. Run sparclite-elf-gdb
2. Connect to the Fujitsu evaluation board:

        (gdb) target sparclite com2

3. gdb aborts with to following message:

        [SPARClite appears to be alive]
        Magic number of sparclite target struct wrong

How to fix:
-----------
To fix the problem, apply the following patch to
.../src/gdb/sparcl-tdep.c file:

-----< patch-start >----------------------
876d875
<   0,    /* to_has_thread_control */
-----< patch-end >------------------------

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

[Stan Shebs]

   From: "Gene Kozin" <gkozin@c-cube.com>
   Date: Thu, 8 Jul 1999 11:29:51 -0700

   The following bug has been found in SPARClite gdb from the
   99-03-19 release of eCos tools (ecosSWtools-990319):

Thanks for the patch!  We set up the target vectors in a different way
now (with assignments rather than struct init), so the patch is no
longer needed for GDB, but this is the right fix for older versions.

							Stan Shebs
							Cygnus Solutions
							shebs@cygnus.com

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

[Hugo Tyson]

(This message blind copied various places: be careful if replying)

In separate mail I said that we didn't support SPARClite eval boards with a
release of the tools called ecc-98r1 and that a later release called 99r1
should be used, because the eCos SPARClite support work is relatively
recent, and the fact that ecc98r1 "obviously" could not work.

I was wrong: ecc-98r1 ("or better") is the correct toolchain for the
SPARClite releases of eCos that are out there, and it works fine; the tools
in the sourceware site are fine, including the 99-03-19 release of eCos
tools (ecosSWtools-990319).

Now, that bug is genuine, and the patch is welcome, but it escaped our
strict testing regime because the "target sparclite" way of working - using
Fujitsu's own monitor ROM - is not supported by eCos.[1]

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.

	- Huge


[1] OK, you *can* use it to load-and-go, *if* your eCos app is configured
suitably, but you don't get debugging facilities or the ability to
interrupt the program or any other nice things... and we didn't test it.

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

[Gene Kozin]

----- Original Message -----
From: Hugo Tyson <hmt@cygnus.co.uk>
Sent: Friday, July 09, 1999 8:18 AM
Subject: [ECOS] Re: ecos/20273 [ECOS] Alert: SPARClite gdb bux (and fix)


>
> Now, that bug is genuine, and the patch is welcome, but it escaped our
> strict testing regime because the "target sparclite" way of working -
using
> Fujitsu's own monitor ROM - is not supported by eCos.[1]
>
> 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.  And since SygMon source
is not publicly available, the only way to boot eCos is with "target
sparclite..."

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.

Best Regards,

Gene Kozin
C-Cube Microsystems

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

[Hugo Tyson]

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