Updating TI Beagleboard to 3.x Linux from Angstrom Embedded Distro

I've have one of these neat TI Beagleboard for a couple years, have not used it for a while. TI recently released a new hardware implementation of this family called the Beaglebone. This device looks to be more useable for hardware interfacing, so I picked up a couple to explore. At USD 90, the price of the Beaglebone shows the continued downward price curve of powerful embedded hardware.

I dusted off the older Beagleboard to do some comparisons with the newer Beaglebone hardware. So first off I decided to get the distro version as close as possible. Angstrom appears to be most used and updated distro for the family, but the Android folks look to be getting some steam up.

Here are my notes on getting the most current Angstrom distro running on the Beagleboard.

The one big gotcha that may trip up forever n00b's like me was the change of the TTY port naming conventions. The correct port name for the serial port on the Beagleboard is:

ttyO2

that is a capital OOOOOO as in Oscar not a zero!

After Linux kernel version 2.6.36 the naming convention appears to have moved from:

ttySx

--to--

ttyOx

I'm sure there is a really good reason to slipstream this change in, but not only is it not clearly announced / documented around the various Linux and embedded internet resources [one of those "weed 'em out events perhaps?"] but using the capital 'O' character seems to be making for more opportunities for mistakes by confusing it with the number zero '0'.

The standard instructions to create a SD card with the two partitions containing the u-Boot and linux kernel on the first FAT partition and the remaining core Linux core OS files on the second [one of several types] Linux/Unix formatted partition is straight forward and does not vary from prior configs.

The main two changes to get the console output and the a serial terminal login prompt are as follows:

1) change the Linux bootargs console value to be:

console=ttyO2

REMEMBER THAT IS A CAPITAL O NOT A ZERO!

my basic u-Boot environment variable 'bootargs' is as follows:

bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait

2) Before you put the SD card into the Beagleboard, or after via the X Window session that comes up by default, edit the inittab file in /etc and change the following line from:

S:2345:respawn:/sbin/getty 115200 ttyS2

--to--

S:2345:respawn:/sbin/getty 115200 ttyO2

this will give you a login prompt on the Beagleboard's serial port.

Results and experiences to date.

I am still testing the 3.x kernel on the Beagleboard, so far so good. The serial port might be exhibiting some slow down after a the machine is up for a while. I need to get more data on this. Unfortunately, most of my focus is on the new Beaglebone, so the '..board' is getting the 'old dog' treatment. The puppy is the center of attention.

I updated the two boot modules of the Beagleboard to what I believe is the most current version. You get these by putting the MLO and u-boot.bin files on the FAT boot partition when you download the latest build of Angstrom. There are couple of thinks to be aware of with these upgrades. The version of these files that are in the flash memory of the Beagleboard are the older version until you use the u-boot commands to re-flash them. The instructions to do this are straight forward and worked fine. The 'gotcha' here comes in that the commands in u-boot have changed considerable and the boot scripts are stored as environment variables in the flash. So your old boot scripts will work with with your old SD cards and when you boot these files from flash [by removing the SD card or holding down the 'user' button during power up]. However, when you boot with the newer u-boot, thinks quit working. And, unfortunately, it appears to be even worse than the new versions don't work the same as to older version. It appears that the documentation and perhaps some of the commands do not work as documented that you will find on the 'help' sites on the web. I have not got my arms around these 'additional' issue yet so take this with a grain of salt, but do watch carefully as commands run. One example of what I am talking about is the 'mmc' command family to work with the SD card. There is much discussion of a 'mmcinit' command, but I could not find that command anywhere. What I did find is that before reading from the SD card, it is a good idea to do a 'mmc reset' each time before loading a file or doing a directory of the mmc. Below is my before and simple v1 'after' environments:

-- before version of environment variables that booted a October 2009 Angstrom Linux --

OMAP3 beagleboard.org # printenv

bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi
bootdelay=10
baudrate=115200
loadaddr=0x82000000
console=ttyS2,115200n8
vram=12M
dvimode=1024x768MR-16@60
defaultdisplay=dvi
mmcargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
nandargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}
stdin=serial
stdout=serial
stderr=serial
dieid#=1c04000300000000040323090e01600d

Environment size: 1056/131068 bytes
OMAP3 beagleboard.org # 


-- simple 'after' version that boots the Angstrom November 2011 3.x Linux --

OMAP3 beagleboard.org # printenv
baudrate=115200
beaglerev=Cx
bootaddr=0x80300000
bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait
bootcmd=mmc rescan 0; fatload mmc 0 ${loadaddr} uImage; bootm ${bootaddr}
bootdelay=10
buddy=unknown
buddy2=unknown
dieid#=1c04000300000000040323090e01600d
filesize=338778
loadaddr=0x80300000
stderr=serial
stdin=serial
stdout=serial
video=omapfb:2M,vram:4M
vram=12M

Environment size: 412/131068 bytes
OMAP3 beagleboard.org # 


Here is what is running on the Beagleboard now:

Linux beagleboard 3.0.8+ #1 Tue Nov 1 21:14:19 CET 2011 armv7l unknown


Some useful web sites:

Good basic setup instruction of the Beagleboard. Old so it does not address the problems I highlighted above, but still a good anchor to go back to:

http://www.ibm.com/developerworks/linux/library/l-beagle-board/

Beagleboard web site:

http://beagleboard.org/

Angstrom Linux for Beagleboard latest version. NOTE: go to the Amazon AWS mirror of this web site to get much faster download of files:

http://www.angstrom-distribution.org/demo/beagleboard/

Summary...

Pretty frustrating waste of time I had as a n00b here because the 'in the know' folks that are maintaining this stuff did not take five minutes to document some of the rather major changes. Glad I have it working! The Beagleboard and Beaglebone are great training ground for the amazing world of embedded connected inexpensive devices we are moving to. 

Berg Insights research: 1.4% of world wide wireless connection are machine to machine (M2M)

The research firm, Berg Insights, did a study at the end of last year  that finds that 1.4 percent of wireless communications is from one machine to another. And this is predicted grow by 26% per year. In the USA, Berg says the current percentage of wireless M2M connections is 4.3%.

This is the 'Internet of Things' growing at a very fast pace. This research only focuses on the mobile/cellular market, so the machine to machine communications in other frequencies [WiFi, Zigbee, Dash7] are even larger.

From Berg's research paper:

New M2M initiatives launched by major mobile operator groups are expected to have a positive influence on demand, stimulating new large-scale projects. Regulatory developments are predicted to have a major impact on the telematics industry. The EU is expected to propose formal legislation for the introduction of eCall by 2014 but in Brazil the fate of Resolution 245 is more uncertain. Another significant development to watch will be the progress of the Dutch government’s plans to introduce a nationwide electronic road charging system for all motor vehicles.

More on bad embedded software coding and coding practices

Good article here in Electronic Design about litigation that is starting to occur around embedded systems code. Just have a look at this line of code the author of that article found:

y = (x + 305) / 146097 * 400 + (x + 305) % 146097 / 36524 * 100 + (x + 305) % 146097 % 36524 / 1461 * 4 + (x + 305) % 146097 % 36524 % 1461 / 365;

In the original listing, there were no comments on this line to help. I eventually learned that this code computes the year, accounting for extra days in leap years, when given the number of days since a known reference date. But we still don’t know if it works in all cases, despite its presence in an FDA-regulated medical device. The Microsoft Zune Bug was buried in a much better formatted snippet of code that performed a very similar calculation.

This is a follow up to my post about the poor code that TI shipped out with their Zigbee products. I saw posts today that they are shipping updated code, but how long will it take to get it rolled out.

This article really highlights how important good training, good review processes and I think much more open source review is needed as we move forward to the Internet of Things.