Add an introduction sequence to a Theora video

FilmTo produce new HD videos from the Embedded Linux Conference, we needed a new script to add an introduction sequence to the videos we processed.

To make all this automatic, and to suppress the need to go through interactive tools (such as kdenlive) to produce a title with a fade-in / fade-out effect, I created a new theora-intro script. The process got much more complex than I expected, but fortunately, I got a lot of valuable advise and help from the Theora mailing list, and could hide all this complexity inside the script. That’s what scripts are for!

A nice feature. compared to the interactive video editors, is that no extra video processing pass is needed. Thanks to this, even a big video file can be processed within a few minutes. Another useful feature is that the script preserves the Ogg metadata (artist, title, location, copyright…).

So, if you wish to add an introduction sequence to your own videos, whatever their initial format, first convert them to Theora using ffmpeg2theora. Then, create a title image for your video, and then run theora-intro on it.

You can find all useful details on our theora-intro page.

ELC 2009 videos

My Colleague Thomas and I had the privilege to participate to the 2009 edition of the Embedded Linux Conference, which took place in San Francisco, on April 6-8. In spite of the weak economy, this event was once again a success. It attracted major developers from the embedded Linux community, as well as participants from all over the word.

Following the tradition, we are proud to release new videos about this event. These videos were shot by Satoru Ueda and Tim Bird (Sony), and by Thomas Petazzoni and Michael Opdenacker (Bootlin). For the first time, we used an HD camcorder to shoot some of the videos. A higher resolution allows to read the slides projected on the screen. As usual, the videos are released with a Creative Commons Attribution – ShareAlike 3.0 license.

Thomas and I found the following talks particularly interesting:

  • Ubiquitous Linux, by Dirk Hohndel
  • Embedded Linux and Mainline Kernel, by David Woodhouse
  • What are Interrupt Threads and How Do They Work?, by Reece Pollack
  • Visualizing Process Memory, by Matt Mackall
  • KProbes and Systemtap Status, by Tim Bird
  • Deploying LTTng on Exotic Embedded Architectures, by Mathieu Desnoyers
  • Embedded Linux on FPGAs for fun and profit, by Dr John Williams (Petalogix)
  • Linux on Embedded PowerPC porting guide, by Grant Likely
  • Understanding and writing an LLVM Compiler Backend, by Bruno Cardoso Lopes

You may be interested in watching the presentations we made and the BOFs we led:

  • Building Embedded Linux Systems with Buildroot, by Thomas Petazzoni. In these last months, Thomas has made big contributions to this build system.
  • Build tools BOF, by Thomas Petazzoni
  • Update on filesystems for flash storage, by Michael Opdenacker
  • System Size BOF, by Michael Opdenacker

Of course, lots of other talks were very interesting. See the whole list by yourself:

theora-intro

Add an introduction sequence to a Theora video

Introduction

For the needs of producing conference videos, we developed a Python script to add an introduction sequence to a given Ogg/Theora video:

Usage: theora-intro [options] input-video title-image output-video

Adds an introduction to a source Ogg/Theora video, using the given title image

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -v, --verbose         Verbose mode
  --artist=ARTIST       Overrides the ARTIST Ogg metadata
  --title=TITLE         Overrides the TITLE Ogg metadata
  --date=DATE           Overrides the DATE Ogg metadata
  --location=LOCATION   Overrides the LOCATION Ogg metadata
  --organization=ORGANIZATION
                        Overrides the ORGANIZATION Ogg metadata
  --copyright=COPYRIGHT
                        Overrides the COPYRIGHT Ogg metadata
  --license=LICENSE     Overrides the LICENSE Ogg metadata
  --contact=CONTACT     Overrides the CONTACT Ogg metadata

Why was this script created?

This script was created especially for people who need to produce multiple videos, typically from the same event. So far, the only way to add an introduction video with fade-in and fade-out was through interactive video editors, such as kdenlive, and this required to encode the video again. Another reason to create a script is that the sequence of commands to run and the amount of data to extract and generate is rather complex. Having a script rather than just a howto thus reduces the risk of errors and mistakes.

Downloads

All the releases of theora-intro can be found here.

How it works

