GSoC Weekly Report #2

Weekly Report #2

Submitted on 2010-05-31

Covers 2010-05-23 to 2010-05-31

Corresponding Draft Schedule Item:

Familiarize with DSP/BIOS Link and its various modules. Experiment with GPP-DSP communication and compilation processes to identify potential issues and useful features. Review existing RPC protocols and create one suitable for DSP-GPP communication over DSP/BIOS Link.

Status and Accomplishments

• initially built DSP/Link module and examples using OpenEmbedded
• modified DSP/Link examples and built them using the ti-devshell script with the OE toolchain
• successfully compiled and tried out C6RunApp on the BeagleBoard, using both OE and CodeSourcery toolchains
• created the dsp-rpc-posix branch at http://gforge.ti.com/svn/dspeasy/C6RunApp/branches/dsp-rpc-posix (no commits yet, though)
• did some more studying of the C6RunApp source code, better understanding when one sees it in action

Plans and Tasks

• more experimentation with DSP<->GPP communication and especially with DSP side code
• benchmark some DSP/Link on the Beagle, mainly NOTIFY and MSGQ, may be useful to have numbers around
• study how C6RunLib does RPC calls from GPP to DSP to get some inspiration for implementing the reverse
• come up with a finalized list for the order in which the POSIX wrappers will be written

Risks, issues, blockers

• probably not an issue but worth a mention: the speed at which DSP/Link conveys messages and notifications may have a performance impact, but this isn't expected to be a major issue since the primary goal is easy prototyping on the DSP anyway
• how best to determine which C standard library functions are used the most often / are the most useful? (aside from personal experience) statistics? polls?
• the original project definition contains a few too many references to POSIX - Daniel Allred pointed out that there are many fine details and many, many functions in the standard itself. full POSIX compatibility could be an eventual goal (but why full compliance is such a good idea is open to discussion) but it looks wiser and more productive to start and progress with commonly used / useful functions.
• providing easier prototyping will lower the entry level and this may, in turn, mean there will be more inexperienced behavior regarding the dsp. some basic "baby-sitting" (perhaps checking/loading the needed kernel modules automatically at the app startup, and catching Ctrl-C signals so we can cleanup before the exit) may be necessary.
• DSP works with physical addresses, while the GPP works with virtual ones. what if the user wants to print a string which is allocated from the DSP heap? the issue can be handled by copying buffers to POOL buffers and passing them in this manner (this is what C6RunApp currently does) but the issue itself is worth further investigation. is there a better approach? will POOL buffer copying be sufficient, or is there something it won't be able to handle correctly? 

Modifying the DSP/Link examples and utilizing OE toolchains outside OE

Now that we got OE to build the DSP/Link kernel module and examples for us, we'll probably want to do some tinkering with the sample applications to feel more comfortable with DSP/Link - one may just as well start from scratch, but it definitely won't be as easy as modifying the existing examples.

You should be able to find the dsplink source tree at

~/oe/setup-scripts/build/tmp-angstrom_2008_1/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dsplink-tree/packages/dsplink

and under this directory, you'll find the two directories for the sample sources, namely gpp/src/samples for the GPP-side code of the samples, and dsp/src/samples for the DSP-side. The source codes found in these directories themselves is quite interesting to study to learn how DSP/Link and its components are used, and I've heard that actually tinkering with things allows you to learn much faster *wink wink*.

The thing is, once you have modified the sources, it's not very straightforward to re-compile them as they're part of the DSP/Link make system. Here one can utilize OpenEmbedded's environment to make this go a bit more smoothly.

The ti-devshell recipe generates a shell script which you can run to become bitbake. Well, maybe not become bitbake, but it'll export all the related environment variables for you once you run it, which will make life much easier. One thing before baking the actual recipe that you may want to do is, check the ti-devshell.bb recipe file and see if it contains this line:

PACKAGE_ARCH = "${MACHINE_ARCH}"

if it doesn't, you can just add it somewhere near the top - it'll be generating incorrect paths for the ti- thingies otherwise. Koen mentioned that this is needed due to some hack the ti- recipes are using.

After bitbake ti-devshell you'll end up with a shell script in the OE deploy/addons directory. Try running this script and typing in env to get an idea how much it does for you :)

