(This posting was really just an archive of the link to the blog for me!)

People

People are the main ingredient in an engineering organization. When interviewing candidates, I look for three qualities: professionalism, interest, and interpersonal skills.

Professionalism is an aggregation of three attributes. First, self-control and a system of ethics. Second, competency and expertise in a technical area and an awareness of how that technical area links to the larger picture. Third, selflessness (or doing what’s best for the organization before any personal gain.)

Interest is sharing values between the candidate and organization. This includes a personalized understanding of the organization’s mission, vision, and core values.

Interpersonal skills are the final component to the recipe. How does the candidate work in a team environment? What is his/her behavior during a conflict? During stressful times? Does the candidate look for realistic, productive solutions?

Software

• OpenFire
• DokuWiki
• Subversion
• OpenEmbedded
• Mantis Bug Tracker
• Gurock TestRail

The cornerstone of any successful team is communication. To aid with that, we selected two packages: OpenFire and DokuWiki. OpenFire is a Jabber-based instant messaging server that is compatible with any Jabber/XMPP client such as Adium, Pidgin, Spark, etc. DokuWiki is an extremely powerful wiki that can be used as a scratch board, requirements/specifications repository, etc.

Next in the process is coding. Our repository of choice is Subversion, with each project split into the standard trunk/branches/tags hierarchy. (We did evaluate git, but decided Subversion worked better for our needs. Either would probably have worked well.)

The build system is a close third, and OpenEmbedded is a winner here. For embedded systems development, it greatly simplifies the entire build process. In previous postings, I’ve discussed OE in great detail.

Of course, coding is nothing without quality. Tracking issues (and features and roadmaps) is the responsibility of Mantis. TestRail, the only package with licensing, linked in with Mantis and provided our QA team the ability to create test suites and test cases, assign test runs to specific people, and track progress towards release.

Planning

“In preparing for battle I have always found that plans are useless, but planning is indispensable” (Dwight D. Eisenhower). Know your mission, know what success means in a measurable way, and communicate that information to everyone.

To checkout Bitbake 1.8.18 (the latest as of this writing), use the following instructions:

$ git clone git://openembedded.org/bitbake.git
$ cd bitbake
$ git checkout 1.8.18

You can see a list of current tags and upgrade to a specific one, if desired:

$ git tag -l

Our goal at the end of this post is to have an OE environment that:

1. builds images for a custom board based on the AT91SAM9263-EK;
2. adds the patches needed for the custom board to AT91Bootstrap, U-boot, and the Linux kernel; and
3. creates a custom root filesystem, bundled with programs that you want installed in the default image.

Lots to do, so let’s get started!

Creating the Agama9263 Machine

The Agama9263 machine will be a spin-off of the Atmel AT91SAM9263-EK. The quick overview of technical specifications for this new machine is below:

• Atmel AT91SAM9263 Rev. B processor
• 18.432 MHz main crystal
• ~200 Hz master clock
• Numonyx NAND02GW3B2D NAND flash (256 MB, 8-bit wide)
• (2) Micron MT48LC8M16A2B4 SDRAM (Each 32 MB, 16-bit wide — connected in 32-bit wide mode for 64 MB total RAM)
• (2) USB host ports
• (1) USB gadget port (for programming)
• (1) RS-232 Debug UART port (/dev/ttyS0, for programming)
• (1) RS-232 UART port (/dev/ttyS1, for user output)

A high-level block diagram of the Agama9263 is available.

Since this machine is based on an existing one, we first start by copying the OE machine configuration file:

# cd ~/workspace/local/conf/machine
# cp at91sam9263ek.conf agama9263.conf

Load up the new file in your favorite editor and let’s tweak it:

#@TYPE: Machine
#@Name: Agama9263 from Headnut.org
#@DESCRIPTION: Machine configuration for the Agama9263 board with a at91sam9263 processor

TARGET_ARCH = "arm"
#PACKAGE_EXTRA_ARCHS = "armv4t armv5te"

PREFERRED_PROVIDER_virtual/kernel = "linux"
PREFERRED_VERSION_linux = "2.6.28"
PREFERRED_PROVIDER_xserver = "xserver-kdrive"

KERNEL_IMAGETYPE = "uImage"
UBOOT_MACHINE = "agama9263_nandflash_config"
AT91BOOTSTRAP_MEDIA = "nandflash"

PREFERRED_VERSION_at91bootstrap = "1.14"

#don't try to access tty1
USE_VT = "0"

MACHINE_FEATURES = "kernel26 ext2 usbhost usbgadget screen touchscreen"
EXTRA_IMAGEDEPENDS += "u-boot"
EXTRA_IMAGEDEPENDS += "at91bootstrap"

# used by sysvinit_2
SERIAL_CONSOLE = "115200 ttyS1"
IMAGE_FSTYPES ?= "jffs2"
EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x20000 -n"

require conf/machine/include/tune-arm926ejs.inc

We also need to update ~/workspace/local/conf/local.conf to point to this new machine:

DL_DIR = "/home/chris/sources"

# BitBake configuration
BBFILES = "/home/chris/workspace/openembedded/recipes/*/*.bb"
BBFILES += "/home/chris/workspace/local/recipes/*/*.bb"
BBFILE_COLLECTIONS="upstream local"
BBFILE_PATTERN_upstream = "^/workspace/openembedded/"
BBFILE_PATTERN_local = "^/workspace/local/"
BBFILE_PRIORITY_upstream = "5"
BBFILE_PRIORITY_local = "10"
BBMASK = ""

# Uncomment the next line to have BitBake output debug messages
# BBDEBUG = "yes"

# Uncomment the next line to have BitBake emit a log upon an error
BBINCLUDELOGS = "yes"

# OpenEmbedded configuration
MACHINE = "agama9263"
DISTRO = "angstrom-2008.1"
IMAGE_FSTYPES = "jffs2"
ENABLE_BINARY_LOCALE_GENERATION = "0"
# GLIBC_GENERATE_LOCALES = "en_US.UTF-8"

# Select between multiple alternative providers, if more than one is eligible.
PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-intermediate:gcc-cross-intermediate"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"

Now the remainder of the work involves porting the various applications that have board-specific support.

Modifying AT91Bootstrap

In our second post, we created a new recipe for AT91Bootstrap that added version 1.14 to OE. Now we need to take that one step further, adding our custom board to the AT91Bootstrap sources. To get started, create a repository for our patches:

# mkdir -p ~/workspace/local/recipes/at91bootstrap/at91bootstrap-1.14/agama9263

Download at91bootstrap-1.14-agama9263.patch and save it to ~/workspace/local/recipes/at91bootstrap/at91bootstrap-1.14/agama9263/. Next, modify at91bootstrap_1.14.bb to include the following:

DESCRIPTION = "at91bootstrap: loaded into internal SRAM by AT91 BootROM"
SECTION = "bootloaders"
PR = "r0"