To create an introduction sequence and concatenate it to the input video, theora-intro first needs to collect information from the input video. In particular, it reads the video width, height, the number of frames per seconds, as well as the audio bitrate and sample frequency, which need to be the same in the introduction sequence.

The introduction sequence shows the input title image (scaled), which fades in from a black picture, and eventually fades out to black again. The script actually generates a series of PNG images (using ImageMagick‘s convert utility), and converts this series into a video using ffmpeg2theora. Any input image format should work (JPG, GIF, PNG…), as ImageMagick supports most existing formats.

To be complete, the introduction sequence also needs an audio track. If it didn’t, the output video wouldn’t have any. Therefore, theora-intro generates a silent sample in WAV format, and converts it to Ogg/Vorbis.

The audio and video for the introduction sequence are then merged and concatenated. For some reasons still a bit unclear, the audio tracks of the introduction and input videos need to be resampled, but at last, there is no need to encode the video again. This makes theora-intro much faster than the time it takes to encode the video (just a few minutes even for big video files encoded in several hours).

You can find out more details by reading the code! It shoudn’t be difficult to understand it.

Ogg Metadata

It is useful to produce Ogg/Theora videos with appropriate metadata (artist, title, location, copyright…). If the input video contains such metadata, these metadata are also replicated to the generated video. Note that theora-intro has options to override these metadata when needed, or when there are no such metadata in the input video.

Requirements

This script relies on several software packages and libraries:

In Ubuntu and Debian, you can get the first four packages as follows:

sudo apt-get install vorbis-tools imagemagick ffmpeg2theora oggz-tools

Anyway, if any of the above packages is missing, theora-intro will let you know.

Use in real life

theora-intro was used to produce videos from the 2009 edition of the Embedded Linux Conference.

Known issues

At the moment, videos generated with the latest release still show a few warnings with the ogginfo command:

$ ogginfo elc2009-bird-closing.ogv 
Processing file "elc2009-bird-closing.ogv"...

