creating a backup bootable image(s) of your sdcard

One of things that you can be guaranteed to do is make mistakes.  Especially when your learning.  So having regular backups is essential.  One of the ways to do this is by making an image of your hard drive/flash drive/sd card that your operating system resides on.  Imaging creates an exact replica so that all of those packages and dependencies you setup will work again after you break it.

Backup:

The most helpful page I found in a brief search on the topic was here:

https://help.ubuntu.com/community/DriveImaging

In case that link goes dead I've copied the steps I took away from this below.

Find out the name of the device you want to image through fdisk:

sudo fdisk -l                                                                               

In my case the device was at  \dev\sdc as I had my bootable sd card inserted in a usb reader.  When inserted the sd card has two partitions.  Make sure you record the file table.  Mine looked something like this.  You'll want to know the start, end and Id numbers for each partition.

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048       100351       ***    e  W95 FAT16 (LBA)
/dev/sdc2            100352     7741439      ***   83  Linux

The sd card is now ready to have an image taken of it using dd.  There is a lot of potential to screw up with dd so make sure you read the man page and understand what each flag is doing and avoid typos.  My command was as follows which takes /dev/sdc1 and 2 and puts it in an gzip'd bin file.  I did one image for each partition in this case.

sudo dd if=/dev/sdc1 bs=1024 | gzip > ~/bbbsdjun9boot.bin.gz                                                           

sudo dd if=/dev/sdc2 bs=1024 | gzip > ~/bbbsdjun9rootfs.bin.gz                                                         

I ended up with two files which can be extracted to an sd card to recover the system.

Recovery:

You will need to have the exact size partitions or larger of the original in order for this to work so make sure you write  it down above.  If you're booting up a new sd card instructions to do this can be found here:

http://www.armhf.com/boards/beaglebone-black/bbb-sd-install/

Essentially, you need to recreate the partition structure of the SD card you had before.  If you're using a larger card, in my case I have an 8 Gb card and my original was 4 Gb, you need to create the partition structure using the start and ends from before.

Now you can run:

gzip -dc ~/bbbsdjun9boot.bin.gz | dd of=/dev/sdc1 bs=1024

gzip -dc ~/bbbsdjun9rootfs.bin.gz | dd of=/dev/sdc2 bs=1024

Which can take a while depending on the write speed of your SD card.  Mine was getting around 1.7 Mb/s so the 50 Mb boot partition only took 30 sec, the ~4Gb rootfs partition took much longer.  Go get a coffee or something.

It is wise to follow through with checking your backup is viable before moving on to do whatever sketchy development you want to do next.  If you can't recover your system when the **** hits the fan you're going to be one sad panda.

Oh.  One note.  I had a bunch of problems with the dd command throwing an permissions error for /dev/sd1.  setting 'sudo -i' seemed to solve the problems.

Starting applications at boot

So by now you've likely written a few applications for your little BBB and you're thinking, 'hey, sure would be nice if these ran at boot'.

Here is some things I've found to make your life easier when doing this.

First off from this fellow:
http://stackoverflow.com/questions/7221757/run-automatically-program-on-startup-under-linux-ubuntu

you want to create an init script called 'yourscript' and put in init.d, make it excecutable and add it to the update-rc.d with default parameters as below

sudo mv /filename /etc/init.d/
sudo chmod +x /etc/init.d/filename 
sudo update-rc.d filename defaults 

If you've never created an init script before there is a template on github:

https://github.com/fhd/init-script-template

which details the adding and use.  

Once added these are helpful commands:

/etc/init.d/algorithms start

/etc/init.d/algorithms stop

/etc/init.d/algorithms status

Also anything you put on stdout and stderr should show up in the log files here:

 /var/log/scriptname.log and error output to /var/log/scriptname.err. 

Load things at boot time

So one of the useful things you will likely want to be able to do is enable certain hardware configurations at boot.

Well for starters you can mess with the uEnv.txt file similar to this:


##To disable HDMI/eMMC...
optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-UART1

You may also wish to run some scripts at boot.
add any scripts to rc.local.

sudo nano /etc/rc.local

you will need to make the scripts executable of course.

disabling/enabling boot things

sudo update-rc.d -f  apache2 remove

Try this for a while

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.