kernel compiling

So by now there are real limitations to the demo kernel's available and I have been really wanting to enable some of the missing features as well as disable things I don't need.



EDIT:  The below links are broken. go here instead:

http://eewiki.net/display/linuxonarm/BeagleBone+Black

The best and most recent tutorial I've found on compiling the kernel is http://wiki.replicape.com/index.php?title=Compile_kernel_3.12 see also http://wiki.replicape.com/index.php?title=Compiling_the_kernel I'll copy his stuff to here just in case it gets deleted.

 Get and patch the kernel:
 git clone https://github.com/beagleboard/kernel.git 3.12
 cd 3.12
 git checkout origin/3.12 -b 3.12
 ./patch.sh

Compile the kernel:
 cd kernel
 cp ../configs/beaglebone .config
 make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- LOADADDR=0x80008000 uImage dtbs
 make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- modules
 mkdir rootfs
 make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- INSTALL_MOD_PATH=./rootfs modules_install

Install the kernel on your BeagleBone:
 scp arch/arm/boot/uImage root@192.168.7.2:/boot/uImage-3.12.0
 scp arch/arm/boot/dts/am335x-bone*.dtb root@192.168.7.2:/boot/
 rm rootfs/lib/modules/3.12*/build
 rm rootfs/lib/modules/3.12*/source
 scp -r rootfs/lib/modules/3.12* root@192.168.7.2:/lib/modules/

Log in, move link, sync and reboot:
 ssh root@192.168.7.2
 cd /boot/
 rm uImage
 ln -s uImage-3.12.0 uImage
 sync
 reboot

Power Management

Update:
After much screwing around building custom kernels.  I have managed to get the board to standby and wakeup from the uart0.

http://processors.wiki.ti.com/index.php/AM335x_Power_Management_Standby_User%27s_Guide

Is the important link.  But first I had to load the 6.0 SDK version onto the BBB and power the device from the barrel jack.  For some reason it won't boot without the usb plugged in but whatever at least it's progress. I have it down to 25mA@5V on standby. Which isn't bad.  Still not as advertised.  Plus using the dying 3.2 linux kernel is a bit of a pain.

I had to do this for standby:

mkdir -p /debugfs
   mount -t debugfs debugfs /debugfs
   cd /debugfs/omap_mux/board/
   echo uart0_rxd.gpio1_10=0x27,rising > standby_gpio_pad_conf
   echo standby > /sys/power/state

cd /debugfs/omap_mux/board/suspend_io_pad_conf

echo 1 > enable*

echo xdma_event_intr0.gpio0_19=0x27 > suspend_pad_conf

echo xdma_event_intr1.gpio0_20=0x27 > suspend_pad_conf

Much of this is extracted from here also here and here.  To save you the trouble and provide what I think is useful here is a summary of the command line stuff you can do and eventually from c/c++.

Note: I found that I had a kernel dated 2013-06-20, I have updated to one from 2013-09-12.

First we will check out the frequency scaling.  Look under:

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

cpufreq-set --governor ondemand
cpufreq-set --governor powersave




 Check out all of the different file contents there. By default the frequency scales with demand from 300kHz all the way to 1Ghz.  This brought my device's usage from 250mA down to about 120mA with only the debug serial connected and powered from the barrel plug.

Checking voltages:

cat /sys/class/regulator/regulator.3/microvolts 

It would be very nice to put the device in standby but short of recompiling the kernel with the appropriate flags I cant seem to access these features. (It seems you need this enabled in your kernel which it is not in the default one from BBB) To do this try:

mkdir /debug
mount -t debugfs debugfs /debug
echo mem > /sys/power/state 

There are other modes you can pass to state such as standby

Turning off leds.  This did not have much effect.

echo none > /sys/class/leds/beaglebone\:green\:usr0/trigger
echo none > /sys/class/leds/beaglebone\:green\:usr1/trigger
echo none > /sys/class/leds/beaglebone\:green\:usr2/trigger
echo none > /sys/class/leds/beaglebone\:green\:usr3/trigger

BBB, the UARTs and C/C++

Ok a primer

You've got your BBB setup, running Angstrom with a connection over the debug serial channel and powered from the 5V plug.

Why this setup?  Apparently, there's some issues with the usb-ethernet code on the kernel which logs a lot, using up disk space and cpu resources.  See here for  a description.

Now what we would like is to enable UARTs at runtime and send/receive data over them, right?  Fortunately there is a convention setup for this using device tree overlays (DTO) which allows us to do this. The description here is probably the most succinct on how to get these running from a terminal. Copied over to here all we do is this:

echo BB-UART1 > /sys/devices/bone_capemgr.8/slots

To check if it worked you can do this:

cat /sys/devices/bone_capemgr.8/slots

where you should see the list of devices installed in the slots.

But wait we want to do this at runtime!  No worries we can print to the slots file the same as we did in the terminal.  See this guys code for a description on how to enable pretty much any hardware you want. For our purposes the bbb_enableSerial function is the one we want.

So now that we've enabled the hardware during runtime we would still like to configure and preferably send and receive data.  Read this.  Basically we can set parameters using stty:

stty -F /dev/ttyO1 115200

stty -F /dev/ttyO1 raw

And then we can read and write in in the terminal like this:

read ---> cat /dev/ttyO1
write ---> echo hello! > /dev/ttyO1

And now if we want to do this in c/c++ we simply open /dev/ttyO1 as a file for reading or writing and read and write to it using the standard c-library.  For reference look here. I could not open it for read and write access as of yet.

/* fopen example from cpp reference */
#include <stdio.h>
int main ()
{
  FILE * pFile;
  pFile = fopen ("myfile.txt","w");
  if (pFile!=NULL)
  {
    fputs ("fopen example",pFile);
    fclose (pFile);
  }
  return 0;
}

Thats all.