New logical stream (#1, serial: 376a8b22): type theora
New logical stream (#2, serial: 06fd37a7): type vorbis
Theora headers parsed for stream 1, information follows...
Version: 3.2.1
Vendor: Xiph.Org libTheora I 20081020 3 2 1
Width: 1280
Height: 720
Total image: 1280 by 720, crop offset (0, 0)
Framerate 25/1 (25.00 fps)
Aspect ratio undefined
Colourspace: Rec. ITU-R BT.470-6 Systems B and G (PAL)
Pixel format 4:2:0
Target bitrate: 0 kbps
Nominal quality setting (0-63): 63
User comments section follows...
	TITLE=Tim Bird (Sony)- ELC Closing
	DATE=May 2009
	LOCATION=San Francisco
	ORGANIZATION=Bootlin
	COPYRIGHT=Bootlin
	LICENSE=Creative Commons BY-SA 3.0
	CONTACT=feedback@...
	ENCODER=ffmpeg2theora-0.23
Vorbis headers parsed for stream 2, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20070622 (1.2.0)
Channels: 2
Rate: 48000

Nominal bitrate: 48.000000 kb/s
Upper bitrate not set
Lower bitrate not set
User comments section follows...
	ENCODER=oggVideoTools 0.8
Warning: Expected frame 5265, got 5266
Warning: Expected frame 5270, got 5269
Warning: Expected frame 12663, got 12664
Warning: Expected frame 12667, got 12666
Warning: Expected frame 13657, got 13658
Warning: Expected frame 13660, got 13659
Warning: Expected frame 14213, got 14214
Warning: Expected frame 14218, got 14217
Warning: Expected frame 14875, got 14876
Warning: Expected frame 14879, got 14878
Warning: Expected frame 17635, got 17636
Warning: Expected frame 17638, got 17637
Vorbis stream 2:
	Total data length: 4322809 bytes
	Playback length: 11m:57.264s
	Average bitrate: 48.214426 kb/s
Logical stream 2 ended
Theora stream 1:
	Total data length: 49233283 bytes
	Playback length: 11m:57.320s
	Average bitrate: 549.080277 kb/s
Logical stream 1 ended

These warnings don’t seem to create any issue in Ogg/Theora players. They are probably caused by an issue in the Ogg Video Tools, and we have reported this to their maintainer.

On the road to Buildroot 2009.08

Buildroot logoAs I posted back in March, the Buildroot project has begun a new life since January. One of the aspects this new life is the fact that stable releases are delivered every three months. So we had one in February (2009.02), one in May (2009.05) and therefore we’re going to have one release soon in August (2009.08).

Peter Korsgaard, Buildroot’s maintainer, has just released 2009.08-rc1, a good opportunity to look at what’s new in Buildroot since the last release. To highlight Bootlin’sparticipation in the free software community, it is worth noting that in number of patches, I’m the second most important contributor to Buildroot, right after Peter, the maintainer. It’s really nice that I’ve been able to find enough time to contribute at such a level to Buildroot, and hope to be able to dedicate more time in the future to Buildroot, since we have lots of ideas to improve the project.

Back to the 2009.08 release specifically, in the notable features or improvements, we have :

  • Improvement of external toolchain support. I’ve already posted about this specific feature, that I find very important. Several reports from people using this feature have been received since then, which means that it is a useful feature for some of the Buildroot users. So, we have now support for glibc toolchains, the configuration provided to Buildroot is verified against the real toolchain configuration, the copy of the toolchain libraries to the target has been improved (including the C++ standard library) and other minor improvements have been. I’ve been the major contributor of these improvements, together with the reports provided by Buildroot users
  • Integration of the QT-based configurator. Buildroot uses the kconfig system from the kernel to allow its users to configure the different elements of the system to be built. Until now, only the ncurses interface (make menuconfig) was supported. In the 2009.08, the QT interface (make xconfig) will also be supported, adding a little more userfriendliness to Buildroot. This feature was contributed by Alper Yildirim, and I helped in polishing the remaining issues.
  • Support for the Xtensa architecture has been contribued by Maxim Grigoriev, from Tensilica, the company designing the Xtensa architecture.
  • Cleanup of X.org support. the configuration options were clarified, and mandatory dependencies on useless libraries such as libXt or libXaw were removed, some components were upgraded to fix build issues. It’s also a task I contributed to.
  • Of course, toolchain components have been upgraded (GCC 4.4.1, 2.6.30 kernel headers), new packages have been added (bmon, ctorrent, dosfstools, enchant, gst-plugins-bad, iw, libmms, libnl, netstat-nat, ntfsprogs, sdl_gfx, spawn-fcgi), and many more packages have been upgraded (bind, busybox, coreutils, sqlite, directfb, expat, gamin, gnuconfig, haserl, ipsec-tools, classpath, libcurl, libglib2, liblockfile, libpng, libsoup, libxml2, lighttpd, ltp-testsuite, lvm2, matchbox, memstat, gst-plugins-good, gstreamer, libogg, libvorbis, mplayer, neon, openssl, pciutils, php, qt, ruby, sawman, webkit, wpa-supplicant, xdriver_xf86-input-synaptics, xdriver_xf86-video-intel, xlib_libXfont, xlib_libXft, xlib_libXt, xproto_xproto, xserver-xorg, xutil_makedepend, xutil_util-macros)
  • We’re also paying a lot more attention to the bugs reported in our bugtracker than we used to do in the past. Since 2009.05, 43 reported issues have been fixed, and I except that we will fix some more before the 2009.08 release

Shortly after the 2009.08, we will set the goals for the next 2009.11 release, and I’d like to do a lot of cleanup to make Buildroot easier to use and to understand. We’ll see how things go.

In the mean time, if you’re interested in testing and improving Buildroot, don’t hesitate to grab 2009.08-rc1, try it in your conditions with your package set, and report your issues!

Switching between toolchains made easy!

It is quite common to have several toolchains and to switch back and forth between them while doing development. At least, this is something I do a lot when doing Buildroot development and debugging. As I hate typing full paths all the time, I usually put the toolchain bin/ directory into my $PATH variable, so that I can easily access the toolchain binaries. However, it means that everytime you run a new shell or everytime you want to switch from one toolchain to another, you need to modify the PATH variable manually by re-exporting it. Of course, one could easily put all the bin/ directories of all toolchains in the PATH, but that would clutter what is shown when I do arm-TAB-TAB, and that’s not nice.

So, I ended up hacking a few lines of Bash that provide me with two new commands: xtoolsadd, to add a toolchain to my PATH and xtoolsdel, to remove a toolchain from my PATH. These commands work by making the assumption that all toolchains are stored in a common directory. In my case /usr/local/xtools/ contains all the toolchains, one per subdirectory. So I have /usr/local/xtools/arm-unknown-linux-gnu for an ARM glibc-based non-EABI toolchain, or /usr/local/xtools/arm-unknown-linux-uclibcgnueabi for an ARM uClibc-based EABI toolchain).

So, now I can do things such as

xtoolsadd arm-unknown-linux-gnu

or

xtoolsdel arm-unknown-linux-uclibcgnueabi

Because these commands must modify the PATH variable of the current shell, they cannot be implemented as separate shell scripts, so they are in fact implemented as functions in my ~/.bashrc script. And in addition to these functions, I also implemented completion, so when you do xtoolsadd TAB-TAB, it gives you a choice of toolchains, and if you start typing one and press TAB, it will just automatically complete for you. The same thing works with xtoolsdel, of course.

To make this work, here is what you need to put in your ~/.bashrc file:

export XTOOLSDIR=/usr/local/xtools

xtoolsadd() {
    TOOLCHAINDIR=$XTOOLSDIR/$1/bin
    if [ ! -d $TOOLCHAINDIR ] ; then
        echo "Directory $XTOOLSDIR doesn't exist"
    else
        case "$PATH" in
            *"$XTOOLSDIR"*)
                ;;
            *)
                export PATH=$TOOLCHAINDIR:$PATH
        esac
    fi
}

