Beagleboard

From Stu2
Jump to navigation Jump to search

Using the Angstrom distro to build a custom image. Building the image also provides the libraries and tool chain, which allows you to add new packages and compile custom code. I went this route because I wasn't sure how to match a tool chain to a specific Angstrom image. I tried installing the tcpdump package (ipkg) under the demo image that came with the beagleboard, but tcpdump was compiled against different (older) libraries. This took me hours and hours, but it should be worth it in the long run.

OE Environment

http://www.angstrom-distribution.org/building-angstrom - building the Angstrom distro. This will download all the files and allow you to build an image. I built the 'console-image' first. This took a really long time, as you would expect. When everything is finished, the images were located in /usr/src/oe/build/tmp-angstrom_2010_x-eglibc/deploy/images/beagleboard#.

I moved to attempting an X11 build - but failed. ca-certificates had the wrong MD5 hash and I wasn't able to update the BB files. Since every attempt requires at least 5 minutes of loading the cache, I set this project aside for a bit.

For the beaglebone, I found this great site. http://falstaff.agner.ch/2011/11/18/building-an-image-for-beaglebone/ These commands must be done as a user, not root.

Building the kernel

Follow these instructions. http://www.angstrom-distribution.org/building-angstrom Substitute "beaglebone" where "beagleboard" is used. When you get done with step 2, you will have a kernel in the 'deploy' directory:

setup-scripts/build/tmp-angstrom_v2012_05-eglibc/deploy/images/beaglebone

All the files you need for booting should be there. That is MLO, uImage and u-boot.

After you execute the instructions above, you can run bitbake for other things without the "oebb.sh" wrapper by sourcing the .oe environment file first. Then, run "bitbake TARGET". Note, do not install bitbake using apt-get. This next command will build the systemd-image, which is the filesystem I use in this project.

. ~/.oe/environment-angstromv2012.05
bitbake systemd-image

The resulting Angstrom rootfs tar file will be in the 'deploy' directory. The file contains the entire filesystem, including the necessary modules. The available recipes are in; setup-scripts/sources/meta-angstrom/recipes-images/angstrom.

After executing update, upgrade and bitbake systemd-image, I noticed uImage and the modules weren't being rebuilt. I discovered this when the /sys/kernel/security filesystem wasn't mounting on a beaglebone. uname -a revealed I was running an older kernel from the one in the rootfs file.

I found a post that fixed it. Run:

bitbake virtual/kernel -c cleansstate -f

That removed the uImage and systemd image files in the deploy subdirectory. I manually remove the soft link to the modules file. When I rebuilt the virtual/kernel with the steps above, all the files appeared and the symlinks were back. It's possible to run the steps sequentially as in this link here: https://groups.google.com/forum/#!msg/beagleboard/xGJtod0yz90/WVo1Yi1ZO7QJ but, it's better just to bitbake the target (e.g. console-image or systemd-image).

To rebuild the MLO and u-boot, I deleted the MLO and u-boot files from the deploy directory and ran:

bitbake -c cleansstate u-boot
bitbake u-boot

This next command allows you to run menuconfig to add/subtract features in the kernel. When you run it, you should get the familar menuconfig screen. I didn't at first, but discovered ncurses-dev wasn't installed.

bitbake virtual/kernel -c menuconfig

Of course, cleansstate wipes out the images, so you have to rebuild stuff to get the uImage and systemd image files.

. ~/.oe/environment-angstromv2012.05
bitbake systemd-image

When I loaded new files on for the Beaglebone, I wasn't able to log in as 'root' with no password via the serial console. After some digging, I found the answer was: "Cannot make/remove an entry for the specified session". I followed an earlier post on this list to edit /etc/pam.d/common-session and comment out "session required pam_systemd.so" to get past this hurdle.

Loading the Compiled Image on the SD Card

The instructions on the Angstrom demo page are wrong. Anyway, here's what I did to get the compiled files on the SD card.

Get the mkcard.txt file. Comment out the lines associated with kpartx.

#Check for the right /dev/sdx
df -k    

