Beagleboard xM 1 GHz operation – safely and reliably

Over the past couple of days, I’ve been reading on the blog about the 3.11-rc2 kernel coming out and that it contained a new driver, ti-abb-regulator (adaptive body bias), which allows the omap chips to adjust their operating voltages for different operating frequencies.  Combined with the smart reflex class 3 driver (which has been in the kernel since 3.6), allows for the safe operation of the beagleboard xM at 1 GHz – finally.  Its been a long time coming since the last time it was safe was kernel 3.0.28 back in early 2012.  The process of enabling 1 GHz operating comes in 4 parts.

First, since the TI abb driver bindings are for the device tree based boot only, we need to bring in some resources for the device tree (  The abb driver requires a reference to the system clock, as in hardware that what drives it.  I began to code one up myself, and then looking for information on that, I stumbled into a post from April 2013 ( containing such a driver.  So I pulled that resource in which provides the ability to bring in the OMAP clocks references into the device tree.  Sweet!

Second, we dive into the device tree.  We now need to add the system clock binding to our definition of the omap3 CPU (  I just created references to the required clock for the system clock, and then according to this post ( one needs to add a reference to the CPU dpll1 clock for the cpu frequency driver.  Okay!

Third, we need to modify the power management startup for the omap processor (  By default, it will only load a cpu-freq driver when performing a non-dts based boot.  This is a problem.  So we tell the power management driver to always initialize the cpu-freq system and modify the initialize function to load the legacy cpu-freq driver when performing a non-dts boot and to load the new cpu0-cpufreq SoC generic driver if performing a dts based boot.

Fourth, we need to add the abb bindings for the beagleboard xm into omap3-beagle-xm.dts (  This consists of two modifications, 1) adding the ti-abb-regulator driver and 2) adding the frequency and core voltage values for OPP1G, the 1 GHz operating point of the OMAP36xx/OMAP37xx CPUs.  After this modification, the beagleboard xM can boot supporting 1 GHz under the device tree based boot.

Screenshot of the cpu-freq info for these patches


These patches have been merged into the v3.11.x branch, so to build a kernel, checkout the v3.11.x branch

nathaniel@Sedenion:~> git clone

nathaniel@Sedenion:~> git checkout origin/v3.11.x -b v3.11.x

and then follow the standard build instructions provided in the README.

After you build the kernel, you need to modify the uEnv.txt file to enable the dts based boot.  At the bottom of  uEnv.txt, comment out this line

uenvcmd=run boot_classic; run device_args; bootz 0x80300000 0x81600000:${initrd_size}

and uncomment this line.

uenvcmd=run boot_ftd; run device_args; bootz 0x80300000 0x81600000:${initrd_size} 0x815f0000

When I was messing around, the bootloader seemed to fail to detect the dtb to use for the current board, so you can force it by adding this line at the beginning of the file


There is still an annoying issue currently, not with the operating frequency, but with the USB ports on the board.  The sprz319 erratum patch has not yet been ported to 3.11 yet, so until I finish that, not stable usb ports.  It probably will take a few hours, but it shouldn’t be so hard.  Happy coding!

Edit: I have ported the sprz319 erratum patch to the beagleboard xM –  Make sure to uncomment it in before running  It is disabled by default because it breaks support for the older Beagleboard (not xM) series.

Using python as a shell

I have absolutely no idea if this is useful for anyone (embedded systems?), but I was creating a user on the new OS image i’m using for my Beagleboard xM and wondered what would happen if I specified python as the login shell for a user.  So anyway, it worked, and you get the python shell when you log into the system.


Using a Beaglebone with an HC-SR04 sonar

Over the last couple of days, now that Robogames 2013 has come and gone, I’ve been working on projects that are more experiments than anything else.  A few weeks before Robogames, I noticed that there were sonars for real cheap on  At the time I didn’t realize that these were all over the internet and are essentially a cheap Chinese knockoff of devices like the Ping))) and SRF04/5.  These things are dirt cheap, buying in bulk from Ebay can lead gets you prices approaching $1.50 a unit.  Seems insane because I once bought a 5 pack of Ping)))s for $100, but one can by a pack of 10 of these little guys for $15.  Needless to say I didn’t have high expectations for them.  So I ordered a couple so that I could test against my collection of Ping)))s and SRF04s.  Much to my surprise, they perform just as well as the Ping))) and the SRF04.  I don’t know how long they will be available at this price, so I ordered a whole lot more of them.  Their interface is the same as an SRF05, and you can connect the trigger pin and the echo pin and use only one I/O line per sonar, giving it the same interface as a Ping))).  One of my personal side projects is the Beaglebot, a small, tabletop or hardwood roving bot that I want to entirely operate using the Beaglebone, as in, without external AVRs, arduinos, etc.  So I set out to understanding Linux kernel development so that I could write kernel drivers for all of my hardware.  I was very happy to discover that kernel module development is actually really easy, nothing like driver development is with Windows.  Within a week I had an LED driven by PWM and you could control its max brightness and blink rate from sysfs.  At this point I was feeling confident enough to tackle driving a sonar from my Beaglebone.  My testing of the sonars previously had used an Arduino Uno and interrupts to keep the CPU free from having to wait on the sonars to respond and to be able to do stuff during measurements, etc.  This is exactly how you should write drivers for operating systems.  So I wrote my sonar driver.  And when I loaded it up and debugged it as best I could, I was disheartened that I could not get the sonar working properly, for I was getting extremely variant or random measurements.  With all of my experience with microcontrollers, my thought had been that interrupt handlers would execute when interrupts occurred, but it’s a bit more complicated than that.  Interrupts aren’t handled immediately, but rather put onto a queue which is sorted by priority and processed sequentially.  This is not good for a device where its input is time dependent.  So I began to explore other options and discovered that the Beaglebone has two high speed microcontroller cores, known as PRUs (Programmable Realtime Units), built into the CPU that can access the entirety of the memory map, meaning that they can access all of the memory, all of the IO, and the communications buses.  They both have an interrupt to the CPU so that they can signal when they’ve completed some action, in this case, that the sonar has taken a reading.  Before toying with the code, we have to hook up the sonar to the Beaglebone.  The HC-SR04 is a 5V device, and will not operate at any less than that.  As the beaglebone, along with every other ARM Cortex based system, has a maximum voltage of 3.3V, we have to protect the beaglebone from the sonar.  Essentially all I did for this was connect an NPN transistor between one of the beaglebone’s IO pins and ground.  This is fine considering that each of the IO lines on the beaglebone has a configurable pullup or pulldown resistor, we just have to note that the signal is now inverted.  The base of the transistor is connected through a 220 ohm resistor to the echo line of the sonar.  From experimenting, turns out 3.3V is enough to cause the sonar to trigger, so we can hook one of the beaglebone’s IO lines right up to the trigger pin.  The schematic is essentially this