xtoolsdel() {
    TOOLCHAINDIR=$XTOOLSDIR/$1/bin
    NEWPATH=
    found=0
    for i in $(echo $PATH | tr ":" "\n") ; do
        if [ $i == $TOOLCHAINDIR ] ; then
            found=1
        else
            NEWPATH=$NEWPATH:$i
        fi
    done
    if [ $found == 0 ] ; then
        echo "$1 is not in your PATH"
    else
        export PATH=$NEWPATH
    fi
}

_xtoolsadd() {
    cur=${COMP_WORDS[COMP_CWORD]}
    LIST=$(ls -1 $XTOOLSDIR | tr "\n" " ")
    COMPREPLY=( $( compgen -W "$LIST" -- $cur))
}

_xtoolsdel() {
    cur=${COMP_WORDS[COMP_CWORD]}
    LIST=$(echo $PATH | tr ":" "\n" | grep "^$XTOOLSDIR" | sed "s%$XTOOLSDIR/\([^/]*\)/bin%\1%")
    COMPREPLY=( $( compgen -W "$LIST" -- $cur))
}

complete -F _xtoolsadd xtoolsadd
complete -F _xtoolsdel xtoolsdel

The shell code may not be perfect or fully optimized, but it works. Of course, if you have suggestions or questions, don’t hesitate to post comments!

Linux 2.6.30 – New features for embedded systems

Interesting features in Linux 2.6.30 for embedded system developers

Linux 2.6.30 has been released almost 1 month ago and it’s high time to write a little about it. Like every new kernel release, it contains interesting features for embedded system developers.

The first feature that stands out is support for fastboot. Today, most devices are initialized in a sequential way. As scanning and probing the hardware often requires waiting for the devices to be ready, a significant amount of cpu time is wasted in delay loops. The fastboot infrastructure allows to run device initialization routines in parallel, keeping the cpu fully busy and thus reducing boot time in a significant way. Fasboot can be enabled by passing the fastboot parameter in the kernel command line. However, unless your embedded system uses PC hardware, don’t be surprised if you don’t get any boot time reduction yet. If you look at the code, you will see that the async_schedule function is only used by 4 drivers so far, mainly for disk drives. You can see that board support code and most drivers still need to be converted to this new infrastructure. Let’s hope this will progress in future kernel releases, bringing significant boot time savings to everyone.

Tomoyo LinuxLinux 2.6.30 also features the inclusion of Tomoyo Linux, a lightweight Mandatory Access Control system developed by NTT. According to presentations I saw quite a long time ago, Tomoyo can be used as an alternative to SELinux, and it just consumes a very reasonable amount of RAM and storage space. It should interest people making embedded devices which are always connected to the network, and need strong security.

