BDI2000 vs RiskWatch

BDI2000 vs RiskWatch

[Felix Radensky]

Hi,

I have to convince our bosses to purchase BDI2000 for linux kernel
debugging.
Can someone please explain what BDI2000 can do that RiskWatch cannot.

Thanks a lot.

Felix.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: BDI2000 vs RiskWatch

[Wolfgang Denk]

In message <3B8212A6.9AF31020@allot.com> you wrote:
>
> I have to convince our bosses to purchase BDI2000 for linux kernel
> debugging.
> Can someone please explain what BDI2000 can do that RiskWatch cannot.

Just one question: does RiskWatch support the MMU?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"'Tis true, 'tis pity, and pity 'tis 'tis true."
- Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: BDI2000 vs RiskWatch

[Felix Radensky]

Wolfgang Denk wrote:

> In message <3B8212A6.9AF31020@allot.com> you wrote:
> >
> > I have to convince our bosses to purchase BDI2000 for linux kernel
> > debugging.
> > Can someone please explain what BDI2000 can do that RiskWatch cannot.
>
> Just one question: does RiskWatch support the MMU?
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> "'Tis true, 'tis pity, and pity 'tis 'tis true."
> - Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_

It seems so. This is what I've found in RISCWatch user manual:

RISCWatch support for MMU on the 400Series processors is subject to
adherence to the following conditions:

1. The translation mode for Data and Instruction access must be the same.
     They can both be enabled or disabled; having only one enabled is not
supported.

2. If the program execution is stopped at a point where the translation
mode has
     changed from the state existing upon initial load, then the mapping
must be
     real=virtual. If this is not the case, the source level debug
information for the
     stopped context will not be displayed correctly.

3. The real addresses in the TLB entries are assumed to be correct and
valid addresses.

Please excuse my ignorance: I assume that MMU support in debugger is
required to access
kernel virtual addresses. Is that correct ? Also what does this excerpt
from RISCWatch
manual tell you ? How can these RISCWatch "features" influence kernel
debugging.

Thanks a lot.

Felix.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: BDI2000 vs RiskWatch

[Scott Anderson]

Felix Radensky wrote:
> Can someone please explain what BDI2000 can do that RiskWatch cannot.

To me, the main thing is that it integrates well with a Linux
development box.  I use my normal debug tools (ddd/gdb) and the BDI2000
acts like a gdbserver for the kernel.  For things such as FLASHing code
into the target, you just telnet into the BDI2000.

Bottom line: If you are developing on Windows, the RiscWatch is probably
what you want.  If you are developing on Linux (which I hope is the
case), you want a BDI2000.  Otherwise, you're going to need a Windows
box for RiscWatch to run on and then you'll have to set up Samba or some
other mechanism for the Windows box/RiscWatch to see your sources, etc.

    Scott Anderson
    scott_anderson@mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: BDI2000 vs RiskWatch

[Kenneth Johansson]

Scott Anderson wrote:
>
> Felix Radensky wrote:
> > Can someone please explain what BDI2000 can do that RiskWatch cannot.

> Bottom line: If you are developing on Windows, the RiscWatch is probably
> what you want.  If you are developing on Linux (which I hope is the
> case), you want a BDI2000.  Otherwise, you're going to need a Windows
> box for RiscWatch to run on and then you'll have to set up Samba or some
> other mechanism for the Windows box/RiscWatch to see your sources, etc.

No the RiscWatch is as useless in wondows as it's under unix.

To be fair RiscWatch is not one product but two separate entites. The
hardware part is marked IBM RiscWatch but is in fact a box from hp(agilent).
To control this hardware you just have to telnet into it.

The software part is the one that sucks and I REALLY mean that. I had a hell
trying to get this to work. To begin with the software can't be used on any
Xdisplay that uses 16 bith depth it just crash. This is not entierly easy to
figure out when all displays is running in this mode and the IBM people don't
know about this problem. Solution run in 8 bit :(

Then is came a bit longer but hang when it was trying to flash the hp box
with software for the version of cpu I was using. Several visit's by IBM
people could not solv this problem so they gave me a box on loan that had the
right software already inside.

Now I could run commands like reset and singelstep but the run command
resulted in the software hanging again but the target cpu was at least
running. So I could set up registers and stuff and do one run. Not very
usefull mode :(

Then came summer time (daylight saving time) and now without me doing
anything it worked more or less as intened ?????  But only if run from
solaris 2.7 not from solaris 2.6 ?

Then it seems to have a life on it's own. The "reset system" command has
always done a complete reset and the cpu has started as normal from
flash/rom. But a few weeks ago it nolonger can start from ROM as for some
reason a reset system fails to put valid entry into chip select 0 registers
making an access to fffffffc invalid :(

Well my recomendations is to stay far away from this software. The hardware
part is probably ok and you can buy just the hardware but as it needs to be
programmed to the target cpu you use and that is in the software package in
practice you need both.

It is probably quite easy to interface the hardware with gdb but you need to
snoop what RiscWatch dose as the help for the telnet interface in the hp box
is to little to be usefull.

I have not used BDI2000 so I can't really say anything about it but my
recomendation is anything BUT RiscWatch.

--
Kenneth Johansson
Ericsson Business Innovation AB   Tel: +46 8 404 71 83
Viderögatan 3                     Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@inn.ericsson.se

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: BDI2000 vs RiskWatch

[Wright, David]

IBM only supplies programs to run the RISCWatch on Windows,
RS/6000, and Sun (no Linux).  As an alternative to buying a
separate box, you can also run the Windows version of the
software under VMware on Linux.  You still have the "access
to sources" problem, though.

  -- David Wright, InfiniSwitch Corp.



> -----Original Message-----
> From: Scott Anderson [mailto:scott_anderson@mvista.com]

> Felix Radensky wrote:
> > Can someone please explain what BDI2000 can do that
> > RiskWatch cannot.
>
> To me, the main thing is that it integrates well with a Linux
> development box.  I use my normal debug tools (ddd/gdb) and
> the BDI2000
> acts like a gdbserver for the kernel.  For things such as
> FLASHing code into the target, you just telnet into the BDI2000.
>
> Bottom line: If you are developing on Windows, the RiscWatch
> is probably
> what you want.  If you are developing on Linux (which I hope is the
> case), you want a BDI2000.  Otherwise, you're going to need a Windows
> box for RiscWatch to run on and then you'll have to set up
> Samba or some
> other mechanism for the Windows box/RiscWatch to see your
> sources, etc.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/