building a bootable SD card for the BBB as easily as possible

GoogleGroups
1

as the basis for some classes coming up using the BBB, i documented
how to build, from scratch, the simplest bootable SD card i could
think of, and wrote it up here:

http://www.crashcourse.ca/wiki/index.php/Minimal_scratch_build_for_BBB

  the point was to build, piece by piece, the components to create a
small, bootable system to use as the starting point for further
experimentation. i cheat a bit stealing robert nelson's kernel build
system and root filesystem, but it's still a useful walkthrough for
new students.

  moving on, i'll come up with exercises to add functionality to that
image. thoughts? i'm sure i can already improve that recipe. open to
suggestions for improvements.

rday

2

So far, what I’ve found easiest is to make a few changes to Robert Nelsons Omap Image Builder:
https://github.com/RobertCNelson/omap-image-builder

To build the image, I copy the file build_image.sh to a new file[in my case build_raring_image.sh]

Down towards the bottom of the page I change:

DEFAULT_RELEASES=“quantal raring saucy wheezy jessie”

to

DEFAULT_RELEASES=“raring”

At the top of the file I change:

if [ -f ${DIR}/release ] ; then
chroot_KERNEL_HTTP_DIR="
https://rcn-ee.net/deb/${release}-${dpkg_arch}/v3.11.0-rc6-armv7-x10/
https://rcn-ee.net/deb/${release}-${dpkg_arch}/v3.7.10-x13/
https://rcn-ee.net/deb/${release}-${dpkg_arch}/v3.8.13-bone26/"
fi

to

if [ -f ${DIR}/release ] ; then
chroot_KERNEL_HTTP_DIR="
https://rcn-ee.net/deb/${release}-${dpkg_arch}/v3.8.13-bone26/"

fi

Basically, this is striping down the build process so it only builds a single kernel/release/distribution. IE only the 3.8.13-bone26 kernel for the Raring release[13.04] of the Ubuntu distribution.

I THINK that instead of editing the top of the file, if you create the file “release” in the same directory as build_image.sh you can specify the kernel there instead.

Lastly, to add packages available via apt-get install to include your own preferences, simply create a new release in the file “releases.sh”. For example,
Copy a release from build_image.sh:

raring_release () {
extra_pkgs=“devmem2”
firmware_pkgs=“linux-firmware”
is_ubuntu
release=“raring”
select_rcn_ee_net_kernel
minimal_armel
compression
}

to the releases.sh as:

customraring_release () {
extra_pkgs="devmem2 mysql-server php5 libapache-mod-php5 "
firmware_pkgs=“linux-firmware”
is_ubuntu
release=“raring”
select_rcn_ee_net_kernel
minimal_armel
compression
}

Then change DEFAULT_RELEASES to customraring.

This will add your own packages to the image that is build[though mysql-server may be a problem since it prompts for a password]

After creating the image, I use tools/setup_sdcard.sh in order to cut a new SD image[note: delete all the existing partitions on the SD card first - if setupd_sdcard.sh finds what looks like it might be a validly configured card, it will add the new deployment to it rather than delete and recreate. Since I wanted Robert’s boot process and not whatever I had mucked with before, I had to make sure to delete the existing partitions]

FOR upgrading the kernel - or to change kernel compile options, I then use use Robert Nelson’s linux-dev:
https://github.com/RobertCNelson/linux-dev

First perform a straight build of the kernel version your interested in. After building the image, you can edit the files in KERNEL and use the tools/rebuild.sh process to update it. This is especially useful as it gives you the source tree with all the patches applied to it that can then be edited. For example, when working with the Cape Manager, I really hate the fact that if I lose my ssh connection while performing simple read functions[such as ‘cat /sys/devices/bone_capemgr.*/slots’ it causes the cape manager itself to hang - I believe this is because Cape Manager uses a lot of straight mutex_locks to protect data structures. I’m experimenting with using mutex_lock_interruptible instead along with some extra code to catch interrupts/failures. I think this may also help with unloading devices since the current code seems to allow for deadlocks to occur.