Another nice feature is support for kernel images compressed with bzip2 and lzma, and not just with zlib as it’s been the case of ages. The bzip2 and lzma compressors allow to reduce the size of a compressed kernel in a significant way. This should appeal to everyone interested in saving a few hundreds of kilobytes of storage space. Just beware that decompressing these formats requires more CPU resources, so there may be a price to pay in terms of boot time if you have a slow cpu, like in many embedded systems. On the other hand, if you have a fast cpu and rather slow I/O, like in a PC, you may also see a reduction in boot time. In this case, you would mainly save I/O time copying a smaller kernel to RAM, and with a fast cpu, the extra decompression cost wouldn’t be too high.

However, if you take a closer look at this new feature, you will find that it is only supported on x86 and blackfin. Alain Knaff, the author of the original patches, did summit a patch for the arm architecture, but it didn’t make it this time. Upon my request, Alain posted an update to this arm patch. Unfortunately, decompressing the kernel no longer works after applying this patch. There seems to be something wrong with the decompression code… Stay tuned on the LKML to follow up this issue. Note that the blackfin maintainers took another approach, apparently. They didn’t include any decompression code on this architecture. Instead, they relied on the bootloader to take care of decompression. While this is simpler, at least from the kernel code point of view, this is not a satisfactory solution. It would be best if the arm kernel bootstrap code took care of this task, which would then work with any board and any bootloader.

Another interesting feature is the inclusion of the Microblaze architecture, a soft core cpu on Xilinx FPGAs. This MMU-less core has been supported for quite a long time by uClinux, and it’s good news that it is now supported in the mainline kernel. This guarantees that this cpu will indeed be maintained for a long time, and could thus be a good choice in your designs.

Other noteworthy features are support for threaded interrupt handlers (which shows that work to merge the real-time preempt patches is progressing), ftrace support in 32 and 64 bit powerpc, new tracers, and of course, several new embedded boards and many new device drivers.

As usual, full details can be found on the Linux Kernel Newbies website.

The Bifferboard: tiny, low power embedded x86 board

A nice, cheap and tiny x86 embedded board that runs Linux and just consumes 1W. It has all the basic connectivity you need in an embedded system.

As you may already know, we maintain a list of attractive and Linux friendly embedded boards. Whenever we find a new board that is attractive and meets our strict criteria (supporting Linux or other free kernels, public pricelist, public documentation and website with an English version), we add this board to our list. This way, we don’t forget about any useful board, and we can offer useful guidance to our customers and to any embedded system developer looking for a suitable hardware platform.

Somebody at Bifferos.com has just contacted us to let us know about their Bifferboard product. Here are its announced features:

  • Bifferboard150MHz RDC CPU, Intel 486SX compatible
  • 1 watt power consumption (200mA @5v)
  • 68mm x 28mm x 19mm
  • 32MB SDRAM/1MB Flash
  • OHCI/EHCI USB 2.0
  • 10/100 Ethernet
  • Serial console 115200 baud
  • 4-pin JTAG (can be used as GPIO)
  • 2 GPIO (1 LED, 1 button)
  • Linux 2.6.27.5 + OpenWrt
  • 29 UK pounds

The board has two components: the CPU board, and the I/O one, offering Ethernet and USB host connectivity. For a serial port, you can order a special cable from their shop, which connects to a USB port on your workstation.

Thanks to its low power consumption, the Bifferboard can even be powered by USB. According to its makers, the board can do anything a NSLU2 device can do. It is just cheaper (approximately 33 EUR at the time of this writing).

Last but not least, most Bifferboard hardware can be emulated with QEMU.

While it could also be suitable for mass production projects, it can be at least a nice platform for prototypes, hobby, research and educational projects.

Of course, if you know about other attractive boards that we could add to our list, please post a comment or send us e-mail.

Buildroot gains better support for external toolchains

Buildroot logoBuildroot is a tool that I’ve already covered in a previous blog post. To me, its main purpose is to build the root filesystem for an embedded Linux system, with all the necessary applications and libraries. It automates the tedious process of cross-compiling and integrating all the free software components in an embedded system.