sh ./mkcard.txt /dev/sdx

Some handy commands:
dmsetup ls   # list the partitions grabbed by volume manager
dmsetup remove $DRIVE  # removes them from the vm list

I had to run the mkcard.txt file twice. Unplug the USB device and plug it back in. My disk auto-mounted, which told me mkcard.txt actually worked. If you need to mount the partitions, do the following.

mount -t vfat /dev/sdd1 /media/boot
mount /dev/sdd2 /media/Angstrom

Copy the files over from the build directory.

cd ~/setup-scripts/build/tmp-angstrom_v2012_12-eglibc/deploy/images/beaglebone#

# copy the files to sc-card boot partition.
# Do these steps as root so the permissions are right on the disk.
cp MLO /media/boot/
cp uImage /media/boot/uImage
cp u-boot.img /media/boot/
sync
tar -xvJ -C /media/Angstrom -f [YOUR-ANGSTROM-FILE].tar.xz
sync
umount /media/boot
umount /media/Angstrom
eject /dev/sdd

Try booting from the SDC. Attach the USB cable to the BB and set up a serial session using 'screen'. Note, the lights next to the Ethernet connector will blink to let you know the BB is running.

screen /dev/ttyUSB0 115200

If you can't find the BB on /dev/ttyUSB0, try /dev/ttyUSB1.

SD Cards Gone Wild

I'm almost bald. I have been pulling my hair out with regards to the micro SD cards getting corrupted. Everything was fine for a couple of weeks, when the SD cards started failing with I/O errors. I tried reformatting them and reloading the software - only to find that they failed again and again. The cards ar 4GB Kingston cards. Some googling lead me to very interesting pages regarding fake cards, but I think this must be a driver problem. I can't see that the cards would wear out after such a short time.

To solve the problem, I decided to boot from the SD card, but mount root from a USB thumb drive. To do that, you add a file called uEnv.txt to the /boot partition of the SD card. u-boot reads the parameters set in this file. mmc_root is set to the first USB partition, where the Angstrom file system resides. uEnv.txt replaces boot.scr and all that jazz. Write it to the boot partition. You also do NOT need to start the USB bus from u-boot. It's automatic.

uEnv.txt

kernel_file=uImage
kernel_addr=0x80300000
mmc_root=/dev/sda1 rw
mmc_root_fs_type=ext4 rootwait
bootargs=console=ttyO0,115200n8 ${mmc_root} ${mmc_root_fs_type}
mmc_load_uimage_deb=fatload mmc ${mmc_dev} ${kernel_addr} ${kernel_file}
mmc_load_uimage=run mmc_load_uimage_deb; run mmc_args; bootm ${kernel_addr}

I also changed /etc/fstab to use 'noatime' to ensure the file system doesn't write on every read. noatime doesn't update the file modification times when read. Should be no problem for this application.

For my beaglebone, I use snmp and cacti to gather the data. All the files are stored in /tmp. For the other two setups, I update the rrd files on the thumbdrive, but still use /tmp for the storage. This way, when the power goes out, the data is still stored on the thumb drive for later.

Narcissus - getting a custom build to work

I went back to Narcissus. http://narcissus.angstrom-distribution.org/ Nothing is easy, but I have unlocked some of the secrets. When you build the image, you can ask for a SDK and boot images. Under basic, use Beagleboard and Advanced. Under advanced setting, choose the default package (2011.03), Extended System, udev, sysvinit, tar.gz, SDK-simple tool chain. User environment choose X11 and GNOME. Under Additional Package selection, choose Platform Specific Packages, Texas Instruments/Boot Loader files. Build. You will end up with two files. One will be the toolchain and the other will be the image. The image file will contain both the boot files and the rootfs files.

Follow http://treyweaver.blogspot.com/2010/10/installing-angstrom-on-beagleboard-xm.html - covers moving the boot files and system image to the SD card. Note, the file names are different. See below. (i.e. there are no .bin files in the boot directory)

