Beagleboard xM 1 GHz operation – safely and reliably

Over the past couple of days, I’ve been reading on the beagleboard.org 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 (https://github.com/Teknoman117/beagleboardxm-kernel/blob/v3.11.x/patches/drivers/0005-ARM-dts-omap-clock-bindings-driver.patch).  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 (http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04079.html) 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 (https://github.com/Teknoman117/beagleboardxm-kernel/blob/v3.11.x/patches/omap/0014-ARM-dts-omap3-add-clock-bindings-to-dts.patch).  I just created references to the required clock for the system clock, and then according to this post (http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04074.html) 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 (https://github.com/Teknoman117/beagleboardxm-kernel/blob/v3.11.x/patches/omap/0015-ARM-dts-omap-boot-support-cpu0-cpufreq.patch).  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 (https://github.com/Teknoman117/beagleboardxm-kernel/blob/v3.11.x/patches/omap/0016-ARM-dts-omap3-beagle-xm-add-opp1g-abb-bindings.patch).  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

beagleboard_xm_1ghz

These patches have been merged into the https://github.com/RobertCNelson/armv7-multiplatform v3.11.x branch, so to build a kernel, checkout the v3.11.x branch

nathaniel@Sedenion:~> git clone https://github.com/RobertCNelson/armv7-multiplatform.git

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

 fdtfile=omap3-beagle-xm.dtb

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 – https://github.com/Teknoman117/beagleboardxm-kernel/blob/v3.11.x/patches/omap_sprz319_erratum_v2.1/0001-hack-omap-clockk-dpll5-apply-sprz319e-2.1-erratum-kernel-3.11-rc2.patch.  Make sure to uncomment it in patch.sh before running build_kernel.sh.  It is disabled by default because it breaks support for the older Beagleboard (not xM) series.

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:

https://github.com/Teknoman117/kybernetes

Kybernetes Linux Kernel:

https://github.com/Teknoman117/kybernetes-kernel