In addition to root filesystem generation, Buildroot is also known for its ability to generate a uClibc-based cross-compilation toolchain. Buildroot used to be for quite some time the only way to generate a toolchain based on this size-effective C library, but it is no longer the case with Crosstool-NG supporting glibc, uClibc and eglibc.

However, I’ve personaly never been really satisfied with uClibc generation of cross-compiling toolchains:

  • It mixes the process of the cross-compilingn toolchain generation with the process of root filesystem generation, which are, in my opinion, two very different processes. Once your toolchain is generated, you generally don’t touch it, but regenerate your root filesystem dozens or hundred of times until all your components are here and properly integrated.
  • The attention paid to toolchain generation in the Buildroot project itself is relatively small, while other projects like Crosstool-NG or vendors like Codesourcery, are specifically dedicated to providing toolchains. The fact that, for example, uClibc is the only C library supported is one example of this.
  • It might necessary, for various reasons, make sense to use an already existing toolchain.

Support for the usage of external toolchains has already been present in Buildroot for a long time, but wasn’t developed enough to be easily usable. Months ago, I’ve started to improve the situation (here, here, here and here), and last week, two other patches have been integrated.

  • The first patch, visible here removes the ugly configuration option that allows to configure the set of libraries that must be copied to the target filesystem, and replaces it with a nice selection of the C libary type: uClibc or glibc. It makes it clear that generating Linux system with the glibc library is possible with Buildroot, even if Buildroot has often been advertised as a uClibc only tool.
  • The second patch, visible here adds checks for the conformity of Buildroot configuration versus the C library configuration. There are configuration options in Buildroot that must tell whether the C library supports IPv6, supports RPC, supports locale, supports large file, etc. These options must be set in the configuration interface according to the C library configuration, because some userspace packages depend on them. The added checks verify that the value set to these options match the configuration of your C library

So, now, external toolchains are a little bit easier to use with Buildroot, and your own vendor toolchain, Codesourcery toolchains or any other toolchain can be used with Buildroot. The only requirement is that the toolchain supports the sysroot feature, which is very common in most toolchains.

Building Android on Beagle

Note: these instructions are now out of date and refer to URLs which no longer exist. See the elinux.org wiki for more recent instructions.

These instructions are derived from Embinux.org’s Android Porting Guide to Beagle Board (the corresponding web page no longer exists), based on their work to port Android on the Beagle board. They correct multiple inaccuracies in this guide, and also add many useful details.

These instructions were tested on xubuntu 9.04. There shouldn’t be many differences if you use other recent Ubuntu or Debian versions.

Install needed software packages

At the time of this writing, note that Android requires Sun’s Java5 JDK, and doesn’t support the Java6 one.

apt-get update
apt-get dist-upgrade
apt-get install git-core bison sun-java5-jdk flex g++ zlib1g-dev
apt-get install  libx11-dev libncurses5-dev gperf uboot-mkimage

Android also uses its own repo script as a git front-end:

mkdir -p ~/bin
cd ~/bin
curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > repo
chmod +x repo

We are also going to need a 2007q3 toolchain from Code Sourcery

cd
wget http://www.codesourcery.com/sgpp/lite/arm/portal/package1787/public/arm-none-linux-gnueabi/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
cd /opt
sudo tar jxf arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

You could also get this toolchain from our website:

cd
wget /pub/demos/beagleboard/android/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.lzma
cd /opt
sudo tar --lzma -xf ~/arm-2007q3-51-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.lzma

Download sources

Our instructions create a directory in your home directory, but of course, it can be placed anywhere!

 mkdir ~/beagledroid
 cd ~/beagledroid
 repo init -u git://labs.embinux.org/repo/android/platform/beaglemanifest.git/
 repo sync

Caution: this can take a lot of time, as this downloads and extracts 2.4 GB of data. On a fast workstation with a 500KB/s Internet connection, it took about 90 minutes.

Building Android

make

If your workstation has multiple CPUs, you could save a lot of time by running multiple jobs in parallel:

make -j 4

On our machine, this took about 4 hours!

Building the kernel

export CC_PATH=/opt/arm-2007q3/bin/arm-none-linux-gnueabi-
cd ~/beagledroid/kernel
../vendor/embinux/support-tools/beagle_build_kernel.sh

