Abatron BDI2000

Abatron BDI2000

[Brian Kuschak]

Is anyone out there using the Abatron BDI2000 to set hardware breakpoints on
data access (on 405GP)? I'm probably just doing something dumb, but I don't
see it. Any ideas?

Thanks,

Brian

BDI>bd w 0xc019c390
# syntax is BDx [R|W]
BDI>bdx w 0xc019c390
# syntax error in command
BDI>bd w c019c390
# syntax error in command
BDI>bd 0xc019c390
# syntax is BDx [R|W]
BDI>BD W 0xc019c390
# syntax is BDx [R|W]
BDI>BDH W 0xc019c390
# syntax is BDx [R|W]
BDI>bd0 w 0xc019c390
# syntax error in command
BDI>bd4 w 0xc019c390
# syntax error in command
BDI>bdw w 0xc019c390
# syntax error in command
BDI>bd r 0xc019c390
# syntax is BDx [R|W]
BDI>


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

Re: Abatron BDI2000

[Wolfgang Denk]

In message <B25E2E5A003CD311B61E00902778AF2A0204433C@SERVER1> you wrote:
>
> Is anyone out there using the Abatron BDI2000 to set hardware breakpoints on
> data access (on 405GP)? I'm probably just doing something dumb, but I don't
> see it. Any ideas?

Not on 405, but on 8xx / 82xx instead.

> BDI>bd w 0xc019c390
> # syntax is BDx [R|W]

BDI>bd w 0xc019c390
Breakpoint identification is 0

Works fine for me.

> BDI>bdx w 0xc019c390
> # syntax error in command

Error, "bdx" is no valid command.

> BDI>bd w c019c390
> # syntax error in command

Error, c0... is no valid hex number (0x... missing).

> BDI>bd 0xc019c390
> # syntax is BDx [R|W]

BDI>bd 0xc019c390
Breakpoint identification is 1

Works fine for me.

Um... Try re-loading the firmware.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

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

RE: Abatron BDI2000

[Brian Kuschak]

I reflashed my BDI2000 (loader=1.03, firmware=1.01, logic=1.01).
Unfortunately I get the same results.  I will contact Abatron.  Perhaps
there is a bug in this version of the command parser.

Thanks,
Brian


-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Tuesday, January 30, 2001 4:14 PM
To: Brian Kuschak
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Abatron BDI2000


In message <B25E2E5A003CD311B61E00902778AF2A0204433C@SERVER1> you wrote:
>
> Is anyone out there using the Abatron BDI2000 to set hardware breakpoints
on
> data access (on 405GP)? I'm probably just doing something dumb, but I
don't
> see it. Any ideas?

Not on 405, but on 8xx / 82xx instead.

> BDI>bd w 0xc019c390
> # syntax is BDx [R|W]

BDI>bd w 0xc019c390
Breakpoint identification is 0

Works fine for me.

> BDI>bdx w 0xc019c390
> # syntax error in command

Error, "bdx" is no valid command.

> BDI>bd w c019c390
> # syntax error in command

Error, c0... is no valid hex number (0x... missing).

> BDI>bd 0xc019c390
> # syntax is BDx [R|W]

BDI>bd 0xc019c390
Breakpoint identification is 1

Works fine for me.

Um... Try re-loading the firmware.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

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

Abatron BDI2000

[Joshua Horvath]

In my lab, we are currently using EST VisionICE boxes to develop custom
PowerPC 8xx based boards.  I recently got a BDI2000 evaluation unit and am
trying to decide if it makes sense to purchase a few of these units and dump
the EST boxes.

>From playing around with the Abatron unit, it seems the two biggest advantages
are

1) MMU support
2) Can be used with a Linux based development pc

Since we haven't had a problem bringing the kernel up on our boards, 1) isn't
(currently) a big deal.  What we really need is to be able to debug loadable
modules, which from what I've gathered is only possible with kgdb.  Is this
assumption correct?

We can flash our boards, download code, etc. and as I said, we've got the
kernel running successfully.  So other than point 2) above, is there anything
else I've missed that would provide a compelling reason to purchase these
units?


Thanks,
-Josh

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

Re: Abatron BDI2000

[Scott Anderson]

Joshua Horvath wrote:
> From playing around with the Abatron unit, it seems the two biggest advantages
> are
>
> 1) MMU support
> 2) Can be used with a Linux based development pc
>
> Since we haven't had a problem bringing the kernel up on our boards, 1) isn't
> (currently) a big deal.  What we really need is to be able to debug loadable
> modules, which from what I've gathered is only possible with kgdb.  Is this
> assumption correct?

I have used an Abatron to debug loadable modules.  As far as gdb is
concerned, it only knows that it is talking to something that speaks
the gdbserver protocol.  Whether that is kgdb or an Abatron makes no
difference.

> We can flash our boards, download code, etc. and as I said, we've got the
> kernel running successfully.  So other than point 2) above, is there anything
> else I've missed that would provide a compelling reason to purchase these
> units?

Price?

    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: Abatron BDI2000

