February 7 – 15, 2012 – Kernel Compile, Assorted

Last few lab days have felt fairly uneventful. We finished soldering the power supply together for all the +5V electronics and tested the device to ensure a stable output. Additionally we added the propellers to the copter so that we can begin flying the vehicle around, once rotor guards are figured out.

Last week we determined that we would need to recompile the Linux kernel and U-Boot to properly modify the multiplexer settings. We are using a Linux Kernel 3.0.0 RC2 codebase with the DSP Bridge kernel driver code included. Also installed were the ncurses header files for menuconfig. The codebase can be obtained from git:

git clone git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git

Basic compilation process works like this:

make distclean
make ARCH=arm omap2plus_defconfig
make ARCH=arm menuconfig
make ARCH=arm CROSS_COMPILE=~/armgnu/arm-none-linux-gnueabi- uImage
make ARCH=arm CROSS_COMPILE=~/armgnu/arm-none-linux-gnueabi- modules

Line 1 cleans the source directories of all the generated object and configuration files, as well as final outputs.
Lines 2 and 3 setup the build configuration file which will determine which kernel features will be compiled in the final image. During the menuconfig step we need to enable the DSP Bridge Driver which is found under Device Drivers -> Staging Drivers -> DSP Bridge Driver. Note that Staging Drivers needs to be enabled and Exclude Staging Drivers From Being Built needs to be disabled.
Lines 4 and 5 compile the kernel image and any necessary kernel modules. The CROSS_COMPILE options indicates the location of the proper cross compiler. I chose to link a folder in my home directory (armgnu) to the bin folder for Code Sourcery. arm-gnu-none-linux-gnueabi- is a prefix attached to gcc and related binaries to indicate the proper cross compiler.

The above obviously builds ONLY the kernel image and modules and not any supporting programs and utilities.

On Tuesday the 14th Nelson started recompiling the Angstrom distribution on my laptop using Open Embedded. The process took a very long time, at least 6 hours. During this time I worked on finding a way to access the GPIO pins without modifying the kernel image. As it turns out the GPIO is abstracted into a file just like every other device. By writing single values of 1 or 0 to the proper file (one per pin) the state can be toggled. Currently I am writing some test code to determine exactly which pins will be usable on the expansion header for PWM. Once the pins have been determined I will be testing the timing precision available in the nanosleep() system function and delays inherent in accessing the pins through the OS. If no changes are required we will be able to use the foundation code as the framework for our end project. Code will be posted in a file on Thursday if completed.