SRC_URI = " \
     ftp://www.linux4sam.org/pub/at91bootstrap/AT91Bootstrap${PV}.zip \
"

SRC_URI_append_agama9263 = " \
     file://at91bootstrap-1.14-agama9263.patch;patch=1;pnum=0 \
"

S = "${WORKDIR}/Bootstrap-v${PV}"
PACKAGE_ARCH = "${MACHINE_ARCH}"
EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX} DESTDIR=${DEPLOY_DIR_IMAGE} REVISION=${PR}"

AT91BOOTSTRAP_MEDIA ?= "nandflash"

do_compile () {
     unset LDFLAGS
     unset CFLAGS
     unset CPPFLAGS

     rm -Rf ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA}/${AT91BOOTSTRAP_MEDIA}_${MACHINE}.bin
     rm -Rf ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA}/${AT91BOOTSTRAP_MEDIA}_${MACHINE}.elf
     rm -Rf ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA}/${AT91BOOTSTRAP_MEDIA}_${MACHINE}.map
     oe_runmake -C ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA} AT91_CUSTOM_FLAGS="${AT91BOOTSTRAP_FLAGS}" rebuild
}

do_install () {
     install -d ${DEPLOY_DIR_IMAGE}
     install -m 0755 \
          ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA}/${AT91BOOTSTRAP_MEDIA}_${MACHINE}.bin \
          ${DEPLOY_DIR_IMAGE}/${MACHINE}-${AT91BOOTSTRAP_MEDIA}boot-${PV}-${PR}.bin
     rm -Rf ${DEPLOY_DIR_IMAGE}/at91bootstrap.bin
     cd ${DEPLOY_DIR_IMAGE} \
          && ln -sf ${MACHINE}-${AT91BOOTSTRAP_MEDIA}boot-${PV}-${PR}.bin at91bootstrap.bin
}

And that’s all, folks. The beauty of OE is that such complex tasks like adding board support are made so ridiculously simple at the build level.

You can incrementally rebuild AT91Bootstrap through the make bb PACKAGE="at91bootstrap" command. (Remember to do it once with CMD="-c clean" and again with no CMD argument.)

Modifying U-boot

Similar to the process we followed with AT91Bootstrap, a patch must be added to the U-boot recipe. For the Agama9263 machine, we’ve provided one for you.

Before we apply the patch, however, we must first create a copy of the U-boot recipe into our local overlay. While we’re doing this, let’s go ahead and make the machine-specific subfolder for the patch require:

# cp -R ~/workspace/openembedded/recipes/u-boot/ \
     ~/workspace/local/recipes/u-boot/
# mkdir -p ~/workspace/local/recipes/u-boot/u-boot-2009.01/agama9263/

Download u-boot-2009.01-agama9263.patch and save it to ~/workspace/local/recipes/u-boot/u-boot-2009.01/agama9263/. Next, let’s modify the u-boot_2009.01.bb recipe to include the patch:

require u-boot.inc

PV = "2009.01"

DEFAULT_PREFERENCE = "-1"

DEFAULT_PREFERENCE_at91rm9200dk  = "1"
DEFAULT_PREFERENCE_at91sam9rlek  = "1"
DEFAULT_PREFERENCE_at91sam9260ek = "1"
DEFAULT_PREFERENCE_at91sam9261ek = "1"
DEFAULT_PREFERENCE_at91sam9g20ek = "-1"
DEFAULT_PREFERENCE_at91sam9263ek = "1"
DEFAULT_PREFERENCE_at91cap9adk   = "1"
DEFAULT_PREFERENCE_atngw100      = "1"
DEFAULT_PREFERENCE_atstk1000     = "1"
DEFAULT_PREFERENCE_agama9263     = "1"

PR = "r1"

SRC_URI = "ftp://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2"

SRC_URI_append_at91sam9263ek = " \
     file://u-boot-2009.01-exp-002-at91sam9g20ek.patch;patch=1 \
     file://u-boot-2009.01-exp-003-drivers-net-macb.c.patch;patch=1 \
"

SRC_URI_append_at91sam9g20ek = " \
     file://u-boot-2009.01-exp-002-at91sam9g20ek.patch;patch=1 \
     file://u-boot-2009.01-exp-003-drivers-net-macb.c.patch;patch=1 \
     file://at91sam9g20-fix-config.patch;patch=1 \
"

SRC_URI_append_agama9263 = " \
     file://u-boot-2009.01-exp-002-at91sam9g20ek.patch;patch=1 \
     file://u-boot-2009.01-exp-003-drivers-net-macb.c.patch;patch=1 \
     file://u-boot-2009.01-agama9263.patch;patch=1;pnum=0 \
"

Thus has support for the Agama9263 platform been added to U-boot.

Like with AT91Bootstrap, you can incrementally rebuild U-boot through the make bb PACKAGE="u-boot" command. (Remember to do it once with CMD="-c clean" and again with no CMD argument.)

Modifying the Linux Kernel

Finally, we perform the same process in modifying the Linux kernel.  At this point, try to make the modifications needed, using the linux-2.6.28-agam9263.patch and defconfig provided.

Once you are finished or get stuck, take a look below for the recommended approach:

# mkdir -p ~/workspace/local/recipes/linux
# cp ~/workspace/openembedded/recipes/linux/linux.inc \
     ~/workspace/local/recipes/linux/
# cp ~/workspace/openembedded/recipes/linux/linux_2.6.28.bb \
     ~/workspace/local/recipes/linux/
# cp -R ~/workspace/openembedded/recipes/linux/linux-2.6.28/ \
     ~/workspace/local/recipes/linux/linux-2.6.28/
# mkdir -p ~/workspace/local/recipes/linux/linux-2.6.28/agama9263/

Because there are a huge number of files in ~/workspace/openembedded/recipes/linux/, we cherry pick only the ones needed.  Next, modify the linux_2.6.28.bb file:

require linux.inc

PR = "r11"

DEFAULT_PREFERENCE = "-1"
DEFAULT_PREFERENCE_agama9263 = "28"
DEFAULT_PREFERENCE_at91sam9263ek = "28"

SRC_URI = " \
     ${KERNELORG_MIRROR}/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2 \
     file://linux-2.6.28-at91.patch.bz2;patch=1 \
     file://linux-2.6.28-exp.patch.bz2;patch=1 \
     file://defconfig \
"

SRC_URI_append_agama9263= " \
     file://linux-2.6.28-agama9263.patch;patch=1;pnum=0 \
"

S = "${WORKDIR}/linux-2.6.28/"

Rebuild through the make bb PACKAGE="linux" command.

Building the Root Filesystem

The final step is to build a root filesystem for our new machine.  We want to create our own custom root filesystem (a.k.a. “image” in the OE terminology), and so need to create a corresponding recipe for it.

Create ~/workspace/local/recipes/images/headnut-image.bb with the following content:

export IMAGE_BASENAME = "headnut-image"