And this is what the  setup looks like



The software I have provided on github assumes that the sonar’s trigger is using GPIO1_6 and the inverted echo signal is on GPIO1_7.  The operation of the HC-SR04 sonar is fairly straight forward.  One sends a trigger pulse of at least 10 microseconds.  The device then waits for the echo line to activate (in our inverted case, high to low transition) and measures the time from there until it deactivates (low to high in our case).  This time is the round trip flight time of the sonar pulse.  Divide this number by 58, and you have the distance to target in centimeters.

The code on the Beaglebone side is a bit less straightforward.  Unfortunately there is no higher level language available for the PRU than PRU Assembler.  Oh well I suppose.  The guide on how to use the sample code is here on my github:  In the mean time, here is a YouTube video of my sonar code in action

Kybernetes at Robogames 2013

Kybernetes is a robot I created at UC Merced for the Robotics Society. Up until now I have been the principle developer of both hardware and software, but we are working on teaching all of our members about hardware and/or software so the burden isn’t entirely on my shoulders. Either way, we placed second at Robogames by getting within 7 feet from the goal cone. Didn’t manage to complete the course for two reasons – We had a power problem and I spent three hours working on a solution with the spare parts I had, and the vision was not so great because I hadn’t had a chance to calibrate it, because I completed the software between our second and third run, in which our IMU malfunctioned and botched the run. A lot of work and love went into Kybernetes, and its practically been my pet this semester. It accompanies me to class many days because I worked on it during my sporadic free time. I’ve open sourced all of the code, because I like to share my work. One of the interesting things about Kybernetes is that I am optimizing the software for Linux and the ARM architecture, and am building a lightweight, optimized alternative to ROS on ARM platforms.

