I’m wondering if anyone has any links to a small Linux image I could use with BeagleBoard XM. I need the source code with the image as well, I’m trying to set up a JTAG (XDS100 from Spectrum Digital) and debug into the Kernel using Code Composer Studio as the board boots up. Since the BB XM has 512MB onboard memory I cant go any higher than that.
I have found an image on eLinux.org (http://rcn-ee.net/deb/rootfs/natty/ubuntu-11.04-r1-minimal-armel.tar.xz - thanks Rob, this was the image I used to get my BB running a while ago!) but I dont think there is any source code with it and I need the source code to debug into (and I think trying to find the exact source code that went into this build might be a time-consuming task).
My ultimate goal is to debug into a pci driver as it the kernel boots so I can understand how it works before I try building my own driver for a project.
Thx, Dean
With my images, it's just the mainline kernel + patch + defconfig..
Using the kernel version via (uname -r) as reference you can find the
patch/defconfig here: http://rcn-ee.net/deb/
Or thru the git tree, which has the build instructions for every
release tagged..
https://github.com/RobertCNelson/stable-kernel
Regards,
Dean Hoskins wrote:
My ultimate goal is to debug into a pci driver as it the kernel boots so I can understand how it works before I try
building my own driver for a project.
PCI?
probably *SPI*
Thanks Robert,
I'll check out your links. I was worried that the mainline kernel
would produce an image much bigger than your image that I originally
downloaded (which was less than 512Mb). The only reason I was thinking
this was that after I loaded your image I loaded in packages for a
Desktop and C/C++ development, etc. and my image now stands at 2.6Gb.
I assume if I build an image from the links you have it will still be
below 512Mb.
I notice in you /deb/natty directory there are builds ending in x#,
d#, rc#, is there a convention? I assume every different subdirectory
(for example v3.0-rc1-d0 and v3.0-rc2-d0) are whole builds (dont need
any other files from other directories), is that correct?
Thanks, Dean
Its a little old (Peripheral Component Interconnect) and used to plug
in cards (for example an Ethernet PCI card), you may already know
this. The Beagleboard doesnt have (most PC's do) this but its a good
platform for learning how to do a kernel debug (at least I hope so).
If I can learn how to kernel debug (into drivers - for example the
Ethernet driver [no PCI]) on beagleboard then I can branch off into
trying a debug on other boards that use PCI (and that have a JTAG).
Hi Dean,
That is correct, each sub-directory is from it's own separate build.
The convention i use
-x#'s = stable;
-d#'s = development;
To see what's the latest of each, grep this file:
http://rcn-ee.net/deb/natty/LATEST
Regards,
Dean, 2.6GB kernel image for an embedded system sounds weird. If you don't require the luxury of desktop environment, the mainline kernel image (from kernel.org) with defconfig for beagleboard, makes a UImage of just <5MB. Build other required modules in RFS and load them when the kernel boots or when they are really needed.
Still the total uncompressed size will be nowhere near to your boundary of 512MB.
Thank you,
Johnson
Robert,
A couple questions. I am using your 2.6.39-x1 image (used your install
script to build a 4Gb SD card) and it boots fine.
I need the source for this and I need an uncompressed image for it. I
looked in http://rcn-ee.net/deb/ but I didnt see the source or an
uncompressed image (correct me if I'm wrong but uImage would be the
uncompressed version of vmlinuz which would have the debug symbols in
it - I'm trying to debug in Code Composer Studio). I was able to see
whats inside the .deb files but only saw the .h files not the .c
source.
I can take the route of building the uncompressed image from source by
going to kernel.org but I thought you might have the associated source
and uncompressed image on one of your directories. Can you tell me if
you have the files?
Thanks, Dean
Hi Johnson,
I'm learning the distinction between the kernel and the file system
for debugging, its the file system that has the excessive size after
adding all of the things I mentioned (Eclipse, Desktop, etc.) and
you're right the actual kernal image is small. I was also worried that
in order to debug I would need to fit evrything on the 512MB but it
looks like I only need to worry about the kernel (and possibly any
loader .ko modules) and that the file system just stays in the
background (on the SD card).
Thanks, Dean
Robert,
A couple questions. I am using your 2.6.39-x1 image (used your install
script to build a 4Gb SD card) and it boots fine.I need the source for this and I need an uncompressed image for it. I
looked in Index of /deb but I didnt see the source or an
Hi Dean, if you need the source for 2.6.39-x1 it's..
2.6.39 from kernel.org +
http://rcn-ee.net/deb/natty/v2.6.39-x1/patch-2.6.39-x1.diff.gz +
http://rcn-ee.net/deb/natty/v2.6.39-x1/defconfig
uncompressed image (correct me if I'm wrong but uImage would be the
uncompressed version of vmlinuz which would have the debug symbols in
it - I'm trying to debug in Code Composer Studio). I was able to see
whats inside the .deb files but only saw the .h files not the .c
with 2.6.39 i have: CONFIG_KERNEL_LZMA=y enabled by default, so it's
actually compressed...
As far as debug symbols, make sure you enable:
CONFIG_DEBUG_INFO (which is disabled in my image..)
Regards,
Why not just use KGDB? So much simpler.
Regs,
Joel
Dean, How about loading your root file system over NFS?
Thank you,
Johnson
Hi Joel,
I'm new to kernel debugging so I didnt know if KGDB would be as easy
as setting up a JTAG with Code COmposer Studio. I got it running today
although a lot of hair pulling. I can debug the kernel although I
still have some problems with associating some symbols with code.
Dean
Hi Robert,
I got Code Composer Studio (CCS) running with the XDS100v2 JTAG and I
can step through the code. I do have some symbol concerns though. I
did use CONFIG_DEBUG_INFO=y and I did find a vmlinux file which seems
to satisfy CCS (do you know why there is a vmlinux.o? It doesnt seem
to be a proper symbol file for CCS). Also I guess its the uImage file
that has to line up with vmlinux (kernel file to matching symbol
defs), is that correct? And from googling I get the impression that
using CFLAGS optimization of O2 is the best you can do without having
problems (on bare-metal I always use o0 so the source code matches up
directly with the object code).
The biggest time consumer is trying to understand which source files
(in the massive kernel tree) are not related to a beagleboard so that
I can tell CCS where to look for the right ones and skip the wrong
ones (for instance there are a lot of main.c files in many
directories). Also I dont understand how the vmlinux file (debug
symbols) tells CCS which source code file to associate with the object
code, in many cases it got it correct (the function shown on the stack
matches the source code shown in the source and assembly debug
windows) but in some cases it doesnt (the stack will say for instance
its in cpuidle_idle_call() from power.h:line 111 when its definitely
in the cpuidle.c file).
If you have any pointers I'd be interested in hearing them, it would
help speed up my very slow pace 
For instance could I delete
everything under /arch except the arm directory or are other
directories necessary (I'll bet not ppc or sparc but I'm not so sure
about ones like um (user mode?))? I wonder if there is a kernel tree
just for beagleboard-xm...
Thanks again! Dean
Robert,
In the hit and miss of googling I did stumble on an interesting Linux
command:
nm -a -C -l vmlinux
it provides a list of symbols and their associated source code
mappings (down to the line number) as well as their mapping to an
assembly location. I guess as long as the assembly mapping is correct
for the uImage file then the debugger should pick up the correct
location in the source file.
Dean