Breaking Free the Gumstix DSP
For a senior design project, I was part of a team that needed to process Fast Fourier Transforms on an embedded computer. Specifically, I chose to use the Gumstix Overo Fire because of the integrated Digital Signal Processor (DSP), which has Fast Fourier Transforms as part of the Texas Instruments API. While researching this project, I found the activation of the DSP on the Gumstix to be a relatively unexplored area. So using a combination of methods from the DSPBridge on the BeagleBoard, the Gumstix Developer and the PIXHAWK Project Web sites, I arrived at this method for compiling the Linux-2.6.33 kernel for the Gumstix Overo Fire with DSP support.
The Overo Fire comes with three processors: an ARM Cortex-A8 CPU, POWERVR SGX and C64x+ Digital Signal Processor core. While the ARM provides for the general-purpose processing, the Digital Signal Processor can be used to perform more mathematically intensive calculations. For this reason, the purpose of this article is to describe how to compile a Linux 2.6.33 kernel for the Gumstix Overo Fire to leverage the extra processing power of the DSP for future projects.
Go to the DSPBridge Project Wiki (www.omappedia.org/wiki/DSPBridge_Project), and follow the instructions for retrieving both the kernel-dspbridge and the userspace-dspbridge packages from the DSPbridge git repository, but do not issue any make command as mentioned in the tutorial on the Web page.
Download and install the Code Sourcery tool suite (specifically CodeSourcery G++ Lite 2008q3-72) and both bios_setuplinux_5_33_04.bin and ti_cgt_c6000_6.0.7_setup_linux_x86.bin packages from the Texas Instruments Web site. The Texas Instruments tools require a Texas Instruments user account in order to download. Installing both of the Texas Instrument Tools in the same directory will help with configuring the $DEPOT variable later.
An additional tool needed for compiling the DSP image for the Gumstix is u-boot from Steve's Beagles U-boot git repository. Use the following commands:
git clone git://gitorious.org/u-boot-omap3/mainline.git u-boot-omap3 cd u-boot-omap3 git checkout --track -b omap3-dev origin/omap3-dev
Or, go to www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary and download the packages there.
Next, change into the newly installed u-boot directory and issue the make tools command in order to compile mkimage, which later will be used to create a uImage. Ensure that the OpenEmbedded and bitbake programming suites are installed for the Overo Gumstix profile. Use the default config for the Linux 2.6.33 kernel as the starting config of the new DSP-enabled kernel. Installation instructions for OpenEmbedded and bitbake can be found at www.gumstix.org/software-development/open-embedded/61-using-the-open-embedded-build-system.html.
Finally, create an SDRAM card with a bootable Gumstix image. Instructions for creating a bootable SDRAM card can be found at www.gumstix.org/create-a-bootable-microsd-card.html.
To set up the compilation environment, point the CROSS_COMPILE variable at the Code Sourcery tool suite using the command:
export CROSS_COMPILE= <path to tool suite>/CodeSourcery/ ↪Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-
and the DEPOT variable with the command:
export DEPOT=<path to TI tools>/
Additionally, set the architecture of the device to ARM using the command export ARCH=arm, and add the u-boot directory and cross compilers to the path using the commands:
PATH=<path to u-boot directory>/u-boot-omap3/ ↪tools:<path to tool suite>/CodeSourcery/ Sourcery_G++_Lite/bin:$PATH
Before compiling the kernel, reset the git repository from the current branch to the Linux 2.6.33 kernel to make it compatible with the Gumstix configuration file. (At the time of this writing, the default DSPbridge is set to Linux 2.6.37.) First, issue the git branch command and check out the current DSPbridge branch. Now, issue:
git reset - -hard 85343cd5491260881b34ab7bb7cdc8fdeef078e4
After the branch is reset, check the Makefile for the proper Linux information at the top. In order to keep the kernel size to a minimum, build the kernel in an output directory, which will be referred to as the production directory for the remainder of this article. Now, copy the default config for the Gumstix from OpenEmbedded into the production directory as the .config file. The purpose of this is to configure the basic structure of the Gumstix before adding the DSPbridge libraries. The command should look something like this:
cp <path to openembedded>/org.openembedded.dev/recipes/ ↪linux/linux-omap3-2.6.33/Overo/defconfig <path to "production" directory>/.config
Next, issue the make oldconfig command, which is used to update the current .config file with new options. Generally, the default responses to the questions are acceptable, except in the highlighted cases shown in Figure 1.
Note that the ellipses in Figure 1 are used to indicate breaks in the output for display purposes. Now, issue the make menuconfig command, which will launch a configuration interface in the terminal, such as the one shown in Figure 2.
Navigate to the device drivers option (also shown in Figure 2), press Enter, and navigate to the Graphics Support option (Figure 3), and press Enter.
Now, deselect all the options in Graphics support by highlighting the option and pressing the N key. (The Backlight and LCD Driver support cannot be disabled, but all other options can be, as shown in Figure 4.)
These drivers, if left selected, will cause a compilation error while making the uImage in the core directory of the kernel. By disabling them, the kernel should compile.
Next, issue the make uImage command and wait for the end of the compilation. This compiles a specially wrapped zImage that is used by u-boot during the booting processes for the Gumstix.
Then, issue the make modules command to compile all the kernel modules. This completes the compilation of all the necessary libraries to activate the DSP on the kernel side.
Now, compress the production directory with the compiled uImage and the kernel modules in order to deploy on the Gumstix. A recursive copy will not work, because it will break several links inside the newly compiled uImage and modules. The preferred method is to tarball the directory using tar cvjf <production directory>.tar.bz2 <production directory>.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Nice article, thanks for the
7 hours 26 min ago - I once had a better way I
13 hours 12 min ago - Not only you I too assumed
13 hours 30 min ago - another very interesting
15 hours 23 min ago - Reply to comment | Linux Journal
17 hours 16 min ago - Reply to comment | Linux Journal
1 day 10 min ago - Reply to comment | Linux Journal
1 day 27 min ago - Favorite (and easily brute-forced) pw's
1 day 2 hours ago - Have you tried Boxen? It's a
1 day 8 hours ago - seo services in india
1 day 12 hours ago








Comments
Very interesting read on the DSP portion of OMAP35xx
Thank you very much for this article.
This is the only article that I found with guided instruction for using the DSP portion of OMAP35xx.
What is lacking is a following up to version 2.6.39 or above which incorporate some simple raw image sensor capturing like PixHawk and using the DSP engine for simple test case.
Keep exploring and post a update to the latest stable kernel
Cheers~!
Very interesting read on the DSP portion of OMAP35xx
Thank you very much for this article.
This is the only article that I found with guided instruction for using the DSP portion of OMAP35xx.
What is lacking is a following up to version 2.6.39 or above which incorporate some simple raw image sensor capturing like PixHawk and using the DSP engine for simple test case.
Keep exploring and post a update to the latest stable kernel
Cheers~!
Nice article, I was looking
Nice article, I was looking for these kind of information on site accessibility.
Please continue writing....
Thanks
Software Development India