PREFERRED_PROVIDER_virtual/psplash      = "psplash/angstrom"
PREFERRED_PROVIDER_virtual/xserver      = "xserver-xorg"
PREFERRED_PROVIDER_xserver              = "xserver-xorg"

SPLASH                                  = "psplash-angstrom"
DISTRO_SSH_DAEMON                       = "openssh"
XSERVER                                 = "xserver-xorg xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-video-fbdev"

IMAGE_LINGUAS = ""

DEPENDS = "task-base"

ANGSTROM_EXTRA_INSTALL ?= ""
IMAGE_INSTALL = " \
     task-base-extended \
     apache2 \
     dhclient \
     inetutils \
     libpam \
     msmtp \
     ntp \
     openldap \
     python \
     python-pygtk \
     rng-tools \
     socketcan-modules \
     socketcan-utils-test \
     sqlite3 \
     syslog-ng \
     ${DISTRO_SSH_DAEMON} \
     ${SPLASH} \
     ${XSERVER} \
     ${ANGSTROM_EXTRA_INSTALL} \
"

# create /etc/timestamp from build date
IMAGE_PREPROCESS_COMMAND = "create_etc_timestamp"

inherit image

Two key aspects of the image recipe are marked in red.  The first is the name of the image.  The output image will have a name that corresponds to this field.  The second is the IMAGE_INSTALL variable.  The programs listed in this variable (whitespace separated) are installed in the actual root filesystem.  From our list of programs above, you’ll notice that we’re producing a fairly heavy-set image: Apache, OpenLDAP, etc.  Tweak this list to match your particular desires/needs.

Use the images that come with OE to help guide you in modifying this file.  The images are located in ~/workspace/openembedded/recipes/images/ and range from very basic (minimal-image.bb) to very complex.

The command from ~/workspace/ to accomplish this is simply:

# make image IMG="headnut-image"

Alternatively, you can modify the Makefile to replace the default IMG value and omit it from the command line above.

This one line kicks off a long bundling process.  Take a break while the computer works.

From the Agama9263 to the …?

Unfortunately, the Agama9263 doesn’t actually exist, so loading firmware onto that board will be difficult.    Suffice to say that if you follow the instructions above and apply your own patches to AT91Bootstrap, U-boot, and Linux, you should be successful at getting your board up and running.

Feel free to use the patches for the Agama9263 as a starting point for your own modifications to those programs.  (The patches were directly derived from those needed for an actual board, so have been tested on live hardware.  Names were changed to protect the innocent.)

Disclaimer

Sadly to say in our “sue-first” world, I need to write the following disclaimer:

This information is provided for educational purposes only.  Headnut.org nor its owner (“AUTHOR”) does not warrant that the information is accurate in every respect.  Author is not responsible for errors, omissions, or inaccuracies of the information or the results obtained from use of the information provided herein.  Users are always encouraged to check and confirm the information with other sources and through direct professional contact.

Restriction of Liability

Author makes no claims, promises or guarantees about the accuracy, completeness, or adequacy of the contents of this web site and expressly disclaims liability for errors and omissions in the contents of this web site. No warranty of any kind, implied, expressed or statutory, including but not limited to the warranties of non-infringement of third party rights, title, merchantablility, fitness for a particular purpose and freedom from computer virus, is given with respect to the contents of this web site or its hyperlinks to other Internet resources. Reference in this web site to any specific commercial products, processes, or services, or the use of any trade, firm or corporation name is for the information and convenience of the public, and does not constitute endorsement, recommendation, or favoring by Author.

Ownership

Information presented on this web site is considered public information and may be distributed or copied. However, all information submitted to Author via this site shall be deemed and remain the property of Author, except those submissions made under separate legal contract.  Author shall be free to use, for any purpose, any ideas, concepts, or techniques contained in information provided to Author through this site.

Next Steps

Congratulations!  You’ve now taken OpenEmbedded all the way from setup to deployment.  However, you may have run into some headaches along the way.  Very soon, we will investigate troubleshooting techniques and best practices to use with OE.

This post will focus on tweaking the OE tree to build nandflash images for the AT91SAM9263-EK and then finally uploading those images to the board.  The result (with either dataflash or nandflash) will be to have Angstrom 2008.1 booting on the board.

Overview & Key Files

The result of the compile from the first post is a list of binary images:

# tree ~/workspace/tmp/deploy/glibc/images/at91sam9263ek/
/home/chris/workspace/tmp/deploy/glibc/images/at91sam9263ek/
|-- Angstrom-console-image-glibc-ipk-2009.X-test-20090809-at91sam9263ek-testlab/
|   |-- depends-nokernel-nolibc-noupdate-nomodules.dot
|   |-- depends-nokernel-nolibc-noupdate.dot
|   |-- depends-nokernel-nolibc.dot
|   |-- depends-nokernel.dot
|   |-- depends.dot
|   |-- files-in-image.txt
|   |-- installed-package-sizes.txt
|   `-- installed-packages.txt
|-- Angstrom-console-image-glibc-ipk-2009.X-test-20090809-at91sam9263ek.rootfs.jffs2
|-- at91bootstrap.bin -> at91sam9263ek-dataflashcardboot-2.10-r1.bin
|-- at91sam9263ek-dataflashcardboot-2.10-r1.bin
|-- console-image-at91sam9263ek.jffs2 -> Angstrom-console-image-glibc-ipk-2009.X-test-20090809-at91sam9263ek.rootfs.jffs2
|-- modules-2.6.28-r11-at91sam9263ek.tgz
|-- u-boot-at91sam9263ek-2009.01-r1.bin
|-- u-boot-at91sam9263ek.bin -> u-boot-at91sam9263ek-2009.01-r1.bin
|-- uImage-2.6.28-r11-at91sam9263ek.bin
`-- uImage-at91sam9263ek.bin -> uImage-2.6.28-r11-at91sam9263ek.bin

There are a few key files that we need going forward:

• at91bootstrap.bin.  The AT91Bootstrap program is a very small bootloader produced by Atmel that does initial configuration of the hardware and passes off control to the next application.  For our purposes, this next application will be U-boot, but with a few tweaks could pass control directly to the Linux kernel.  As you can see from the tree above, this file is a symlink to at91sam9263ek-dataflashcardboot-2.10-r1.bin.  The “dataflashcardboot” string indicates which memory type this image supports.
• u-boot-at91sam9263ek.bin.  U-boot is the “universal bootloader” for embedded systems.  It is a very feature-rich bootloader that offers both LCD and command line support — great for recovery purposes in the event that an in-field upgrade goes awry.  Because the AT91SAM9263-EK requires the AT91Bootstrap program first, this is an optional but highly recommended component of your installation.  While the name of the symlink’d file does not reveal whether it supports dataflash or nandflash, the default settings in OE result in this image supporting dataflash.
• uImage-at91sam9263ek.bin.  This is a compressed version of the Linux kernel for use with U-boot.  Once we get to the kernel, the distinction between dataflash and nandflash does not matter as much, though it is very likely that we will need to tweak the kernel’s configuration anyway.  More on this later.
• console-image-at91sam9263ek.jffs2.  The rest of the root filesystem is compressed as a JFFS2 image.  This image holds the files related to the Angstrom distribution.  The prefix of the filename (“console-image”) will match the IMG parameter from the make image command in the first post; remember that if no IMG parameter is given, the default value is console-image.

