You are viewing outdated content for BUG. If you have a BUG Y.T. edition or 2.0 series device, please visit our updated wiki: http://wiki.buglabs.net
BUG Kernel Development with Eclipse
From BUG Wiki
Contents |
Overview
This page describes how to modify Linux kernel sources, compile, and debug with Eclipse. The examples on this page will be using the BUG 2.0 kernel and hardware but all steps should also work on BUG 1.x software and hardware. The notable difference will be the kernel source location and the serial port setup for remote debugging.
Prerequisites
- A Linux host
- Eclipse 3.5
- A BUG with a dock or cable that allows for a serial console at boot.
Warning
The author of this page is pretty new to both Linux kernel development and Eclipse's CDT. Dear reader, if you know of better/faster/cleaner ways of doing any of this please let me know.
Get Linux Sources
Create a working directory and clone Matt Isaac's kernel tree from github:
$ mkdir kernel_dev $ cd kernel_dev/ $ git clone git://github.com/haveahennessy/bl-linux-omap.git ... < this will take time! > ...
Copy the default BUG kernel configuration:
$ cd bl-linux-omap/ $ cp arch/arm/configs/omap3_bug_defconfig .config
Toolchain Setup
Get the Angstrom SDK and install it on your Linux host. I have installed mine into the default directory of /usr/local. You do not have to copy it there but if it's in another location you'll need to modify the environment script to point to the correct directory.
$ wget http://bugcommunity.com/development/angstrom_sdk/angstrom-2009.X-stable-armv7a-linux-gnueabi-toolchain.tar.bz2 $ tar xfj angstrom-2009.X-stable-armv7a-linux-gnueabi-toolchain.tar.bz2 $ sudo mv usr/local/angstrom /usr/local/
Now setup your terminal's environment to use the SDK build tools:
$ source /usr/local/angstrom/arm/environment-setup $ arm-angstrom-linux-gnueabi-gcc --version arm-angstrom-linux-gnueabi-gcc (GCC) 4.3.1 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Test toolchain
Let's compile the kernel with our toolchain on the commandline to confirm everything is working.
$ cd bl-linux-omap $ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- menuconfig $ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- vmlinux ... <get some tea> ...
If everything is setup right this should pass and we know that the toolchain and environment are setup properly.
Eclipse Setup
The cross compiler tools should be in your path when you run Eclipse. I have done this by running Eclipse from the same terminal that I have run environment-setup from. Once Eclipse is running, install CDT. I have also installed the Linux Tools for Eclipse. Currently I am not sure if these are necessary or not for the purposes of this wiki page.
Project Configuration
In my exercise I have started with a fresh workspace. I recommend this as the CDT plugins can do indexing and compiling in the background that at times can get in the way of other development tasks. There may be ways of configuring CDT to be "nice" but I have yet to find a workable solution where-as I can do my Java development along side C development.
In my new workspace (not in the directory I checked out my Linux sources) after switching to the C/C++ perspective, I create a C project. I change the working directory to where the Linux sources are:
The second page of the wizard needs some modifications. CDT tends to put it's toolchain configuration within the project definition, so here is where we specify our toolchain. I've changed the Advanced Settings to look like this:
Note that I'm modifying the "Debug" configuration to call a custom make, not letting Eclipse generate makefiles, and since I've already got my cross toolchain on the path I do not have to worry about setting up each tool's path.
Now I unselect the "Release" configuration, so that CDT will only use my modifications when building. Ideally I could create my own configuration and not override "Debug" however I cannot see how to do this from these dialogs.
After selecting "Finish" CDT will do it's thing. It takes time to index all the C files. In the Eclipse status bar you'll see "C/C++ Indexer: (xx)", this shows how far along the indexing has come. I suggest now is a good time to go have a nice lunch.
After the nice lunch you should have a workbench that looks like this. Note that all the files are indexed so you can easily move through source files, find type and struct definitions, etc.
Remote Debugging
Now comes the magic, running the Linux kernel on the BUG and being able to stop and inspect its state! There are two aspects to this, BUG configuration and Eclipse configuration.
BUG Configuration
The default kernel configuration currently includes the kgdb option. This may change in the future so if you have problems confirm that your kernel has this enabled. We simply need to enable kgdb and tell it where to wait for the gdb server. When the BUG boots, stop the booting process in UBOOT. Modify the mmcargs variable by entering this at the uboot prompt:
U-Boot 2009.08-dirty (Nov 25 2009 - 17:12:07)
OMAP3530-GP ES3.1, CPU-OPP2 L3-165MHz
OMAP3 BUGBase 2.0 board + LPDDR/NAND
DRAM: 256 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Error : I2C unsupported speed 100
Die ID #2752000400000000040365fa1300e00e
Hit any key to stop autoboot: 0
BUGBASE2 # setenv mmcargs setenv bootargs console=${console} root=/dev/mmcblk0p1 rw rootwait rootdelay=1 usbcore.autosuspend=-1 kgdboc=ttyS2 kgdbwait
BUGBASE2 # boot
Now type boot, and after some initial kernel messages you should see something like:
... console [ttyS2] enabled kgdb: Registered I/O driver kgdboc. kgdb: Waiting for connection from remote gdb...
Eclipse Configuration
Open the Debug Configuration dialog by selecting Run->Debug Configurations from the Eclipse menu. Create a new C/C++ Application debug profile like this:
Now go to the Debugger tab and configure it to use the Angstrom SDK version of gdb:
Be sure that the serial port settings are correct on the Connection tab:
Once all the required information is filled in select "Debug". CDT will run some background work the first time this happens and make take some time. Eventually you'll be asked if you want to enter the Debug perspective. At this point you should be able to set breakpoints in the kernel sources and see them in the CDT debugger.