[Wolfgang Denk]

Dear Joshua,

in message <3BE2C1DB.8B975906@labs.mot.com> you wrote:
>
> Since we haven't had a problem bringing the kernel up on our boards, 1) isn't
> (currently) a big deal.  What we really need is to be able to debug loadable
> modules, which from what I've gathered is only possible with kgdb.  Is this
> assumption correct?

No, this is wrong. Of course you can debug loadable modules with  the
BDI2000  as  well. You just have to manually load the symbol table in
GDB, for instance:

On the target: load the module:

	# insmod -m ./buzzer
	Sections:       Size      Address   Align
	.this           00000060  cf007000  2**2
	.text           000005a4  cf007060  2**2
	.rodata         00000128  cf007604  2**2
	.data           00000048  cf00772c  2**2
	.sdata          00000018  cf007774  2**2
	.kstrtab        000000ed  cf00778c  2**0
	.sbss           00000020  cf00787c  2**2
	.bss            00000000  cf00789c  2**0
	.plt            000000a0  cf0078a0  2**4
	__ksymtab       00000060  cf007940  2**2
	__archdata      00000000  cf0079a0  2**4

	Symbols:
	00000000 a buzzer.c
	cf007000 d __this_module
	cf007000 D __insmod_buzzer_O/tmp/buzzer_M3B276319_V132100
	cf007060 T buzzer_init
	cf007060 T __insmod_buzzer_S.text_L1444
	cf007060 t .text        <<============================================
	cf007170 t buzzer_open
	cf0071d8 t buzzer_release
	cf007218 t buzzer_read
	cf007220 t buzzer_write
	cf007284 t buzzer_ioctl
	...

In GDB:

	^C
	Program received signal SIGSTOP, Stopped (signal).
	0xc0003cdc in idled ()
	(gdb) add-symbol-file ../driver/buzzer 0xcf007060
	add symbol table from file "../driver/buzzer" at
		.text_addr = 0xcf007060
	(y or n) y
	Reading symbols from ../driver/buzzer...done.
	(gdb) b buzzer_op
	buzzer_open  buzzer_ops
	(gdb) b buzzer_open
	Breakpoint 2 at 0xcf007170: file buzzer.c, line 236.
	(gdb) b buzzer_ioctl
	Breakpoint 3 at 0xcf0072a0: file buzzer.c, line 316.
	(gdb) c
	Continuing.
	...
	Breakpoint 2, buzzer_open (inode=0xc0f28610, file=0xc01463c0) at buzzer.c:236
	236             if (!immr) {
	...


> We can flash our boards, download code, etc. and as I said, we've got the
> kernel running successfully.  So other than point 2) above, is there anything
> else I've missed that would provide a compelling reason to purchase these
> units?

You can debug device drivers (both statically linked  and  loaded  as
modules)  and  other  kernel  code.  The  BDI2000 works with many CPU
types. The price is (IMHO) fair, the quality good (3  years  warranry
on  the  hardware!),  and  I  know  no  other tool vendor with better
response.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.

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

RE: Abatron BDI2000

[Williams, Kevin M.]

Hello,

Could someone please post the .cnf file they use to debug the kernel with a
BDI-2000?

I just received a BDI2000 and it works great for debugging my bootrom, but
I'm a little confused about settings to use for debugging the
kernel...seeing a working example should be enough to get me going.

Thanks in advance.

Kevin

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

Re: Abatron BDI2000

[Wolfgang Denk]

Dear Kevin,

in message <A3E34B558F5CD211B4980008C7A4A99003C5853A@sparrow.gso.mcs.marconi.com> you wrote:
>
> I just received a BDI2000 and it works great for debugging my bootrom, but
> I'm a little confused about settings to use for debugging the
> kernel...seeing a working example should be enough to get me going.

Oops??? The config file for the  BDI2000  depends  on  the  processor
architecture  and  board  used,  but  that's it. You can use the SAME
config file both for firmware and for Linux kernel debugging.

Make sure you've RTFM about the "MMU XLAT" and the "PTBASE" settings.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Computers are not intelligent.  They only think they are.

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

RE: Abatron BDI2000

[Williams, Kevin M.]

I think the register definition file (reg8xx.def) is the same, but there
seems to be more to the .cnf file than just architecture and board used.
That is covered in the [INIT] section.  I have that correct or I would not
have been able to debug my bootrom using gdb, read/write memory, etc.  I can
do all that without any problem, and if all I wanted was to debug the
bootrom I would be all set.

What I am having trouble with is getting it to download the compressed
kernel image.

Specifically, I was hoping to see what was in the [TARGET], [FLASH], and
[HOST] sections of a correct .cnf file for debugging the kernel. I must
either have an offset incorrect, or not have something enabled, or something
similar. That seems to be where my problem is....in that dozen or so lines
at the end of the cnf file.

I know this is a newbie question, and I have read the manual and made
several attempts but cannot get it to work, so I was trying to make the
inconvenience as small as possible by just asking to see someone's .cnf file
and I will figure out my mistake from there.

Thanks for any help.