These four files comprise all of the support needed to boot Linux.  If you have a board with dataflash, skip ahead to load the files onto the board.  If you have a nandflash board, step through the OE tree modification process with me to build the files that we need.

The Machine Configuration File & U-boot

OE stores many of the definitions surrounding a board in machine configuration files.  These are located in ~/workspace/openembedded/conf/machine.  If you take a peek, you’ll notice there is an at91sam9263ek.conf file for our particular board.  This is the file that needs to be modified to start the support of nandflash.

We are now faced with a question: how do we modify the file?  Beyond the holy war of editor selection, remember that ~/workspace/openembedded is an active git repository.  If we make changes inside the tree, future updates may clobber those changes.  Hours of work get tossed away with a simple make update.

The answer is lies in our ~/workspace/local structure.  BitBake supports the concept of Collections.  These allow us (at runtime) to overlay our own files on top of the ones in the OE repository, but still keep the static structure of the files separate.  Your workspace is already enabled with the concept; see the local.conf file from the first post.

We will need to mimick the OE structure slightly and copy the files that we want to modify:

# mkdir -p ~/workspace/local/conf/machine
# cp ~/workspace/openembedded/conf/machine/at91sam9263ek.conf \
     ~/workspace/local/conf/machine

At this point, fire up your favorite editor and modify ~/workspace/local/conf/machine/at91sam9263ek.conf so that it contains the changes in red below:

#@TYPE: Machine
#@Name: Atmel AT91SAM9263EK Development Platform
#@DESCRIPTION: Machine configuration for the at91sam9263ek development board with a at91sam9263 processor

TARGET_ARCH = "arm"
#PACKAGE_EXTRA_ARCHS = "armv4t armv5te"

PREFERRED_PROVIDER_virtual/kernel = "linux"
PREFERRED_VERSION_linux = "2.6.28"
PREFERRED_PROVIDER_xserver = "xserver-kdrive"

KERNEL_IMAGETYPE = "uImage"
UBOOT_MACHINE = "at91sam9263ek_nandflash_config"

PREFERRED_VERSION_at91bootstrap = "2.10"

#don't try to access tty1
USE_VT = "0"

MACHINE_FEATURES = "kernel26 alsa ext2 usbhost usbgadget screen touchscreen"
EXTRA_IMAGEDEPENDS += "u-boot"
EXTRA_IMAGEDEPENDS += "at91bootstrap"

# used by sysvinit_2
SERIAL_CONSOLE = "115200 ttyS0"
IMAGE_FSTYPES ?= "jffs2"
EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x20000 -n"

require conf/machine/include/tune-arm926ejs.inc

At this point, you may be tempted to start making other changes.  DON’T!  Debugging an embedded system is difficult enough.  Making too many changes at once can lead to some very long nights banging your head against the keyboard.  Start small.

You may be wondering, “how did we know what to use for the UBOOT_MACHINE definition?”  The answer lies in a combination of the U-boot recipe and source code.  In the U-boot recipe (specifically ~/workspace/openembedded/recipes/u-boot/u-boot.inc), the compile process is initiated through the following process:

do_compile () {
        unset LDFLAGS
        unset CFLAGS
        unset CPPFLAGS
        oe_runmake ${UBOOT_MACHINE}
        oe_runmake all
}

We see here that when OE runs automake inside the U-boot build tree, it passes the UBOOT_MACHINE variable verbatim.  When we look at the Makefile in the U-boot source tree (~/workspace/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/u-boot-2009.01-r1/u-boot-2009.01/Makefile), we can see that several targets are supported for the AT91SAM9263-EK board:

at91sam9263ek_nandflash_config \
at91sam9263ek_dataflash_config \
at91sam9263ek_dataflash_cs0_config \
at91sam9263ek_config    :       unconfig
        @mkdir -p $(obj)include
        @if [ "$(findstring _nandflash,$@)" ] ; then \
                echo "#define CONFIG_SYS_USE_NANDFLASH 1"       >>$(obj)include/config.h ; \
                $(XECHO) "... with environment variable in NAND FLASH" ; \
        else \
                echo "#define CONFIG_SYS_USE_DATAFLASH 1"       >>$(obj)include/config.h ; \
                $(XECHO) "... with environment variable in SPI DATAFLASH CS0" ; \
        fi;
        @$(MKCONFIG) -a at91sam9263ek arm arm926ejs at91sam9263ek atmel at91

So at this point, rebuilding U-boot would create a version that supported nandflash.  (We’re going to hold off on rebuilding at the moment and just do everything in one fell swoop.)

AT91Bootstrap

OE contains recent versions of AT91Bootstrap (v2.x and later).  Unfortunately, these versions appear to be broken for use with nandflash.  (Many thanks to Marcin Juszkiewicz for pointing that out!  His one sentence answer ended my hours of banging a head against the table.)  To work around the issue, we will add a new recipe for AT91Bootstrap v1.14.

First, create the directory to hold our new recipe:

# mkdir -p ~/workspace/local/recipes/at91bootstrap

Next, create a file named at91bootstrap_1.14.bb in this directory.  You can either download the file or create it youself.  The file should contain the following:

DESCRIPTION = "at91bootstrap: loaded into internal SRAM by AT91 BootROM"
SECTION = "bootloaders"
PR = "r0"

SRC_URI = " \
     ftp://www.linux4sam.org/pub/at91bootstrap/AT91Bootstrap${PV}.zip \
"

S = "${WORKDIR}/Bootstrap-v${PV}"
PACKAGE_ARCH = "${MACHINE_ARCH}"
EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX} DESTDIR=${DEPLOY_DIR_IMAGE} REVISION=${PR}"

AT91BOOTSTRAP_MEDIA ?= "nandflash"

do_compile () {
     unset LDFLAGS
     unset CFLAGS
     unset CPPFLAGS

     rm -Rf ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA}/${AT91BOOTSTRAP_MEDIA}_${MACHINE}.bin
     rm -Rf ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA}/${AT91BOOTSTRAP_MEDIA}_${MACHINE}.elf
     rm -Rf ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA}/${AT91BOOTSTRAP_MEDIA}_${MACHINE}.map
     oe_runmake -C ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA} AT91_CUSTOM_FLAGS="${AT91BOOTSTRAP_FLAGS}" rebuild
}

