Recipes4Linux
Recipes4Linux
DDD-2000 has been extensively tested on the following commercial distributions:
RHL 7.x
RHL 8
RHL 9
The following information has to be filtered when applied to different host distributions. If you did not install all packages doing a custom installation, you may need to install individual RPM files, as required.
All recipes on this site make assumptions about the host, to keep things simpler in the recipes. See this link to review the basic assumptions.
Built-in to DDD-2000 is an interface to the bdisetup utility that must be run to configure the BDI-2000 the first time you use it. Outside of the DDD-2000 installation, the user must build the bdisetup utility that is part of the firmware update files provided by Ultimate Solutions. The bdisetup utility must be in the $PATH setting (typically /usr/local/bin) in order for DDD-2000 to access the utility. Please note that a serial connection is required between the host and the BDI-2000 unit when the bdisetup utility is used.
See R4DDD2000 : 2 : Edit | Preferences | bdi2000 window for a description of the setup variables that should be updated for your system. Please use the Help button on this display for additional information about each Preference variable/setting. Alternatively, from the command line, after bdisetup is built and installed, you can issue this command to receive a help display directly from the utility:
bdisetup > bdi.help
This command creates a text file in the current working directory that can be viewed for additional information about the bdisetup commands and parameters.
Whenever firmware updates are issued by Ultimate Solutions, or some network configuration option has changed, you should run the bdisetup utility. Please follow these steps.
Recipe steps...
Remove power from target board
Disconnect JTAG cable between target and BDI-2000
Establish RS-232 connection between BDI-2000 and host
Install firmware update files on host
Modify Edit | Preferences | bdi2000 settings, as required
Run appropriate bdisetup utility function
Cycle power on the BDI-2000 unit (leave power off for 10 seconds)
| bdisetup utility function | Description |
| bdi2000 | bdiSetup | bdiVersion | runs bdisetup -v to determine current version information |
| bdi2000 | bdiSetup | bdiErase | runs bdisetup -e to erase current firmware and logic |
| bdi2000 | bdiSetup | bdiUpdate | runs bdisetup -u to update firmware and logic |
| bdi2000 | bdiSetup | bdiConfigure | runs bdisetup -c to configure network parameters |
Please note that when any of the bdisetup functions are executed, the X display "freezes" until the command completes. The status line at the bottom of the display is updated to reflect the utility function running, but no X control is possible until the utility completes. When the function is complete an X dialog window appears with the output of the command.
This section describes the same sequence of steps as detailed in the App-Note available from Ultimate Solutions on debugging a Linux Kernel. The App-Note is titled "Using the Abatron BDI-2000 to Debug a Linux Kernel" and is Number 02-001. A PDF version of this App-Note is available here, and Ultimate Solutions can provide a hard-copy of the App-Note, if this is desirable.
The sequence of steps, as presented here, are in a slightly different order, because DDD-2000 now controls the BDI-2000 unit. The hardware used (RPX-Lite PPC/823 board from Embedded Planet) is the same, but the kernel version is now slightly different. The steps described here are based on using the Journeyman edition of HHL 2.0. Only the actual steps are presented here, for a description of the steps, please see the App-Note link above.
Preparing the Kernel to be Debugged
cd [root of kernel source tree]
vi +/'CFLAGS :=' Makefile
add "-g -ggdb" to the end of the CFLAGS macro definition
make clean dep
make zImage
make modules
make modules_install
cp arch/ppc/boot/images/zImage.mbx /tftpboot/vmlinuz.bdi
Some of the steps above, like 2-3, you will only do once, but most of them you will do whenever you modify the kernel, or more likely, a driver that is linked with the kernel. Step 8 gives the BDI-2000 visibility to the kernel image that will be downloaded. The filename specified in step 8 should be the same as that specified in the configuration file used by the BDI-2000.
Starting minicom (assumes serial connection between host and target)
minicom
Starting DDD-2000 and downloading Linux kernel
Steps in this recipe involve interacting with 3 components of DDD-2000: the gdb console window [gdb], the bdi console window [bdi] and the menu system.
cd [root of kernel source tree]
ddd --debugger ppc_8xx-gdb --gdb vmlinux
bdi2000 | connectBDI
bdi2000 | reset
[bdi] go
in minicom window, wait for firmware prompt
[bdi] halt
[bdi] load
[bdi] bi 0xc0002180
[bdi] go
in minicom window, wait for target to hit breakpoint and return control
[bdi] ci
bdi2000 | connectGDB
[gdb] b panic
[gdb] b sys_sync
[gdb] cont
At this point, in the minicom window, the kernel should complete booting and a login prompt should appear. The kernel has booted, with two breakpoints set and you can begin your debug session. The address above (0xc0002180) is the address for 'start_here' in my kernel image. This address will differ in most kernel images, and the user may wish to place the initial breakpoint at another place in the kernel image. Unless you need to debug the very initial start-up code, it is recommended that the initial breakpoint be placed after the kernel has enabled the MMU.
Sometimes during a debug session it becomes necessary or advantageous to reset the target and/or cycle power on the target. Please follow the instructions in this recipe when you need to do this with your system.
Once the target is reset or power-cycled, issue the BDI reset command:
bdi2000 | reset
Whatever was running on the target is lost and has to be reloaded. If you were debugging a Linux kernel, follow the steps in recipe R4US : 2 : Loading and debugging a Linux Kernel.
From the perspective of DDD-2000, this is a benign event.
All breakpoint information in gdb is still accurate and breakpoint(s)/watchpoint(s) do not have to be redone.
Unlike R4US : 3 : Cycling power on the target board, this event must be managed carefully. Basically, the power sequence documented in the bdiGDB User Manual, must be followed.
The following reference is on the bottom of page 8 of my manual (v1.23 for PowerPC MPC8xx/MPC5xx)...
Please switch on the system in the following sequence:
external power supply (for BDI-2000)
target system
If power is cycled on the BDI-2000 unit, and the target is not turned off, the telnet interface to the BDI-2000 will appear to hang. If a bdi2000 menu command is attempted at this time, more than likely DDD-2000 will crash with a core file. If the system hasn't crashed, cycle power on the target and the expected behavior should occur.
Expected behavior is that when the BDI-2000 unit is power-cycled, the telnet process is killed and restarted. When the system is operating normally, the [Not Connected] prompt appears in the bdi console window after a BDI-2000 power-cycle. At this point, issue the bdi2000 | connectBDI command and a new telnet session is established with the BDI-2000.
The user now has to restore the debug session to the state it was in prior to the power-cycle.
From the perspective of DDD-2000, the expected behavior from this event is benign. The fact that DDD-2000 cannot, at this time, protect against the unexpected behavior, is known and the user is warned.
All breakpoint information in gdb is still accurate and breakpoint(s)/watchpoint(s) do not have to be redone.
You will probably have to issue the GDB connect command:
bdi2000 | connectGDB
twice. The first time an error message is displayed in the dialog window, related to a Broken pipe and the putpkt function. The second time the command is issued, no error message occurs and the connection between GDB and the BDI-2000 is re-established.
PLEASE NOTE: If you try to exit DDD-2000 with an inconsistent state between gdb and the BDI-2000 unit, the program does not exit normally. The DDD-2000 process needs to be killed at the command-line. A core file is likely to be generated. In this context, inconsistent means that gdb believes a connection is established with a gdb-agent process (BDI-2000), and the connection no longer exists because the BDI-2000 has been reset.
Contact tmike@recipes4linux.com
Copyright © 2004 Tools Made Tough