[beagleboard] Experience and mistakes

Experience is what tells you the name of the mistake when you make it again.

The BeagleBone Black (BBB) seems pretty much ideal for a current project,
but unfortunately the project requires a battery-backed clock. (It involves
the BBB sitting in the middle of a field a long way from anywhere and
logging data to local storage.)

A BBB costs 40 UK pounds, delivered, and a clock chip breakout board
consisting of a chip, a capacitor and a resistor and a battery costs
20 UK pounds delivered, which just shows what volume building will do.
I'd hoped that I could find some way to get at the BBB's RTC clock power
line - I think if you fed that with 1V it would keep the clock going - but
looking at the board it doesn't seem practical. Anyhow, the DS3234 on
the breakout board runs from SPI and has a Linux kernel driver; how hard
could it be?

Answer, pretty bloodstained, although that's because of my ignorance,
not any intrinsic difficulty. The sequence of events to date may
prove useful to anyone starting to tinker with the BeagleBone Black
and particularly kernel 3.8. It took me a week or ten days of fairly
intensive Googling to find the solutions to the various problems.

I started by simply booting from the eMMC, with the board tethered via
USB to my (Linux) laptop. That worked, but when booted from the SD card
with an Ethernet cable plugged in the BBB ran for ten seconds and then
shut itself down. Odd, since the laptop has a relatively modern USB 2.0
port, but plugging in the Ethernet cable ten or fifteen seconds after
booting worked. (The BBB could then survive a reboot without problems.)
This was fixed by using a 5V 2.2A PSU on the barrel connector; at a guess
something in the power controller chip needs a longer timeout.

I then added a plain ext4 formatted SD card to the board, and the boot hung
with four leds up; it turns out that you need to have a very specific
partition layout on the card for the BBB to recognise it as non-bootable.
(What do those leds mean anyway, apart from the heartbeat?)

However, while the Angstrom image on the eMMC has a device table compiler,
making it easy to add 1Wire support for sensors, it doesn't have the drivers
for the DS3234. Ok, next step, compile a new kernel with the DS3234 module.

That got me involved with bitbake, whose build script turned out to need
a permanent internet connection for the duration of the build, and which
doesn't appear to checkpoint the build process. I don't have a permanent
internet connection, so I abandoned the Angstrom build with insincere
expressions of regret.

By contrast, building a Ubuntu kernel is easy; fetch Robert Wilson's build
script and run it; that's all (b). Once the packages have been downloaded
can finish the build offline. However, Angstrom seems to have its own
interactions with u-boot, or the filesystem, or uEnv.txt, and an SD card
with the Angstrom kernel and ancillary files replaced by the equivalent
Ubuntu versions fails to boot.

I then downloaded a minimal Ubuntu 13.04 image (c), loaded it onto an SD
and updated it with the new Ubuntu kernel. Once the power supply had been
upgraded (see above) it booted without problems, but the image has no dtc,
and no gcc to build one. (There's plenty of space on the 2G Ubuntu image;
adding the dtc, at least, would make the user's life a lot simpler.)

Yes there is plenty of space. But, at what point do we say 'enough'
packages? 2Gb/4Gb? Plus i have to upload 6 variations (Ubuntu
Quantal/Raring, Debian Wheezy/Jessie, plus the two "flasher" images)
to rcn-ee.net... That takes time with my limited bandwidth at my
home.. My goal with the images is to have 'enough' packages installed
out of the box, to easily allow you to get connected to the internet
and to then "install" what you need.. I just need to write up a good
usb/ip/bridge/etc guide for people who don't use the Ethernet

I spent a lot of time fooling with iptables to try to get the BBB to access
the Internet via eth0 and my laptop's wireless connection. In the end I
couldn't get routing/forwarding sorted on the laptop, but despite knowing
nothing about Ubuntu it turned out to be straightforward to add the usb
connection to the Ubuntu image using static addressing initialised by udev.
The laptop can then reach the BBB via eth1, and the BBB can reach the
via its own eth0, and apt-get can reach its updates.

Meanwhile, since I was going to need a cross-compiler at some point I built
one and compiled the Debian dtc 1.3.0-2 package. This compiled with some
warnings, but I then found that it needed patching (d); I downloaded the
patch file, but the patches don't apply cleanly to the Debian dtc, or to
the dtc that comes with the 3.5.7 kernel, and the results (patched with
some educated guessing) don't compile. In the end I found (e), and those
sources patch almost cleanly; there still needs to be some hand editing
to get the correct output from the --help option.

Just posted this over the weekend on the eewiki:

wget -c https://raw.github.com/RobertCNelson/tools/master/pkgs/dtc.sh
chmod +x dtc.sh

It'll install a version of dtc with the '@' patch..

Returning at last to the the SPI drivers, I can enable the spi1.0 and
devices with a dtb overlay, but I still don't fully understand how these are
connected to the SPI device drivers themselves.

All in all, slow progress, but progress. The information which has got me
this far is scattered in fragments across the net, much of in these forums
with their nearly unusable Google Groups interface. With luck someone
knowledgeable will write a guide to device driver installation, rather as
Robert Wilson has for kernel builds, and life will then be much easier.

Until then, good luck - Will

a) http://dev.gentoo.org/~armin76/arm/beagleboneblack/install_emmc.xml
b) http://www.eewiki.net/display/linuxonarm/BeagleBone+Black
e) git clone git://www.jdl.com/software/dtc.git dtc