do_install () {
     install -d ${DEPLOY_DIR_IMAGE}
     install -m 0755 \
          ${S}/board/${MACHINE}/${AT91BOOTSTRAP_MEDIA}/${AT91BOOTSTRAP_MEDIA}_${MACHINE}.bin \
          ${DEPLOY_DIR_IMAGE}/${MACHINE}-${AT91BOOTSTRAP_MEDIA}boot-${PV}-${PR}.bin
     rm -Rf ${DEPLOY_DIR_IMAGE}/at91bootstrap.bin
     cd ${DEPLOY_DIR_IMAGE} \
          && ln -sf ${MACHINE}-${AT91BOOTSTRAP_MEDIA}boot-${PV}-${PR}.bin at91bootstrap.bin
}

The AT91BOOTSTRAP_MEDIA variable allows us to define the flash type (dataflash or nandflash) used on the machine in the machine configuration file.  The follow-up step, therefore, is to modify ~/workspace/local/conf/machine/at91sam9263ek.conf to include this definition:

#@TYPE: Machine
#@Name: Atmel AT91SAM9263EK Development Platform
#@DESCRIPTION: Machine configuration for the at91sam9263ek development board with a at91sam9263 processor

TARGET_ARCH = "arm"
#PACKAGE_EXTRA_ARCHS = "armv4t armv5te"

PREFERRED_PROVIDER_virtual/kernel = "linux"
PREFERRED_VERSION_linux = "2.6.28"
PREFERRED_PROVIDER_xserver = "xserver-kdrive"

KERNEL_IMAGETYPE = "uImage"
UBOOT_MACHINE = "at91sam9263ek_nandflash_config"
AT91BOOTSTRAP_MEDIA = "nandflash"

PREFERRED_VERSION_at91bootstrap = "1.14"

#don't try to access tty1
USE_VT = "0"

MACHINE_FEATURES = "kernel26 alsa ext2 usbhost usbgadget screen touchscreen"
EXTRA_IMAGEDEPENDS += "u-boot"
EXTRA_IMAGEDEPENDS += "at91bootstrap"

# used by sysvinit_2
SERIAL_CONSOLE = "115200 ttyS0"
IMAGE_FSTYPES ?= "jffs2"
EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x20000 -n"

require conf/machine/include/tune-arm926ejs.inc

One final step needs to take place before the AT91Bootstrap recipe is complete.  In the SRC_URI variable, we’ve specified a new file to download, one which OE has never before seen.  For security reasons, one of the checks that OE performs before uncompressing source code is to check the MD5/SHA256 checksum of the compressed version to ensure that the content matches what is expected.  So we need to teach OE about this file.

Create a new file at ~/workspace/local/conf/checksums.ini that contains the following:

[ftp://www.linux4sam.org/pub/at91bootstrap/AT91Bootstrap1.14.zip]
md5=2942f22a101d61a34aaf48b0f6b88cba
sha256=90bfc6ecc53a3ee7bb5a3eb33bae3f8fd768165570046d92bb47462f629bdd11

(The blank line at the end is important.  More on this in later posts.)

Once the recipe exists, the checksum data is added to the approved list, and the machine configuration file is updated, we’re ready to begin our build.

Rebuilding AT91Bootstrap and U-boot

After the steps from the previous sections have been completed, we’re now ready to build both AT91Bootstrap and U-boot.  The following two commands accomplish this task:

# cd ~/workspace
# make bb PACKAGE="at91bootstrap u-boot" CMD="-c clean"
# make bb PACKAGE="at91bootstrap u-boot"

Note how the first make command overrides the command passed to BitBake, telling it to clean the existing builds off the system.  The second make command then tells BitBake to regenerate the builds.

Looking at our images tree, we now see the new files:

# tree --dirsfirst -F ~/workspace/tmp/deploy/glibc/images/at91sam9263ek/
/home/chris/workspace/tmp/deploy/glibc/images/at91sam9263ek/
|-- Angstrom-console-image-glibc-ipk-2009.X-test-20090809-at91sam9263ek-testlab/
|   |-- depends-nokernel-nolibc-noupdate-nomodules.dot
|   |-- depends-nokernel-nolibc-noupdate.dot
|   |-- depends-nokernel-nolibc.dot
|   |-- depends-nokernel.dot
|   |-- depends.dot
|   |-- files-in-image.txt
|   |-- installed-package-sizes.txt
|   `-- installed-packages.txt
|-- Angstrom-console-image-glibc-ipk-2009.X-test-20090809-at91sam9263ek.rootfs.jffs2
|-- at91bootstrap.bin -> at91sam9263ek-nandflashboot-1.14-r0.bin*
|-- at91sam9263ek-nandflashboot-1.14-r0.bin*
|-- console-image-at91sam9263ek.jffs2 -> Angstrom-console-image-glibc-ipk-2009.X-test-20090809-at91sam9263ek.rootfs.jffs2
|-- modules-2.6.28-r11-at91sam9263ek.tgz
|-- u-boot-at91sam9263ek-2009.01-r1.bin*
|-- u-boot-at91sam9263ek.bin -> u-boot-at91sam9263ek-2009.01-r1.bin*
|-- uImage-2.6.28-r11-at91sam9263ek.bin
`-- uImage-at91sam9263ek.bin -> uImage-2.6.28-r11-at91sam9263ek.bin

Programming the AT91SAM9263-EK Board

IF USING DATAFLASH: The Tcl script and ubootEnvtFileNandFlash.bin below have been optimized for nandflash.  They will not behave properly with boards that use dataflash.  I will try to post instructions on how to get dataflash working later, but for now, you may have to tweak things on your own.

Once we have the appropriate dataflash/nandflash versions of the binary images, we are ready to upload the images to the AT91SAM9263-EK board.  To assist with this process, we will need two files.  You can either download them or create them yourself:

~/workspace/tmp/deploy/glibc/images/at91sam9263ek/load_flash.bat

sam-ba.exe \usb\ARM0 AT91SAM9263-EK load_flash.tcl > logfile.log 2>&1
notepad logfile.log

~/workspace/tmp/deploy/glibc/images/at91sam9263ek/load_flash.tcl

#
# Derived from at91sam9263ek_demo_linux_nandflash.tcl
# Copyright (c) 2008 Atmel Corporation.
#

################################################################################
#  proc uboot_env: Convert u-boot variables in a string ready to be flashed
#                  in the region reserved for environment variables
################################################################################
proc set_uboot_env {nameOfLstOfVar} {
    upvar $nameOfLstOfVar lstOfVar

    # sector size is the size defined in u-boot CFG_ENV_SIZE
    set sectorSize [expr 0x20000 - 5]

    set strEnv [join $lstOfVar "\0"]
    while {[string length $strEnv] < $sectorSize} {
       append strEnv "\0"
    }
    # \0 between crc and strEnv is the flag value for redundant environment
    set strCrc [binary format i [::vfs::crc $strEnv]]
    return "$strCrc\0$strEnv"
}

################################################################################
#  Main script: Load the linux demo in NandFlash
#               Update the environment variables
################################################################################
set bootstrapFile       "at91bootstrap.bin"
set ubootFile           "u-boot-at91sam9263ek.bin"
set ubootEnvFile        "ubootEnvtFileNandFlash.bin"
set kernelFile          "uImage-at91sam9263ek.bin"
set rootfsFile          "console-image-at91sam9263ek.jffs2"

## NandFlash Mapping
set bootStrapAddr       0x00000000
set ubootAddr           0x00020000
set ubootEnvAddr        0x00060000
set kernelAddr          0x00200000
set rootfsAddr          0x00400000

# u-boot variable
set kernelUbootAddr     0x00200000
set kernelLoadAddr      0x22200000

## NandFlash Mapping
set kernelSize    [format "0x%08X" [file size $kernelFile]]

lappend u_boot_variables \
 "ethaddr=3a:1f:34:08:54:54" \
 "bootdelay=3" \
 "baudrate=115200" \
 "stdin=serial" \
 "stdout=serial" \
 "stderr=serial" \
 "bootargs=mem=64M console=ttyS0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2" \
 "bootcmd=nand read $kernelLoadAddr $kernelUbootAddr $kernelSize; bootm $kernelLoadAddr"

puts "-I- === Initialize the NAND access ==="
NANDFLASH::Init

puts "-I- === Erase all the NAND flash blocs and test the erasing ==="
NANDFLASH::EraseAllNandFlash

puts "-I- === Load the bootstrap: nandflash_at91sam9-ek in the first sector ==="
NANDFLASH::sendBootFile $bootstrapFile

puts "-I- === Load the u-boot in the next sectors ==="
send_file {NandFlash} "$ubootFile" $ubootAddr 0

puts "-I- === Load the u-boot environment variables ==="
set fh [open "$ubootEnvFile" w]
fconfigure $fh -translation binary
puts -nonewline $fh [set_uboot_env u_boot_variables]
close $fh
send_file {NandFlash} "$ubootEnvFile" $ubootEnvAddr 0

puts "-I- === Load the Kernel image ==="
send_file {NandFlash} "$kernelFile" $kernelAddr 0

puts "-I- === Load the linux file system ==="
send_file {NandFlash} "$rootfsFile" $rootfsAddr 0

(Feel free to change the ethaddr and baudrate settings if your setup needs it.)

Download the ubootEnvtFileNandFlash.bin file and place it in ~/workspace/tmp/deploy/glibc/images/at91sam9263ek/.  This file has been provided by Atmel (along with the original versions of the .bat and .tcl files above) to assist in the flashing of the board.  The Tcl file overwrites certain parameters before writing the contents to the ENV sector of flash.

To illustrate how this Tcl script works, let’s take a look at the memory map (derived from http://www.linux4sam.org/twiki/pub/Linux4SAM/GettingStarted/demo_nandflash_map.png):

AT91SAM9263-EK Memory Map for NandFlash

The addresses on the left side of each box are memory locates in the nandflash.  AT91Bootstrap is loaded first at address 0x0.  U-boot follows at address 0x20000, with its environment close behind at address 0x60000.  (A redundant environment is stored at address 0x80000, but nothing needs to get loaded for this.)  The Linux kernel itself is way up at address 0x200000, with the root filesystem coming last at address 0x400000.

Later, we will investigate what to do if you want to change these address, but let’s leave them be for now.

The final tool in this puzzle is the Atmel AT91 In-system Programmer (ISP).  The current version as of this writing is v1.13 for Windows XP/Vista and Linux.  Download the install package for your operating system from the Atmel website and run through the setup.  The AT91 ISP installs several utilities, one of which is named SAM-BA.  This program will be used to continue the flashing operation.

The next few steps will use Windows XP as the example system that is used to flash the board.  The process can be easily adopted for your particular operating system.

Follow the below steps to flash the Atmel AT91SAM9263-EK board:

1. Power off the board.
2. Connect a USB cable from your computer to port J18 (USB device interface) on the AT91SAM9263-EK board.
3. Open (remove) jumper J29 (NANDCS).
4. Power on the board.
5. Wait for your computer to recognize the AT91SAM9263-EK as a new USB device.  Install any drivers that it recommends using.
6. Close (add) jumper J29 (NANDCS).
7. Run load_flash.bat.  Wait until the Notepad window appears.
8. Close Notepad.
9. Momentarily press the SPST switch BP3 (RESET) to power cycle the board.

At this point, if you have a serial console connected to J14 (SERIAL DEBUG PORT) with the settings 115200 8-N-1 (no flow control), you should see the following sequence:

RomBOOT
>

U-Boot 2009.01 (Aug 09 2009 - 07:07:28)

DRAM:  64 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   macb0
macb0: Starting autonegotiation...
macb0: Autonegotiation timed out (status=0x7849)
macb0: link down (status: 0x7849)
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x200000, size 0x1d722c
 1929772 bytes read: OK
## Booting kernel from Legacy Image at 22200000 ...
 Image Name:   Angstrom/2.6.28/at91sam9263ek
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:    1929708 Bytes =  1.8 MB
 Load Address: 20008000
 Entry Point:  20008000
 Verifying Checksum ... OK
 Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux.............................................................
........................................ done, booting the kernel.
[    0.000000] Linux version 2.6.28 (chris@headnut.org) (gcc version 4.3.3 (GCC)) #1 PREEMPT Sun Aug 9 02:14:09 PDT 2009
[    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: Atmel AT91SAM9263-EK
[    0.000000] Ignoring unrecognised tag 0x54410008
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] Clocks: CPU 199 MHz, master 99 MHz, main 16.367 MHz
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line: mem=64M console=ttyS0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2
[    0.000000] AT91: 160 gpio irqs in 5 banks
[    0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[    0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
...[snipped]...

If your screen looks like above, congratulations!  You have modified the default OE workspace and successfully built a nandflash version of images for the Atmel AT91SAM9263-EK.

If things are not working, step back through these instructions and double check everything.  You can try removing ~/workspace/tmp/ and restarting the entire build process from make.  This will sometimes work as items are not always cleared out of the BitBake cache properly.  If none of these suggestions help, there will be additional information on debugging embedded systems posted later.

Once you have a working system, you will be very tempted to start modifying things.  The next post will talk about exactly that.

OpenEmbedded provides a framework that promotes cross compiling in a “emerge”-like manner.  Relying on BitBake (derived from “emerge”, in fact) as its under-the-hood workhorse, OE creates a sandboxed build system that is entirely self-contained.  Entire systems can be created with a single command and, more importantly, without having to understand the complexities of cross compiling!

This first post will focus on creating a working build system.  By the conclusion, you will be able to compile binary images for the target board.  Follow-up posts will show you how to load the binary images onto the target, create your own custom target board, and then roll your own Linux distribution.

Definitions:

• Architecture (ARCH). The target’s CPU architecture — in our example, the AT91SAM9263 Rev B. processor.
• Build host. A “regular” computer that will be used to compile all of the programs needed for the target.
• OE. Abbreviation for “OpenEmbedded.”
• Target. The embedded system on which we want Linux to run — in our example, the AT91SAM9263-EK board.

OE requires certain prerequisites to start its build process.  You will need a PC running Linux as the build host.  OE supports many different distributions, so check for specific support required for your particular Linux flavor. Regardless of distribution, you will likely need between 32 GB and 64 GB of free space to begin the process.

I use Gentoo as my build host, so the following instructions will add all prerequisites:

# emerge -n \
  psyco \
  ccache \
  patch \
  make \
  sed \
  dev-lang/python \
  m4 \
  bison \
  cvs \
  openjade \
  quilt \
  sgmltools-lite \
  docbook-xml-dtd \
  docbook-dsssl-stylesheets \
  xmlto \
  docbook-sgml-utils \
  libpcre \
  boost \
  subversion \
  texi2html \
  pysqlite

First, create a directory for your workspace.  I literally use the name “workspace” unless there is a need to support several build systems at the same time.

# mkdir ~/workspace

Next, create a directory for all of the source files that are downloaded (tarballs, subversion snapshots, etc.)  Since these files can be shared across multiple workspaces — aren’t the GCC sources the same regardless of what platform you use? — we put them in a common location to avoid cluttering the hard drive:

# mkdir ~/sources

While most instructions at this point will tell you to export a lot of system variables, I use a Makefile to help coordinate all of the building activities.  It helps when jumping from one workspace to another by providing a single set of commands that operate no matter which workspace you’re using.

Download the Makefile and save it to ~/workspace/Makefile.

Your directory structure resembles the following:

# tree --filelimit 5 --dirsfirst -F --noreport
.
|-- sources/
`-- workspace/
    `-- Makefile

There are four basic targets (e.g. commands) supported:

make workspace
make update
make image [IMG="..."]
make bb PACKAGE="..." [CMD="..."]

The first target, make workspace, downloads the Bitbake and OE files required.

The second target, make update, will update Bitbake and OE to the latest version in their respective repositories.  USE THIS COMMAND WITH CAUTION!  Your build may stop working if an upstream change breaks something unexpectedly.  Once you get a system running, you will almost never want to run this command.

The third target, make image, does the bulk of the work, creating the desired image.  To change the image created, either modify the target in the Makefile or pass the image name through the optional IMG variable.

The fourth target, make bb, executes Bitbake directly and is useful for package development.  The name of the package should go in the PACKAGE variable, while any particular command arguments for Bitbake should go in the optional CMD variable.

Next, modify ~/workspace/local/conf/local.conf to define your particular target. For the AT91SAM9263-EK target, the file should look something like this:

DL_DIR = "/home/chris/sources"

# BitBake configuration
BBFILES = "/home/chris/workspace/openembedded/recipes/*/*.bb"
BBFILES += "/home/chris/workspace/local/recipes/*/*.bb"
BBFILE_COLLECTIONS="upstream local"
BBFILE_PATTERN_upstream = "^/workspace/openembedded/"
BBFILE_PATTERN_local = "^/workspace/local/"
BBFILE_PRIORITY_upstream = "5"
BBFILE_PRIORITY_local = "10"
BBMASK = ""

# Uncomment the next line to have BitBake output debug messages
# BBDEBUG = "yes"

# Uncomment the next line to have BitBake emit a log upon an error
BBINCLUDELOGS = "yes"

# OpenEmbedded configuration
MACHINE="at91sam9263ek"
DISTRO="angstrom-2008.1"
IMAGE_FSTYPES = "jffs2"
ENABLE_BINARY_LOCALE_GENERATION = "0"
# GLIBC_GENERATE_LOCALES = "en_US.UTF-8"

# Select between multiple alternative providers, if more than one is eligible.
PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-intermediate:gcc-cross-intermediate"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"

Note in the file above, we did not use the ~/workspace abbreviation of the path. BitBake does not like the ~ operator, so we must use the fully-qualified directory name (FQDN) of /home/chris/workspace instead. (Replace /home/chris with whatever ~ is for your system.)

Stop at this point and make sure that your directory structure resembles the following:

# tree --filelimit 5 --dirsfirst -F --noreport
.
|-- sources/
`-- workspace/
    |-- bitbake/
    |-- local/
    |   |-- conf/
    |   |   `-- local.conf
    |   `-- recipes/
    |       `-- images/
    |           `-- dummy-image.bb
    |-- openembedded/
    `-- Makefile

We are now ready to begin the build process.  This will take a LONG time, even on the fastest of machines.  (My average compile from scratch takes approximately 4 hours on a dual-processor 2.4 GHz dedicated system with 4 GB of RAM.)  I recommend starting this when you have other things to do:

# make
BB_ENV_EXTRAWHITE="WORKSPACE" /home/chris/workspace/bitbake/bin/bitbake console-image
Foo None
NOTE: Handling BitBake files: | (5591/7047) [79 %]
   NOTE: Angstrom DOES NOT support bluez-utils because bluez-utils 3.x has been replaced by bluez4
NOTE: Handling BitBake files: \ (5600/7047) [79 %]
   NOTE: Angstrom DOES NOT support bluez-utils because bluez-utils 3.x has been replaced by bluez4
NOTE: Angstrom DOES NOT support bluez-libs because bluez-libs 3.x has been replaced by bluez4
NOTE: Angstrom DOES NOT support bluez-libs because bluez-libs 3.x has been replaced by bluez4
NOTE: Handling BitBake files: \ (5613/7047) [79 %]
   NOTE: Angstrom DOES NOT support bluez-libs because bluez-libs 3.x has been replaced by bluez4
NOTE: Handling BitBake files: / (7047/7047) [100 %]
NOTE: Parsing finished. 0 cached, 6757 parsed, 290 skipped, 0 masked.
NOTE: Resolving any missing task queue dependencies
...

There is a slim chance that the build will exit prematurely, complaining of some error. Try to fix whatever the problem is, then start make again to pick up where you left off. Handling errors that occur during the build process will be a different posting.

If everything succeeds, you will be told so and dropped back to the command prompt. Congratulations! You have a working OpenEmbedded build system.

At this point, you’re ready to load the files onto the board. But that is a discussion for the next posting.

• Deer
• Mongoose
• Quail
• Humming Birds (iridescent blue and green)
• HUGE spiders
• Donkeys
• Iguanas
• Lizards
• HUGE butterflies (bird-sized)
• Hermit crabs
• Land crabs
• Other weird looking crabs
• Coral banded shrimp
• Barracuda (up to 5 ft)
• Sea turtles (8)
• Sea cucumber
• Squid (hundreds)
• Crawfish
• Rays
• Conch
• Flounder

Tuesday, June 23rd

After anxiously waiting for Chris to wake up, we packed all of our hiking gear and started to town, choosing the harder trail because of the nicer vistas.  Well, the vistas were magnificent, but the hike was really hard, even for two seasoned hikers.  Turns out that there are two key differences between California hiking and St. John hiking: (1) in St. John, it’s hot and muggy; and (2) it’s uphill, all of it.  Nevertheless, it was beautiful and fun!  Good thing we brought extra water.  We saw our first Gungalo, a millipede that will, according to the locals, “pee in yo eye and blind yo.”  After reaching town, we found a nice outdoor cafe for lunch and got directions from the waitress to a grocery store.  We picked up some provisions (sunblock!) and took a taxi back to Caneel.  After lunch, we donned our snorkel gear and headed over to honeymoon beach.   The snorkeling was fantastic.

Wednesday, June 24th

We bummed around Caneel for the whole day.  I talked Chris into packing a beach bag, and we lounged on the beach, kayaking (Chris is an expert kayaker thanks to Camp Ocoee.), snorkeling (Eastern edge of Caneel Bay was surprisingly great.), reading, and jumping off of the incredible floating dock.  The donkeys were even sunbathing with us.  After showers and a bit of down time in the A/C, we headed off to town (by taxi this time), and had dinner at Morgan’s Mangos (delicious Island food!)

Thursday, June 25th

I woke Chris up at the crack of dawn (literally), dressed him in his hiking attire, and we headed out the door.  We took a taxi to Maho Bay to find the Maria Hope trail.  The taxi driver had never heard of it before and outright told us we were crazy.  I gotta admit, he did have a point.  We found the trailhead marked on a gutter as “MH” in white paint.  Indeed, the beginning of the trail was in fact a gutter.  After scrambling for a bit, it opened to a really beautiful trail.  Since it wasn’t a park trail, I wasn’t sure that it would be passable.  The trail was pretty open, but filled with spider webs.  My gallant knight (see picture) cleared the trial for me with his palm frond sword.  We learned later that these were mostly golden orb spiders, and their silk was once used as thread.  We also saw these huge seed pods from the “stinking toe tree,” though we were fortunate not to smell them.  After about a mile of strait uphill, we reached Centerline Road and the trailhead for the Bay Reef Trail, which was totally awesome.  It was well maintained (and all downhill!!!)  In the shade of the trees, the temperature was really nice.  We saw the petroglyphs, which were carved on the side of a rock and reflected perfectly into a small fresh water pond made by a waterfall.  My gallant night entertained himself by sparring with some crawfish in the pond.  After the petroglyphs, we hiked to the ruins from an old sugar plantation that even contained an old rum still, then on to the beach.  (Yes, we hiked across the whole island, North to South, from beach to beach.)  From here, we hiked east via the Lameshur trail, then along the road to Salt Pond Bay.  It was beautiful, but hot.  When we came to the beach, we asked a nice family to take our picture.  That’s when I realized that we had already been to two beautiful beaches, but had had them all to ourselves!  We took the Vitran bus (much less sketch than the SF Muni, but with crazy fast drivers) to Coral Bay, and had the best hamburgers ever at Skinny Legs whose motto is “Same Day Service.”  We then took the Vitran bus to Cruz Bay, where we picked up some Band-Aids, and headed back to Caneel.  After such an intense exploration, Chris was quite content spending the rest of the afternoon taking it easy.

Friday, June 26th

We took a taxi to Annaberg and hiked along the Leinster Bay trail.  After plopping our bag on the beach, we swam out to Waterlemon Cay, which had THE best snorkeling that I’ve ever experienced.  The coral around the cay teemed with life.  There were millions of fish.  We saw two sea turtles that were just hanging out.  One of them just sat there munching on grass.  Most of the fish we saw weren’t even in our book of Tropical Fish of the Virgin Islands. Chris also noticed the 2nd biggest barracuda that I’ve ever seen. (For the biggest, see Saturday’s entry.)   It was huge!  And yes, Carrie, it was looking at me!  After two goes of the island, we decided to swim into shore to get a snack.  That’s when we found that something (a mongoose maybe?) had eaten our trail mix.  We split the rest of the snacks (which were luckily untouched), and started hiking toward the closest place to catch a taxi, the Maho campground.  On the way, we found two fishermen, who were mistakenly waiting for a taxi along a not well traveled section of road.  So, they hiked with us up to the campground, where Chris and I had lunch and saw the Iggy, the iguana.  We took a taxi to Hawksnest Bay, which had a beautiful beach and good snorkeling, though nothing like Waterlemon.  Then, we hiked back to Caneel, took showers, and headed into town for dinner.  We ate at Saint John’s version of a taco stand, which was different, but good nonetheless, hiked up to the grocery store to buy some more snacks (on account of losing our trail mix), and stopped on the way down to get some ice cream.

Saturday, June 27th

While letting Chris sleep in some, I learned a very important lesson: always eat your muffin as soon as you get it.  I set my muffin on my plate while enjoying some orange juice.  Immediately, a seagull flew down, and in one swoop took my whole muffin.  Very impressive!  So, I went back, got a second, and ate it without ever letting it touch my plate.

After Chris woke up, we took a taxi to Cinnamon Bay on a pilgrimage to find the great Theobroma cacao, also known as the god of chocolate.  Since we got there early, the beach was empty, and we had the bay all to ourselves.  (Well, we had to share it with a family of 4, but it was essentially empty.)  We snorkeled for a while, and saw hundreds of squid, in addition to two more sea turtles.  After some lunch at the cafe, we went back to Caneel, and snorkeled over near Honeymoon Beach again.  Here is where we saw the 5 ft barracuda (biggest that I’ve ever seen).  And yes, Carrie, he was looking at me.  We went for tea, met a nice couple from Mobile, and ended up talking with them until the sun set.  They have two kids and vacation with them, guess where, at St. Joseph’s Peninsula State Park!  Then, Chris took me to the fancy restaurant at Caneel where we enjoyed its beautiful view.

Sunday, June 28th

We hiked around Caneel Bay in the morning, as they have two really nice hiking trails with beautiful vistas.  Then, we went into town for the St. John festival.  We saw Miss St. John, heard a children’s steel band, and dinned on bbq chicken, lobster, macaroni and cheese, and rum cake.  Good times.  We spent the afternoon bumming around Caneel.  Chris read mostly, while I snorkeled.  All in all, it was a great afternoon.

No, I’m not at goal yet (the 190 lbs limit shown is incorrect), but the linear progress is quite hopeful! 

I’m still trying to decide what my goal weight should be.  The book’s “healthy weight range” is between a BMI of 20 and 25.  I’m currently at 24.4 with today’s weigh-in.  I think I’d like to split the range and focus on 23 as my target BMI; this translates to a weight of 185 lbs for the upper limit (23.8) and 180 lbs for the lower limit (23.1).

Only 5 pounds to go until I start on maintenance!

Now, one month and five Weight Watchers meetings later, I’m now down almost ten pounds, with about five to ten left.  Half-way there!