The part that comes now was inspired by how the ti-dsplink.bb recipe does things - it's highly recommended that you examine the file yourself.

Next, go into the dsplink source directory by issuing cd $LINK_INSTALL_DIR. There's one particular environment variable that the script doesn't set, so export DSPLINK=$LINK_INSTALL_DIR/dsplink. Find the config script under config/bin in the dsplink directory, and execute this to configure the DSP/Link make system:

perl dsplinkcfg.pl --platform=OMAP3530 --nodsp=1 --dspcfg_0=OMAP3530SHMEM --dspos_0=DSPBIOS5XX --gppos=OMAPLSP --comps=ponslrmc

What was that bunch of parameters? You can run the script without any arguments and it'll describe each of them for you, along with the choices you have. Following the default settings (ie the ones I mention above) is highly recommended though.

Just two steps away from completion...there's some more bitbake-inspired environment variables to be set - beware that these represent my particular paths with the OE root located at ~/oe.

export TARGET_PREFIX=arm-angstrom-linux-gnueabi-

export TOOLCHAIN_PATH=~/oe/setup-scripts/build/tmp-angstrom_2008_1/cross/armv7a

export TARGET_SYS=arm-angstrom-linux-gnueabi

export STAGING_KERNEL_DIR=~/oe/setup-scripts/build/tmp-angstrom_2008_1/sysroots/beagleboard-angstrom-linux-gnueabi/kernel

Finally, go into the gpp/src/samples directory and...

make BASE_TOOLCHAIN="${TOOLCHAIN_PATH}" BASE_CGTOOLS="${BASE_TOOLCHAIN}/bin" OSINC_PLATFORM="${TOOLCHAIN_PATH}/lib/gcc/${TARGET_SYS}/$(${TARGET_PREFIX}gcc -dumpversion)/include" OSINC_TARGET="${BASE_TOOLCHAIN}/target/usr/include" CROSS_COMPILE="${TARGET_PREFIX}" CC="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}gcc" LD="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}gcc" AR="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}ar" COMPILER="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}gcc" LINKER="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}gcc" ARCHIVER="${TOOLCHAIN_PATH}/bin/${TARGET_PREFIX}ar" KERNEL_DIR="${STAGING_KERNEL_DIR}" all

it's just ripped off from the OE dsp/link recipe, it should be just fine to copy-paste it into your terminal as it's pretty neutral with a lot of environment variables (which we already defined in the previous step). You can repeat the same make comand in dsp/src/samples to build the DSP-side code as well, all of which will end up in the gpp/BUILD and dsp/BUILD directories.

Moment of Truth #1: Hello World from the DSP with C6RunApp

O World, behold the C6RunApp saying Hello to Thee!

C6RunApp (formerly known as DSPEasy) is an awesome cross-compiling tool that I'll be basing my work on. What it allows you to do is basically this: you write your 5-line run-of-the-mill Hello World application in plain old C, then call the cross-compiling script on this file as you would call gcc to produce the hello_world_dsp executable you see above. The executable itself is (obviously) an ARM executable, but when you run it it magically extracts the compiled DSP binary from within itself, takes care of all the tedious work of setting up the communications via DSP/Link, and services some C I/O (such as printf) on request from the DSP. Now imagine this with the full capabilities of the standard C library we know and love, not to mention the eventual ability to connect to any ARM-side function. Wouldn't it be lovely to do DSP development like this?

Coming soon: Developing for the DSP, using the OE toolchain to build modified DSP/Link samples, setting up C6RunApp and much more!

Building DSP/Link with OpenEmbedded

I'll be shortly making a post about how the traditional DSP development cycle with DSP/Link works to further emphasize why C6Run and DSP-RPC-POSIX (that'd be my GSoC project's name :)) are needed. But before that, I though I'd talk a little about setting up DSP/Link -which is a vital component for doing DSP development on OMAP3530 in the preferred way- using OpenEmbedded.

Start off by building the ti-dsplink recipe:

bitbake ti-dsplink

(if, for some reason, you want only the kernel module for dsplink, you can use the ti-dsplink-module recipe instead - the ti-dsplink recipe contains both the module and the samples)