Kybernetes Software:

Kybernetes Linux Kernel:

Work to bring the Beagleboard xM to full frequency under Linux 3.2.28 and beyond.

Well the owners and fans of the Beagleboard xM have a bit of a dilema when it comes to picking a version of Linux to run on their boards.  Many of you, including myself are quite annoyed that the big dog is clocked down when running a current version of Ubuntu or Angstrom.  For instance, the other day I installed the latest build of Ubuntu 12.04-r5 for armhf on my board and was quite unhappy to learn that the maximum frequency was capped at 800 MHz with the board being advertised as delivering a 1 GHz arm computer.  The SD card that ships with the board allows for this, but it uses an older version of the Linux kernel, 3.0.x.  The current stable is kernel 3.5.3.  Well, I don’t know if its just me, but I want to squeeze every last instruction per second that it will allow me.  So upon searching the internet for days, I came across this one blog:

It provides a custom buildroot setup that for some camera hardware directly attached to the Beagleboard-xM’s camera capture lines.  But the thing I noticed mainly about it when I tried it was that the board was operating at 1 GHz, and on kernel 3.2.7.  So upon further inspection I found the patches that they were using to increase the top frequency.  So I forked Robert Nelson’s stable kernel repository, which can build one of the latest stable kernels, and I’ve personally tested it for Ubuntu and Angstrom.  It also includes the patches for the xM which keep the USB ports from shutting down randomly.  I integrated the patches into my fork and modified them a bit to fit into the later kernel, and after a little wait for building, I had Ubuntu 12.04 for armhf operating with the 3.2.28-x14 kernel.  You can find my repository for this at: (edit: Kybernetes uses the 3.5.7 kernel now, the repo reflects this update)

However, before you get all excited, its not quite done yet.

Note #1 – Don’t use this on a Beaglebone or original beagleboard.  There is this patch enabled (0002-Fix-sprz319-erratum-2.1.patch) which fixes the xM’s usb problems.  However is will cause the other beagleboards not to boot at all.

Note #2 – I talked with Robert Nelson about my patches and without further work they could potentially damage your Beagleboard xM.  The automatic voltage scaling (Smart Reflex) does not work properly for the OMAP 3 on recent linux kernels, at least for the beagleboard.  The people over at TI and the people working on Angstrom have patches for this that make it completely safe to run at 1 GHz, however the patches are for Linux 3.0.x and there are over a hundred of them and many are hundred of lines long.  Some of them will probably patch into 3.2 properly, and some will definitely not.   So before this works, I am going to have to figure out what works and what doesn’t and integrate this into the kernel.  I will do this for kernel 3.4, because they have completely changed the AVS system in 3.6 entirely.  So if I am going to do this work, then I will do it for the current kernel version because otherwise it would be a waste.  So keep following because I am taking this on!

– Teknoman117

C++ Plugins with Boost::Function on Linux

Over the past few weeks, one of the concepts that I’ve been experimenting with is plugin architecture.  The idea of having a core application which can be extended by shared objects without recompiling the core program.  Or, possibly, a way of defining more services in an application based around plugins.  What I’ve done so far hasn’t been much, but, I haven’t spent much time working on it.  When I started out on researching it, one of the things I wanted was to be able to was define a C++ object in a plugin and be able to instantiate that object in the main program.  So, this is what I have come up with.  There are three parts of this solution: the plugin class definition in plugin.hpp, the plugin in someplugin.cpp, and the loader code in loader.cpp.  I’ve also included a CMakeLists.txt file to compile it with cmake.


#ifndef _PLUGIN_HPP_
#define _PLUGIN_HPP_

#include <string>

namespace plugins
  class Plugin 
    virtual std::string toString() = 0;



#include "plugin.hpp"

namespace plugins
  class AwesomePlugin : public Plugin
    // A function to do something, so we can demonstrate the plugin
    std::string toString()
      return std::string("Coming from awesome plugin");

extern "C" 
  // Function to return an instance of a new AwesomePlugin object
  plugins::Plugin* construct()
    return new plugins::AwesomePlugin();