Kevin

-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Tuesday, November 20, 2001 12:13 PM
To: Williams, Kevin M.
Cc: linuxppc-embedded
Subject: Re: Abatron BDI2000



Dear Kevin,

in message
<A3E34B558F5CD211B4980008C7A4A99003C5853A@sparrow.gso.mcs.marconi.com> you
wrote:
>
> I just received a BDI2000 and it works great for debugging my bootrom, but
> I'm a little confused about settings to use for debugging the
> kernel...seeing a working example should be enough to get me going.

Oops??? The config file for the  BDI2000  depends  on  the  processor
architecture  and  board  used,  but  that's it. You can use the SAME
config file both for firmware and for Linux kernel debugging.

Make sure you've RTFM about the "MMU XLAT" and the "PTBASE" settings.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Computers are not intelligent.  They only think they are.


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

Re: Abatron BDI2000

[Wolfgang Denk]

In message <A3E34B558F5CD211B4980008C7A4A99003C5853B@sparrow.gso.mcs.marconi.com> you wrote:
>
> That is covered in the [INIT] section.  I have that correct or I would not
> have been able to debug my bootrom using gdb, read/write memory, etc.  I can
> do all that without any problem, and if all I wanted was to debug the
> bootrom I would be all set.

Umm... this depends a lot on how you work. Many people  tend  to  put
full initialization (for instance including the memory controller) in
the config file. Istead, I use always minimal config files.

> What I am having trouble with is getting it to download the compressed
> kernel image.

You should be aware that it's not a trivial task to boot  Linux  from
the  BDI2000;  you  not  only need to get all hardware initialization
correct, you also have to prepare and pass a data structure with  all
necessary  parameters  (board  info struct, ramdisk address and size,
command line etc.) to the Linux kernel.

Why are you trying to do this? Use your firmware  to  initialize  the
hardware,  and  to  load  and  boot  the  Linux  kernel. This is MUCH
easier...

> Specifically, I was hoping to see what was in the [TARGET], [FLASH], and
> [HOST] sections of a correct .cnf file for debugging the kernel. I must
> either have an offset incorrect, or not have something enabled, or something
> similar. That seems to be where my problem is....in that dozen or so lines
> at the end of the cnf file.

OK, here is a generic config file I use on many MPC8xx systems:

----- cut here -----
[INIT]
; init core register
WREG	MSR		0x00001002	;MSR  : ME,RI
WSPR	27		0x00001002	;SRR1 : ME,RI
WSPR	149		0x2002000F	;DER  : set debug enable register
WSPR	638		0xFFF00000	;IMMR : internal memory at 0xFFF00000
WSPR	158		0x00000007	;ICTRL:

; init SIU register
WM32	0xFFF00000	0x00010400	;SIUMCR
WM32	0xFFF00004	0xFFFFFF89	;SYPCR

[TARGET]
MMU	    XLAT	; support virtual addresses (for Linux!)
PTBASE	    0x000000F0	; ptr to page table pointers
CPUCLOCK    45000000	;the CPU clock rate after processing the init list
BDIMODE	    AGENT	;the BDI working mode (LOADONLY | AGENT)
BREAKMODE   HARD	;SOFT or HARD, HARD uses PPC hardware breakpoints

[HOST]
IP	    10.0.0.8
LOAD	    MANUAL	;load code MANUAL or AUTO after reset
DEBUGPORT   2001
START	    0x0100

[FLASH]
CHIPTYPE    AM29BX16	;Flash type (AM29LV160B)
CHIPSIZE    0x200000	;The size of one flash chip in bytes
BUSWIDTH    32		;The width of the flash memory bus in bits (8 | 16 | 32)
WORKSPACE   0xFFF02000	; RAM buffer for fast flash programming

[REGS]
DMM1	0xFFF00000
FILE	BDI2000/reg8xx.def
----- cut here -----

As you can see, it does not contain any specific  stuff  to  load  or
program  files (I always feed those in manually, or using some expect
scripts).

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It usually takes more than three weeks to prepare  a  good  impromptu
speech.                                                  - Mark Twain

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

Re: Abatron BDI2000

[Michael Habermann]

At 05:00 PM 11/20/2001 +0000, Alex Zeffertt wrote:
>   BDI> load vmlinux image
>   Loading vmlinux , please wait ....
>   - File offset 0x00010000 to address 0xC0000000 size 6946844
>   # PPC: interrupt indication received (may be bus error)
>
>In the BDi2000 manual (section 3.3.4) it says you need to "Load the
>compressed linux image".  But I
>couldn't find any way to build vmlinuz for the PPC architecture.  As far
>as I'm aware this is only a
>valid target when ARCH=i386.

I do it in this way:
1. Flashing PPCBoot as bootloader using the BDI
2. Boot the PPCBoot which then loads the kernel via TFTP.

In most cases using Linux, you don't need to write an image into RAM using
the BDI. Also 0xc000000 is a virtual adress. You have to pass the BDI a
physical memory address. The Bus error means that no memory or device is
connected at 0xc000000.


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