This should result in several package files in your OE deployment directory (something like ~/oe/setup-scripts/build/tmp-angstrom_2008_1/deploy/glibc/ipk), which can be transferred to your Beagle (by directly copying them to the SD, by networking, by nfs...the options are endless - I personally mount the beagle via sshfs on my host machine) and then installed with opkg install . 

That's all there is to building and install DSP/Link, really! You can invoke the provided examples by cd'ing into /usr/share/ti/ti-dsplink-examples and then:

1. ./ti-dsplink-examples-loadmodules.sh to load the kernel modules. Note that you should have your bootargs configured to leave several megabytes of memory to the DSP/Link module. You may get a warning on the newer Beagles with 256 megs of RAM even if your bootargs are configured correctly, since the script just checks if you have more than 126 megs allocated for the kernel, so no panic.
2. ./ti-dsplink-examples-run.sh to run all the examples with some default parameters - you can examine the contents of this file to see how particular examples are invoked. Aside from the second parameter (which is the DSP executable name) and the last (which is the DSP ID), playing around with the parameters should be safe.
3. ./ti-dsplink-examples-unloadmodules.sh to optionally unload the modules once you're done.

Getting a working gzip

I've previously mentioned that the current version of gzip that ships with Ubuntu 10.04 is broken, among some other distros. I've also mentioned a manual workaround with the gzip recovery tools, but for several reasons (such as not wanting to do the same damn sequence of actions, md5 and sha256 calculations and recipe updating while building things with OpenEmbedded!) one may want to fix those annoying crc error / unexpected end of file error's once and for all.

1. Download the gzip-1.4 package from here.
2. Extract into folder of your choice, I used ~/gzip-1.4
3. Open the terminal and cd into the extraction folder
4. Run ./configure
5. Run make
6. Run sudo make install

And now you have the gzip-1.4 binaries installed on your system, which should take care of the gzip crc errors.

GSoC Weekly Report #1

Here's my first weekly report on my GSoC work. My dear visitors will probably want to skip to parts 2 and 3 since the first part contains mostly my ramblings about OpenEmbedded, which you've already read.

I'll promise it'll be shorter and easier to read the next time - but well, here goes :)

1) Setting up OpenEmbedded

Since the GSoC coding begins officially on 24th of May, and also since
I'm required to be very familiar with the development environment if I
want to be able to make life easier for DSP developers who'll be
working in the same environment, I was suggested to concentrate mainly
on setting up the OpenEmbedded toolchain correctly and build some of
the DSP/Link-related recipes. My initial experience with the setup was
rather frustrating, and it's slightly ironic that this occured not
because of lack of information on the topic, but due to too much
outdated/irrelevant information which is spread around the net, on the
wikis, etc. I initially tried out manually building the stable/2009
branch and learned that this branch was way too outdated. I then tried
setting up the apt-get'able OE and building the dev branch, which I've
had some success with and made a blog post to talk about the issues I
ran into during the process, only to find out later by Koen's mail
that the apt-get'able OE is somehow broken by design and the Ångström
setup scripts are *the* preferred way of doing things. As of the time
of reporting, I've successfully set up my devenv using the setup
scripts, but I honestly think that the visibility of these scripts
needs to be improved in the community provided documentation.

2) Familiarization with DSP/Link and the existing C6Run code

I should first mention that I haven't been able to spend as much time
on this subject as I would have liked to, since I was practically
struggling with the OE setup during the whole week. I had already
compiled DSP/Link and the sample applications using the CodeSourcery
toolchain and gone through parts of the DSP/Link API documentation,
but I still had a long way to go towards being able to use this
knowledge practically, thus I spent some more time on reading
documentation and source code. Aside from the DSP/Link User Manual and
the provided samples, I found the tutorials and documentation on the
ETH PIXHAWK (Computer Vision on Micro Air Vehicles) very helpful.
After these I went through the C6RunApp (formerly DSPEasy) source code
and I now do feel that I have sufficient practical understanding of
the DSP/Link architecture in general and how C6RunApp works in
specific to be able to start experimenting with GPP-hosted DSP-side
calls. This week I'll be trying to get C6Run to build using the OE
toolchain and play around with the PROC, NOTIFY, MSGQ and RINGIO
DSP/Link modules on my own, including some benchmarking for the
various calls since Daniel Allred mentioned over IRC that GPP->DSP
MSGQ message passing can take as much as 0.5ms on the hawkboard and
using NOTIFY may be able to speed things up, although these numbers
are likely to differ on the Beagle.