#include <iostream>
#include <vector>
#include <dlfcn.h>
#include <boost/function.hpp>

#include "plugin.hpp"

typedef std::vector<std::string>             StringVector;
typedef boost::function<plugins::Plugin* ()> pluginConstructor;

int main (int argc, char** argv)
  // Assemble the names of plugins to load
  StringVector plugins;
  for(int i = 1; i < argc; i++)

  // Iterate through all the plugins and call construct and use an instance
  for(StringVector::iterator it = plugins.begin(); it != plugins.end(); it++)
    // Alert that we are attempting to load a plugin
    std::cout << "Loading plugin \"" << *it << "\"" << it->c_str() << std::endl;

    // Load the plugin's .so file
    void *handle = NULL;
    if(!(handle = dlopen(it->c_str(), RTLD_LAZY)))
      std::cerr << "Plugin: " << dlerror() << std::endl;

    // Get the pluginConstructor function
    pluginConstructor construct = (plugins::Plugin* (*)(void)) dlsym(handle, "construct");
    char *error = NULL;
    if((error = dlerror()))
      std::cerr << "Plugin: " << dlerror() << std::endl;

    // Construct a plugin
    plugins::Plugin *plugin = construct();
    std::cout << "[Plugin " << *it << "] " << plugin->toString() << std::endl;
    delete plugin;

    // Close the plugin

  return 0;


# Project Stuff
cmake_minimum_required (VERSION 2.6)
project (PluginDemo)

# Default Options

# Find Boost
find_package(Boost REQUIRED)

# Pull in the project includes
set(LIBS ${LIBS} pthread boost_thread rt)

# Build the plugin experiment
add_executable(pluginloader src/loader.cpp)
target_link_libraries(pluginloader ${LIBS} dl)
add_library(awesomeplugin SHARED src/awesomeplugin.cpp)

Basically create a directory with the folders bin, lib, and src. Put loader.cpp, awesomeplugin.cpp, and plugin.hpp in src, and CMakeLists.txt in the directory. Open a terminal and run “cmake . && make”. Run the pluginloader program and pass it the path to the plugin’s .so in the lib folder. Here is the output from my computer.

nathaniel@XtremePC:~/Programming/Experimentation> cmake .
— The C compiler identification is GNU
— The CXX compiler identification is GNU
— Check for working C compiler: /usr/bin/gcc
— Check for working C compiler: /usr/bin/gcc — works
— Detecting C compiler ABI info
— Detecting C compiler ABI info – done
— Check for working CXX compiler: /usr/bin/c++
— Check for working CXX compiler: /usr/bin/c++ — works
— Detecting CXX compiler ABI info
— Detecting CXX compiler ABI info – done
— Boost version: 1.46.1
— Configuring done
— Generating done
— Build files have been written to: /home/nathaniel/Programming/Experimentation
nathaniel@XtremePC:~/Programming/Experimentation> make
Scanning dependencies of target awesomeplugin
[ 50%] Building CXX object CMakeFiles/awesomeplugin.dir/Plugins/awesomeplugin.cpp.o
Linking CXX shared library lib/
[ 50%] Built target awesomeplugin
Scanning dependencies of target pluginloader
[100%] Building CXX object CMakeFiles/pluginloader.dir/Plugins/loader.cpp.o
Linking CXX executable bin/pluginloader
[100%] Built target pluginloader
nathaniel@XtremePC:~/Programming/Experimentation> bin/pluginloader lib/
Loading plugin “lib/”
[Plugin lib/] Coming from awesome plugin

– Teknoman117

Nvidia system with 3 monitors

