Re: [ECOS] Re: gcc/gdb for mpc860

Re: [ECOS] Re: gcc/gdb for mpc860

[Kenneth Porter]

On Thu, 27 Jan 2000 14:07:03 GMT, Bart Veer wrote:

> However gdb needs to
> interact directly with the hardware. This may involve talking with
> some sort of ROM monitor via a serial line, or it may involve special
> debugging hardware such as JTAG, or whatever.

Has anyone successfully gotten gdb to talk to the MPC823FADS? Or gotten
anything to load at all? The Motorola MPC8BUG program provides a
gdbserver, and this sorta works with powerpc-eabi-gdb (under NT4SP3),
but I've yet to run a program successfully. I'm wondering if I'm
fighting differences between the MPC860 and the MPC823? I just want to
get something very basic to run. I tried loading Mot's example
"mmu_lite" using just MPC8BUG and that gets stuck in a memory test fail
condition. However, it uses an "mpc821.h" header which doesn't match
the peripheral layout of the 823 (there's a separately-available
mpc823.h at Mot's site), so perhaps I just have to study the cache and
MMU configuration with a fine-tooth comb to see if there's a difference
that's biting me. I'm pretty sure the hardware is healthy as I can run
the MPC8BUG self tests which test both the debug hardware and memory on
the target.

If anyone's ever run even something very trivial on this platform,
please let me know the trick to make it work.

Kenneth Porter
Kensington Laboratories, Inc.
mailto:kenneth_porter@kensingtonlabs.com
http://www.kensingtonlabs.com

Re: [ECOS] Re: gcc/gdb for mpc860

[Kenneth Porter]

On Thu, 27 Jan 2000 20:09:39 -0800, Fred Fierling wrote:

> Sorry can't help you.  You're doing better than I.  I can't even get the
> ADI control panel to show up in settings/control panel under NT4/SP5. Did
> you have any trouble?

I did get that far. I think the system I'm using is at SP4.

You need to put the files from the MPC8BUG drivers subdirectory into
the places designated by the readme file. One (.sys) is the actual
driver and one (.cpl) is the Control Panel DLL. There's also a registry
file (.reg) that you run from the command line as if it were an
executable to patch the registry and inform the OS of the other two
files.

Use WinMSD to check for any I/O port conflicts,  then jumper as
appropriate and install the ADI board. Following a reboot, you should
have the ADI object. Select the matching address in the first (zero)
entry and enable it. Set the address switches on the FADS board to
zero, and you should be able to start up MPC8BUG with "mpc8bug 0 0". It
will auto-detect the CPU type and run the appropriate TCL scripts.

Once you get that far, run the "diag" command and within diag mode, run
the "st" (self test) command. This checks the ADI and FADS board and
runs several memory tests on the SIMMs. My system is completing this
successfully, and is able to run the Mot mmu_lite sample up to a memory
test failure routine.

There's a couple of issues relevant to eCos here:

MPC8BUG uses Cygwin b19, not b20. The b19 DLL shipped by Motorola
crashed for me, so I downloaded b19.1 from the Cygnus Cygwin
directories and that cured that

Also, the TCL DLL shipped with MPC8BUG doesn't match that of the one in
Cygwin b20, but has the same name. I don't know if that's going to
cause problems, because AFAIK only one DLL with a given name can be
loaded at a time in Win32. (That was the rule with OS/2, and I assume
NT inherited it. It's a performance optimization so that the kernel
only has to do an 8.3 compare in the loaded DLL list, and doesn't have
to compare the full path.) The first one loaded gets priority, so if
one runs both MPC8BUG and a Cygwinb20 TCL client simultaneously, one
app is going to get the "wrong" DLL.

Kenneth Porter
Kensington Laboratories, Inc.
mailto:kenneth_porter@kensingtonlabs.com
http://www.kensingtonlabs.com

[ECOS] Re: gcc/gdb for mpc860

[Bart Veer]

>>>>> "Michael" == Crowe, Michael E <michael.e.crowe@lmco.com> writes:

    Michael> I realize this is not the proper group for this question
    Michael> but I have had no luck with the people in the
    Michael> gnu.gcc.help newsgroup, and everyone here seems more
    Michael> knowledgable anyway. I'm trying to port gcc and gdb
    Michael> (along with binutils and newlib) to target the MPC860 on
    Michael> a PLX Board. The board should not matter (should it??), I
    Michael> beleive that it is solely processor dependant. My host is
    Michael> Redhat Linux 6.0 with the gcc compiler. SO, has anyone
    Michael> successfully built a cross-compiler under linux that
    Michael> targets the mpc860. I am trying to port eCos to this
    Michael> board, but without a compiler, it's VERY difficult :-)

For the compiler side things are pretty easy. The best place to start
right now is with the complete toolchain sources you can download from
http://sourceware.cygnus.com/ecos/getstart.html , following the
"Installing eCos under Linux" link. Download
ecosSWtools-990319-src.tar.bz2 and then just follow the instructions,
selecting powerpc-eabi as your target triplet. You should end up with
a complete functional toolchain.

Please note that these are not the very latest versions of the tools,
but they should be adequate for the time being. It is possible to
build a working toolchain by combining the latest release of gcc, a
recent snapshot of binutils (the last official release was quite some
time ago and did not have certain functionality required by eCos), and
so on. All of these are available by visiting
http://sourceware.cygnus.com .

gdb is more complicated. The compiler, assembler, linker etc. have no
specific dependencies on the target board: issues such as memory
layout are handled at link-time by providing a suitable linker script,
which is part of the eCos porting process. However gdb needs to
interact directly with the hardware. This may involve talking with
some sort of ROM monitor via a serial line, or it may involve special
debugging hardware such as JTAG, or whatever. If a serial line/ROM
monitor combination is used then there may be further problems,
because different ROM monitors use different protocols and gdb may not
know the protocol for your particular one. Within Red Hat, to make our
life easier we generally replace any existing ROM monitor with our own
gdb stubs. That way we know what is going on and we can implement
additional functionality such as thread-aware debugging.

There is documentation available on the gdb internals, which you will
find in the gdb sources. If you are running on Linux then you may have
the info pages already installed.

Bart Veer // eCos net maintainer