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.

Advertisements

4 responses to “Beagleboard xM 1 GHz operation – safely and reliably

  1. Dear sir, may i asking your help? about patch for erratum fix for beagleboard-xm?

    I had download the patch from:
    https://raw.github.com/Teknoman117/beagleboardxm-kernel/cb5244c7db7db50b5220ab7aec4a5a5495a31bb3/patches/omap_sprz319_erratum_v2.1/0001-hack-omap-clockk-dpll5-apply-sprz319e-2.1-erratum-kernel-3.11-rc2.patch

    and i command with
    patch -p1 < 0001-hack-omap-clockk-dpll5-apply-sprz319e-2.1-erratum-kernel-3.11-rc2.patch

    and the system reply with:
    File to patch:


    is this mean the system request the directory of image file?

    • I believe this means that you are in the wrong directory and it could not find the patch. I made the patch files assuming that the patch command is being run from the root directory of the kernel source tree. So if you execute the above command from the root directory of the kernel tree, you should be fine. But the beagleboardxm-kernel repository is setup with scripts to automatically patch and build the kernel.

      – Nathaniel Lewis

  2. Hi,

    Please could you tell me which gcc version you use to build your kernels?

    Thanks for all your hard work. I have been too scared to leave kernel 2.6.32 for many years but am going to give 1Ghz a go on an up to date kernel now 🙂

    – Mark

    • I’m currently using gcc 4.7.2 and binutils 2.22. I built my toolchain via Crosstool-ng because I’m running on OpenSUSE. If you are using ubuntu, there is an arm version ofgcc-arm-linux-gnueabihf gcc in the standard repositories (gcc-arm-linux-gnueabihf) which i’ve used in the past to compile the kernel.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s