Last year (2011), when I graduated high school, my school was going through a huge overhaul of the campus.  The old campus had been slowly been being destroyed as new buildings had been built.  That said, they also went though a shift in the technological resources.  They decided to write off or just plain junk a significant portion of the old computers (P4 era Dell Optiplex machines) and I happened to obtain two 17″ TFT panel LCD screens.  I bring them home thinking I’ll do something with them in the future.  I happened to be working with a upstart gaming studio, E1FTW Games (, that summer (i still am) and I had an iMac on my desk so I did nothing with the monitors.  After I left for college, I used the pair of them with an old eMachines computer that my family had long since forgotten about as my computer when I was at home because my primary (most awesome) computer I had brought with me to college, and resided in my dorm room.  When I finished my first year, I live (am still as of July, 2012) at my parent and I set my big computer back up.  I use a 1080p 23.5″ LCD tv as my primary monitor, but I seriously wanted to use the pair of monitors I had with my desktop.  Much to my dismay, Nvidia GPUs only support 2 monitors per chip, so, even though I had the three monitors on my desk, only the 23.5″ panel worked along with one of the smaller screens.  So, here I was trying to find the cheapest Nvidia gpu I could that would fit into a PCIe x1 slot.  Much to my surprise, they cost more than their PCIe x16 counterparts, something I regard as pretty damn stupid.  So I was searching for one that would fit in the PCI bus.  They were even more than the PCIe x1 cards.  It just wasn’t fair.  So I was lining up to buy a GeForce GT 430 for something like $80 that slotted in a PCI socket.  I was pretty bummed that this was the only solution, but then I had an idea.  PCIe is supposed to be failure tolerant.  If one of the channels goes dead, it just isolates the problem by ignoring the fact that it exists.  So I had a though – could I stick a PCIe x16 card in a PCIe x1 slot and operate a just a 1/16th the bandwith?  Sure enough, there were websites all over the internet that described cutting the end of the PCIe x1 slot off and placing in a PCIe x16 card.  I decided to try it out, and what do you know, it worked.  So here are some pictures.

All the screens loaded up onto my desk

My desktop. It doesn’t look like much, but its my trusty computer.

the eMachines computer that again I’m stripping of its GeForce 7300 gs graphics card

This is one of the most confused pieces of computing hardware I’ve ever owned. Its labeled as a GeForce 7200 GS, but its been identified as either that OR a GeForce 7300 SE (not a typo)

Targeted a PCIe x1 slot for chopping

Both cards, a GeForce GTX 560 2gb (the primary card) and the GeForce 7200/7300 gs installed

Viewing Steam and a test website under Chrome on the monitors plugged into the 7200 gs and running the Nvidia fluids demo on the primary monitor. Fun fact – the fluids demo runs fine on the old cards too, because it uses the GTX 560 to run the physics

Both GPUs identified in Furmark under Windows 7

World of Tanks up on the center monitor and stuff on the sides

All three monitors up and working under OpenSUSE 12.1 with the nvidia 295.59 drivers installed. This is under Xinerama, which I ended up disabling, see below

There was one unforeseen side effect of running the GPUs under Linux (my OS of choice).  I was trying to use Xinerama to make one contiguous display so I could do the awesome extended desktop thing, but alas, it was not to be, considering that I am using two widely varied cards.  The GeForce 7300 card is so old, it was available before Windows XP had any service packs.  It doesn’t even use shading processors.  It can only run one shader script at a time and has vertex, fragment, and geometry units straight on the card – its a DX9 GPU.  The primary card is a GeForce GTX 560.  A card with 8 times the amount of memory that runs 100s of times, 336 CUDA cores, and supports DX11 and OpenGL 4.x.  So compositing did not work and GL was disabled on the displays because it wasn’t compatible with main card, in turn because not all cards had GL, KDE wouldn’t run the effects manager.  This resulted in really slow window operations, the UI was so very laggy.  So I decided to give separate X screen a go.  It works flawlessly.  Windows may be locked to their respective screens, but its not at all bad.  Kwin places new windows in the screen where the mouse is when the application is launched.  Although, i do wish that when I want a new chromium window I could put it in another screen without having to run DISPLAY=”:0.2″ chromium from the console all the time when its already launched in another X screen.  I spend a lot of time in the console though, so its not really too bad.  Beats having only one monitor.  Since I chose to do it this way, OpenGL applications are supported in all the windows and they start by default unless instructed otherwise on the primary screen.  Fullscreen OpenGL applications on the two side monitors are unpredictable and unstable, but just fine on the center screen, driven my the massive GPU.  All in all, its an awesome setup and I love it. Linux had come a long way since its conception and now with Unity3D, a very popular game engine, officially supporting Linux and Autodesk releasing their 3D software for Linux (such as Maya), maybe Windows will start loosing its stranglehold on gaming.

– Teknoman117