Copying the Android root filesystem

Android’s root file system is generated in ~/beagledroid/out/target/product/generic

cd ~/beagledroid/out/target/product/generic
mkdir ~/beagledroid/rootfs
cp -a root/* ~/beagledroid/rootfs/
cp -a system/* ~/beagledroid/rootfs/system/
cd ~/beagledroid/rootfs
sudo chown -R root.root .
sudo chmod -R a+rwX data system

Formatting an MMC/SD card

First connect your card reader to your workstation, with the MMC/SD card inside. Type the dmesg command to see which device is used by your workstation. Let’s assume that this device is /dev/sdb

Type the mount command to check your currently mounted partitions. If MMC/SD partitions are mounted, unmount them.

In a terminal edit partitions with fdisk:

sudo fdisk /dev/sdb

Delete any existing partition with the d command.

Now, create the boot partition:

Command (m for help): n 
Command action 
   e   extended 
   p   primary partition (1-4) 
p 
Partition number (1-4): 1 
First cylinder (1-239, default 1): 1 
Last cylinder, +cylinders or +size{K,M,G} (1-239, default 239): +64M

Change its type to FAT32:

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))

Using the n command again, create a second partition filling up the rest of your card (just accept default values).

Now, format the partitions in your card:

sudo mkfs.vfat -n beagleboot -F 32 /dev/sdb1
sudo mkfs.ext3 /dev/sdb2

Remove and insert your card again. Your new partitions should be mounted automatically.

Copying data to the MMC/SD card

Start by copying the X-loader and U-boot on the first partition.

cd /media/beagleboot
wget /pub/demos/beagleboard/android/MLO
/pub/demos/beagleboard/android/u-boot.bin
cp ~/beagledroid/kernel/arch/arm/boot/uImage .

Now copy the Android root filesystem to the second partition (assuming it is mounted on /media/disk:

sudo rsync -a ~/beagledroid/rootfs/ /media/disk/

Finish by unmounting your MMC/SD partitions:

sudo umount /media/beagleboot
sudo umount /media/disk

Boot setup

The last thing left to do is to specify how the board boots Linux.

Plug the Beagle board on your computer, and also connect it to a DVI-D monitor. Start minicom (corresponding to Hyperterminal in Windows) on /dev/ttyS0, or on /dev/ttyUSB0 if you are using a serial to USB adapter. Power up the board.

First, stop Minicom from truncating long lines by typing [Ctrl] [a] followed by z and w.

In the U-boot prompt, make the board boot automatically on the MMC/SD card:

setenv bootcmd 'mmc init;fatload mmc 0 80000000 uImage;bootm 80000000'
saveenv

Now set the kernel command line arguments:

setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/mmcblk0p2 video=omapfb.mode=dvi:1280x720MR-24@50 init=/init rootfstype=ext3 rw rootdelay=1 nohz=off androidboot.console=ttyS2

You may need to adapt the video settings to the capabilities of your DVI display. You should now see Android boot!

Beagle board MMC boot myths?

Booting a Beagle board from an MMC/SD should be easier than what people tell you

Beagle boardAt the time of this writing, most documentation that you can find on the web about the Beagle board will tell you that you need to take special preparation steps if you wish to boot your board on an MMC/SD card:

  • The card requires a special geometry: 255 heads and 63 sectors per track
  • The first partition on the card, with a FAT type, must be marked as bootable
  • The X-loader (MLO file), must be copied to the first sectors of the first partition. As a consequence, you should copy this file first.

As my colleague Florent Peyraud and TI engineers started to suspect, all this is not always required. I’ve just made tests with my Rev C2 Beagle board:

  • I took a brand new MMC/SD card. fdisk showed that it had 57 heads and 56 sectors per track.
  • I created the partitions again, and didn’t flag the first one as bootable.
  • After formatting the first partition in FAT32 format, I first copied the u-boot.bin and uImage files, and then the MLO one.

After all this, I had no problem booting my Beagle board on the MMC/SD card. At least with my Rev C2 board, what TI engineers expected was true: the board romcode understood the FAT format, and therefore just needed a file with the MLO name, whatever its physical location on the card.

Does anyone know whether the requirements used to be true with earlier Beagle board romcode releases, or in special cases?