Under Ubuntu 11.10, I had trouble with omap3-mkcard, so I ended up creating the partitions by hand. I discovered that my volume manager was grabbing the partitions after the "xkpart" command executed in the script. Thus, I commented out xkpart lines and the script ran fine. The byproduct was the /dev/sdx kept incrementing every time I ran the script and remounted the drive. (e.g. /dev/sdb, /dev/sdc, etc.) The script uses 'sfdisk' to partition the drive. The 'echo ,9,0xC,*' commands are inputs to sfdisk for the partitions. sfdisk is used because it's easier to feed it parameters from a shell script.

#Check for the right /dev/sdx
df -k    

./omap3-mkcard /dev/sdx

Some handy commands:
dmsetup ls   # list the partitions grabbed by volume manager
dmsetup remove $DRIVE  # removes them from the vm list

Unplug the USB device and plug it back in. My disk auto-mounted. If you need to mount the partitions, do the following.

mount -t vfat /dev/sdb1 /media/boot
mount /dev/sdb2 /media/Angstrom

Copy the files over. Key commands, modified to account for .gz extension. The ./boot directory contained links to MLO, uImage and u-boot.img. I moved the image files from ~/Downloads to ~/beagle/. So ./boot refers to ~/beagle/boot.

# extract the files to the ./boot directory
tar --wildcards -xzvf [YOUR-DOWNLOAD-FILE].tar.gz ./boot/*

# copy the files to sc-card boot partition.
# Do these steps as root so the permissions are right on the disk.
cp ./boot/MLO /media/boot/
cp ./boot/uImage* /media/boot/uImage
cp ./boot/u-boot.img /media/boot/
sync
tar -xvz -C /media/Angstrom -f [YOUR-DOWNLOAD-FILE].tar.gz
(or tar xvj -C /media/Angstrom -f [file].tar.bz2)
sync
umount /media/boot
umount /media/Angstrom

The three files in the boot directory must be MLO, u-boot.img and uImage. The readme's don't tell you that part. Note, if you compiled the images by hand using the Angstrom distro (many, many hours)the necessary files are in the deploy. The file names don't match the this convention, but the symlinks are close. You can figure them out. Just make sure the get renamed when you copy them to the SD card. The modules are in the main .bz2 file, so you don't need to move them over separately.

Try booting from the SDC. Attach the USB cable to the BB and set up a screen session.

screen /dev/ttyUSB0 115200

It took my BeagleBoard a long time to boot the first time because it had to uncompress the files. (like 15 minutes) As long as the LEDs next to the SDC card keep flashing, you're OK. There is no default username/password for the X11 session. The serial console login is 'root' and no password.

Changing the display resolution

Then - I needed to change the resolution. So I connected a serial cable to the serial port. Used 'screen /dev/ttyS0 115200' to connect. Reboot the BB and press any key in the screen terminal during the countdown. [For the beaglebone, 'screen /dev/ttyUSB1 115200'. It takes several minutes to boot the first time and it uses DHCP. With zeroconf, you can ssh beagelbone.local after it boots.]

printenv
setenv dvimode [email protected]
saveenv
printenv
reboot

Works, but doesn't stick...

Other

http://en.wikipedia.org/wiki/User:WillWare/Angstrom_and_Beagleboard - shows how to set up your own opkg feed.

Beaglebone

Basic info: http://www.angstrom-distribution.org/demo/beaglebone/

Building the image: http://falstaff.agner.ch/2011/11/18/building-an-image-for-beaglebone/ Note, oebb.sh kept gaking on the parsing function. I cleaned out the stuff in /usr/src and /home/stu. Then, executed the scripts again. This time, so far, it's working.

This is in the readme. It's a reminder because sometimes the beaglebone is recognized, so you have to load the ftdi driver on the host computer.

sudo modprobe ftdi_sio vendor=0x0403 product=0xa6d0

Access the ADC. From http://dominion.thruhere.net/koen/cms/using-the-analog-pins-on-a-beaglebone

cat /sys/bus/platform/tsc/ain*

http://www.signal11.us/oss/udev/ - may be useful for accessing udev files via C.