Showing posts with label BBB. Show all posts
Showing posts with label BBB. Show all posts

Monday, 9 June 2014

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:


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.

Sunday, 8 June 2014

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:
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

Wednesday, 23 October 2013

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