3) Order of porting for the POSIX functions and how much work the DSP
should be doing on them

One of my goals in the preliminary period was to determine how much of
the POSIX calls should be executed on the DSP and also in which order
the porting should be carried out with respect to their internal
dependencies. Concluding from my previous talk with Daniel over IRC
and my own studies of the commonly used C library .h functions which
my opinion is that -possibly- aside from a few math functions that
involve some internal number crunching, all of the POSIX calls should
be *completely* hosted on the GPP side, ie the DSP should only send a
request with the function name and parameters without doing any
pre-processing. The reasons behind this would be:

 * the DSP is not really suitable for most of the tasks involved in
the internals of POSIX functions, which usually don't involve heavy
mathemathical operations but things like string manipulation which the
GPP is much more suited and optimized for
 * there isn't really any significant time to be gained by doing some
of the processing on the DSP since it appears as though the bottleneck
will be the speed at which messages are carried through DSP/Link
 * this will result in cleaner and simpler to understand code since
the level at which processing is done on different processors doesn't
change from function to function
 * in the case of any modifications to the GPP side code (thinking of
the RPC framework as in general GPP-side function calling, not just
for POSIX calls which are very unlikely to change :)), there will be
no extra effort involved in keeping the DSP-side code up-to-date

This also means that the internal dependencies of POSIX functions
won't have to be taken into consideration regarding the order of
porting - the POSIX side wrappers will be dependent only on the GPP
side host code which is already there anyway. Therefore, a pragmatic
approach such as porting the generally most frequently used functions
can be taken.

OpenEmbedded on Ubuntu 10.04

NOTE: In light of the instructions received from Koen, the Angström head developer, you should avoid following the instructions below, since the deb-based OE is appearantly faulty by design and bitbake 1.10.x should be used instead of Ubuntu's one. Use these setup scripts to set-up your dev branch instead. I'm not deleting the post in case the same errors occur in some other way as well.

Now's the time to talk about...setting up OpenEmbedded on Ubuntu 10.04...and...building the Ångström distribution for the BeagleBoard! (I do realize I've created some suspense surrounding this particular subject with my previous posts, but despite the problems one may run into it's not that terrifying really :))


An advantage of setting up OE on Ubuntu (or any other .deb-based system, for that matter) is that one is able to use the apt-get'able OpenEmbedded. Following the instructions on the blog post (that is, get the repository in your sources list - sudo aptitude install openembedded-minimal - oe-setup-minimal org.openembedded.dev) the set-up part becomes a breeze - this will take care of all the necessary dependencies.


