(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.

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!