You may read from several sources that you absolutely shouldn't be using the bitbake that is in Ubuntu's own repositories (ie, things like DON'T sudo apt-get install bitbake) but from what I've seen, they've updated the repository and version 1.8.18 was directly available at the time of my writing this. You may want to check for yourself by executing bitbake --version once you have obtained the packages, anything over 1.8.16 should be fine.


Once you've set up the environment by executing oe-setup-minimal org.openembedded.dev (yes, using the dev branch is appearantly recommended, instead of the stable/2009 branch) you can make an attempt at trying out your new oven...oh, I mean, development environment, by trying out something smaller via giving this command:

MACHINE=beagleboard bitbake nano

While we're at it, we can take a short look at parts of this particular command. Not that it's that complicated but here goes anyway:

• OpenEmbedded supports a lot of different target platforms, so we should specify the platform we'll be targeting. This is what the MACHINE=beagleboard part is for.
• bitbake is the central make tool, used extensively in OpenEmbedded, and nano is the name of the "recipe" for the miniscule (but useful!) text editor. For a nice introduction to bitbake and its recipes system, you may want to read this.

Although nano itself isn't all that complicated, the build can take some time since the initial setting up of the toolchain and base libraries will also be done.

During the build process, you may run into several errors. I've documented the ones I've personally ran into and how I got over them.

Error #1: Extraction error while building expat

OE Message: ERROR: '/home/maltanar/oe/openembedded.org/recipes/expat/expat_2.0.1.bb' failed

Digging down a bit further reveals 

NOTE: Unpacking ../../sources/expat-2.0.1.tar.gz to ../../tmp/minimal/org.openembedded.dev/work/armv7a-oe-linux-gnueabi/expat-2.0.1-r3/

gzip: stdin: invalid compressed data--crc error

This is a known bug in the current gzip which appearantly affects several distributions on i386 computers. The workaround I did is as follows:

1. Install the gzip recovery tools: sudo apt-get install gzrt
2. cd into the OE sources folder ($OE_ROOT/sources, should be ~/oe/sources if you used the deb setup)
3. Run gzrecover expat-2.0.1.tar.gz; mv expat-2.0.1.tar.recovered expat-2.0.1.tar; gzip expat-2.0.1.tar and say yes to the overwrite
4. Generate the md5 and sha256 sums of the new file by running md5sum expat-2.0.1.tar.gz; sha256sum expat-2.0.1.tar.gz and note them somewhere. Edit the expat-2.0.1.tar.gz.md5 file to reflect the new MD5 checksum.
5. cd into oe/openembedded.org/recipes/expat then edit the expat_2.0.1.bb file in your favorite text editor - change the MD5 and SHA256 checksums there to reflect the new ones, and save.
6. Done! You can run MACHINE=beagleboard bitbake nano once again.

I didn't run into any more problems while building nano, and it was eventually successfully built. And now it's the time to try the bit-baking oven on something bigger...an image of the actual Ångström distribution. Sounds fancy? Well, it starts off as simple as

MACHINE=beagleboard bitbake -v console-image

provided that you want to start out with something simple, that is, the barebones console image. Notice the extra -v passed on the command line - it can be helpful to have a verbose bitbake while building something major.

I've also kept track of what happened during the console-image build process:

Error #2: Trouble with glibc version while building gtk+

OE Message: NOTE: Task failed: /home/maltanar/oe/tmp/minimal/org.openembedded.dev/work/i686-linux/gtk+-native-2.20.0-r8.0/temp/log.do_configure.11847

In more detail: 

| checking for BASE_DEPENDENCIES... configure: error: Package requirements (glib-2.0 >= 2.23.6    atk >= 1.29.2    pango >= 1.20    cairo >= 1.6) were not met:

| 

| Requested 'glib-2.0 >= 2.23.6' but version of GLib is 2.22.1

For some reason, although many newer glib-2.0 recipes are available, OE chooses the older ones. To solve this, I went into the oe/openembedded.org/recipes/glib-2.0 and deleted all the recipe (*.bb) files with the -native suffix (for example, glib-2.0-native_2.2.3.bb), and re-started the build process.

I don't understand it completely but I think the old -native suffixed recipes are sort of left-overs, since OE seems to be using the BBCLASSEXTEND = "native" flag for this purpose now (the non-suffixed recipes all have this).

Error #3: Trouble with mtd-utils build

OE error message: NOTE: Task failed: /home/maltanar/oe/tmp/minimal/org.openembedded.dev/work/i686-linux/mtd-utils-native-1.3.1-r0/temp/log.do_compile.6960

crc32.o: could not read symbols: File in wrong format

Not sure why this happened either. I cd'd into the mtd-utils source directory (oe/tmp/minimal/org.openembedded.dev/work/i686-linux/mtd-utils-native-1.3.1-r0/git) and ran make clean followed by MACHINE=beagleboard bitbake mtd-utils which did complete successfully this time.

After these (and several hours later) the process was complete, and I ended up with the rootfs, uImage and u-boot images in the oe/tmp/minimal/org.openembedded.dev/deploy/images directory! The uImage was still causing a kernel panic for me upon boot with a proper USB cable, so one may want to use the uImage from the /boot folder from the last BeagleBoard demo image as I mentioned in my previous post. Or maybe use an USB cable which isn't working :)

A bit about OpenEmbedded

My project's primary goal is making life easier for developers who want to develop for the DSP, and thus I need to familiarize myself as much as possible with how development cycle for OMAP3 systems (specifically for the BeagleBoard) is like in order to be able to understand the pain and suffering the developers undergo. And this, in turn, involves setting up OpenEmbedded, the toolchain/build framework which is the way to build the Ångström distribution from its source.

One might ask, why is a seperate build framework necessary in the first place? Isn't makefiles sufficient to carry out pretty much any build task? While I'm not exactly in the position to make expert comments on the subject, I can point out several things that would render such a seperate framework necessary:

• it makes cross-compilation (=compiling something on your machine that's going to run on some other processor/type of machine) easier since you don't have to manually obtain and set-up a compiler suite for the target machine
• building a whole Linux distribution from scratch can involve a lot of complicated internal dependencies between the things you're going to build, and this probably will mean things like a lot of downloading, untar'ing, strict order of building packages, making a lot of "make config"s and running recursive makefiles, and so on
• as a mixture of the two above, when you want to build a specific new package for your embedded device, the build framework also helps since it keeps track of changes and dependencies for these. 

So here's what OpenEmbedded (and bitbake, which is quite central to OE's workings) does for you: once you set it up properly, you just tell it "all right, I want the latest Ångström console image built for the BeagleBoard" and it downloads, configures and builds everything for you by itself! Isn't that great?

Well, of course, it's far from perfect - there might be some difficulties involved with setting it up properly, dealing with the errors that may occur during the build process, and running things for the first time tends to take very long, so be prepared to face a lot of frustration and have a lot of time in your hands (possibly even a second computer to do other things in parallel :)).

In my next post, I'll be describing my experiences about setting up OpenEmbedded in Ubuntu 10.04, solving the errors that may come up and similar. As of the time of writing, I was still trying to build the Ångström console image successfully and failing miserably, but I can at least see some light at the end of the tunnel :)

Ångström running on the Beagle

Once I got my Beagle communicating, it was time to get the penguins in (although later I found out that carrying out the actual verification process might have been a good idea - check here for the latest version of the official verification process).

Following the instructions on the beginners page on eLinux wiki, I decided to use XorA's script to make formatting the SD card easier. On my Ubuntu 10.04 machine, the 2GB Kingston card I used showed up as /dev/mmcblk0 and it was a simple matter of sudo-calling the script on it afterwards. I plugged out the card and put it back again, verifying that both partitions (boot and rootfs) were in place when Ubuntu displayed them on the desktop.

Next, I downloaded the latest Beagle demo image files from here, which were as follows:

• the latest rootfs archive, Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.rootfs.tar.bz2 
• the MLO file, MLO
• the modules archive, modules.tgz
• the u-boot image, u-boot.bin
• the kernel image, uImage

Then I followed the copy order present in the wiki (MLO, u-boot and uImage to the boot partition, copy and untar the rootfs into the rootfs partition, followed by copying and untar'ing the modules archive in the same place). My hands were getting sweaty as the big moment approached. Would I see the ASCII Ångström logo? Would I get kernel panics, or everything just freezing at some point while booting?

There was only one way to find out. I sudo'd up minicom, put in the SD card into the Beagle card reader, held down the USER button on my Beagle, and connected the Y USB cable...

And there it was! All to swiftly, the kernel uncompressed itself, set up, and a couple of ten seconds later I was greeted by the ASCII Ångström logo, prompting me for the username. I typed in "root" and got to the shell. After playing around for a little while with some commands and verifying that everything was working, I decided to try out setting up USB networking and then VNC'ing into the Beagle to see some GUI action. I set up an IP address on the Beagle side for the usb0 using ifconfig as described, then enabled the interface.

But something was wrong: my Ubuntu host didn't detect the Beagle at all! I looked at the dmesg kernel logs, the lsusb device listing, the network manager interfaces list...it simply wasn't there. I tried loading the usbnet and cdc_ether kernel modules manually on the host side, re-loading them on the Beagle side and many combinations of these actions in different orderings - none of which helped.

I was feeling quite depressed when Koen mentioned in #beagle that the problem might be a bad USB cable :)

Rummaging around the house, I found another USB A to mini B cable, and tried with that instead. Instantly, before the kernel had even booted up, it showed up as an USB gadget in the Ubuntu networking manager! I had just sighed with relief, but was just about to find out it's too soon...

It was time for...Kernel Panic!

[   17.127868] Unable to handle kernel NULL pointer dereference at virtual address 00000014
[   17.135986] pgd = c0004000
[   17.138732] [00000014] *pgd=00000000
[   17.142333] Internal error: Oops: 5 [#1] PREEMPT
[   17.146972] last sysfs file:
[   17.149963] Modules linked in:
[   17.153045] CPU: 0    Tainted: G        W   (2.6.32 #1)
[   17.158325] PC is at musb_interrupt+0x9f8/0xbb8
[   17.162902] LR is at musb_interrupt+0x9e4/0xbb8
[   17.167449] pc : []    lr : []    psr: 60000193
[   17.167449] sp : c0625ee0  ip : c0625f18  fp : 000000f0
[   17.178985] r10: 00000000  r9 : 00000099  r8 : 00000009
[   17.184234] r7 : 00000000  r6 : cf82f108  r5 : 00000001  r4 : 00000000
[   17.190795] r3 : 00000000  r2 : 00000000  r1 : fa0ab000  r0 : cf82f108
[   17.197357] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   17.204803] Control: 10c5387d  Table: 80004019  DAC: 00000017
[   17.210571] Process swapper (pid: 0, stack limit = 0xc06242f0)
[   17.216430] Stack: (0xc0625ee0 to 0xc0626000)
[   17.220825] 5ee0: 00000000 ffff6b60 00000000 c0684a28 c0624000 cf82f108 60000113 cf8a0a00
[   17.229064] 5f00: c0624000 0000005c 00000000 00000000 c066cfc0 c034101c 060db884 cf8a0a00
[   17.237274] 5f20: c063a5d8 c00a4e90 00000000 cf8a0a00 c063a5d8 0000005c 00000002 00000001
[   17.245513] 5f40: c0624000 0000001f 00000000 c00a7058 0000005c 00000000 c0627e84 c003c074
[   17.253723] 5f60: 00000001 ffffffff fa200000 c003cb44 00000000 80000013 80000013 00000000
[   17.261962] 5f80: c0624000 c0627fe0 c0627e84 c0670fcc 8002f790 411fc083 0000001f 00000000
[   17.270172] 5fa0: c06385c8 c0625fbc c004ca8c c004d2e4 60000013 ffffffff 00000000 c003dfc4
[   17.278411] 5fc0: 00000000 c06b80a0 c0670f90 c0032010 c0627e78 c0008984 c0008498 00000000
[   17.286621] 5fe0: 00000000 c0032010 10c53c7d c0671020 c0032414 80008034 00000000 00000000
[   17.294891] [] (musb_interrupt+0x9f8/0xbb8) from [] (generic_interrupt+0x64/0xa8)
[   17.304168] [] (generic_interrupt+0x64/0xa8) from [] (handle_IRQ_event+0xac/0x1ec)
[   17.313537] [] (handle_IRQ_event+0xac/0x1ec) from [] (handle_level_irq+0xbc/0x148)
[   17.322906] [] (handle_level_irq+0xbc/0x148) from [] (asm_do_IRQ+0x74/0x98)
[   17.331665] [] (asm_do_IRQ+0x74/0x98) from [] (__irq_svc+0x44/0xa8)
[   17.339721] Exception stack(0xc0625f70 to 0xc0625fb8)
[   17.344787] 5f60:                                     00000000 80000013 80000013 00000000
[   17.353027] 5f80: c0624000 c0627fe0 c0627e84 c0670fcc 8002f790 411fc083 0000001f 00000000
[   17.361236] 5fa0: c06385c8 c0625fbc c004ca8c c004d2e4 60000013 ffffffff
[   17.367919] [] (__irq_svc+0x44/0xa8) from [] (omap3_pm_idle+0x4c/0x50)
[   17.376220] [] (omap3_pm_idle+0x4c/0x50) from [<00000000>] (0x0)
[   17.383148] Code: e3530003 13a02000 05963078 05933018 (05d33014)
[   17.389343] ---[ end trace 650abcc06c2958fc ]---
[   17.394012] Kernel panic - not syncing: Fatal exception in interrupt

I'll admit that it wasn't very pleasant, and the fact that I could boot the kernel just fine with the "bad" USB cable was also a bit curious. I still don't know for sure why this particular kernel panic occurs, but it seems to be related with the USB gadget drivers (I don't think it's host-computer related, since I got exactly the same results using a Windows XP host as well. How I hate HyperTerminal).

Guessing that it's probably a kernel issue, I decided to go for the other closest kernel image I could get my hands on, which was really close indeed. In the rootfs, under the /boot directory was another uImage-2.6.32 so I just copied it to my computer, did a comparison with cmp against the uImage I had downloaded to make sure it wasn't the same (it wasn't), and finally replaced the uImage with the one from /boot. This did solve the kernel panic issue, and I was once again able to get to the shell. And this time, the USB networking was all functional! I first ssh'd into the Beagle to make sure everything was working, then I used Ubuntu's VNC viewer (called "Remote Desktop Viewer") to take a small tour of the Ångström Enlightenment GUI. All was fine and mellow :)

Coming Up Next: Setting up OpenEmbedded in Ubuntu 10.04

Setting up the BeagleBoard and the dev-env

My Beagle arrived some three days ago after waiting in the local DHL distribution hub for several days (something went wrong with the address). As can be imagined, I was quite happy about finally receiving it and immediately made some nerd porn (=unboxing photos) out of it. A handsome little board it is to be sure.

Next was a little cable nightmare to go through. The Beagle has various channels of communications available, but unfortunately the RS232 (serial) interface is somewhat compulsory to get the board going for the first time. Thus I went out hunting in Uppsala to find the AT/Everex (IDC-10 to DBM9) cable.

Doesn't look all that fancy, does it? The problem is that it's a bit old and it's not the kind of thing that one would come across in modern electronics stores. I tried several bigger boutiques like MediaMarkt, ELGiganten, ONOFF, then a number of smaller shops in town. Not a chance. I finally found it in a modding/hardware service kind of shop (the variant I bought, as seen above, allows the serial port to be "brought out" from the older motherboards) and bought a female-to-female null modem cable there as well. Voila!

Back home, I noticed that the input pin 10 in my cable was plugged - appearantly pin 10 is used neither on the Beagle nor the cable itself, so it's suggested to either remove the plug or cut away the pin 10 on the Beagle. I tried removing the plug on the cable with a hot needle but it put up quite a fight. And I didn't have needle-nose pliers, so I just bent pin 10 on the Beagle sideways instead. It looks a bit crocodile-ish but does the job (plus it gives reference together with the plugged corner of the cable so I can't plug in the cable backwards :)).

I set up minicom on my Ubuntu 10.04 system, connected the USB-to-serial adapter (which uses the profilic PL2303 kernel module and works without problems, by the way) to the null modem cable, connnected the Beagle to the null modem with the AT/Everex cable, plugged in the USB A to miniB cable, and got a warm welcome from the U-Boot already present on the NAND.

Coming up next: Ångström running on the Beagle and the importance of working and non-working USB cables.

So what's this all about?

My dear readers(-to-be), welcome once again to maltanar's scribbles. Aside from attempting a reclaim on the blogging world, this blog will also serve a more important purpose. Here will be my scribbles on my Google Summer of Code project, for the BeagleBoard, which was initially entitled, rather horrifically, RPC-Like POSIX Wrappers for DSPEasy. A better name is in the works, but in the meanwhile I'd like to tell you all what it's all about.

BeagleBoard is (and the Pandora will be) a powerhouse, thanks to its 3-core (a GPP - generic processing, a GPU - for graphics processing, and a DSP - for, let's say, heavy number crunching! the acronym itself means Digital Signal Processor) OMAP3530 system. Therefore laptop-like performance at handheld power levels is most certainly not a myth. But to be able to achieve true laptop-like performance, the power inside needs to be harnessed to the max.

Of course, thanks to the heterogenous multi-core architecture, there are quite a few different ways in which this power can be harnessed. What I'll be doing will be targeting the DSP. Or more accurately, I'll be doing something that targets (in a friendly way!) programmers that wish to develop for the DSP by doing their work easier.

Right now, making actual use of the DSP is rather cumbersome and even after once you've gotten started, the development cycle isn't exactly bliss: you can't just "printf" the results of your experimental FFT code to the screen, for example, since there is really none - you have to deal with the details of interprocessor communications to see what's going on inside the DSP, as well as put data inside.

My aim with this project will be to create a RPC (remote procedure call)-like framework, which can be used to call any GPP-side function from the DSP-side, and create a set of POSIX wrappers using this framework to make life easier for developers.

Actual status updates coming soon! :)