BeagleBoard

The Beagle Board is a pocket-sized reference board containing a Texas Instruments OMAP3530 system-on-a-chip (SoC) processor (ARM Cortex A-8 core) running at up to 600MHz. (Find a link to more system specs in Resources later in this article.) Tiny reference boards are not themselves necessarily newsworthy—companies such as Gumstix have been providing similar boards for several years, including some based on the OMAP3530 processor. I picked the Beagle Board because it is an inexpensive platform for learning how Linux and small systems work. It is a reasonable alternative for hobbyists designing projects for themselves, academics creating projects for classes, and professionals designing low-cost appliances or thin clients.

For More Board Information visit:

www.beagleboard.org/static/BBSRM_latest.pdf 

Required Items To Bring-up :

Three items are required to boot the Beagle Board:
1.A desktop or laptop computer with a serial port (see the sidebar Notes on host platforms for more information)
2.A serial connector
3.A USB device cable, standard-A to mini-A

The Beagle Board comes with no cables or connectors. See the Beagle Board Shopping List (in Resources) for a list of required and optional items, as well as links to them. Most of the items shown here are available individually or as a package.

Serial connection:

For the serial connection, you need the following components:
1.IDC10-to-DB9M serial cable
2.DB9F-to-DB9F null modem cable
3.DB9M-to-USB cable (optional if your host platform has an RS-232 port)
4.USB mini-B male-to-USB A male cable

The combination of the first three cables gives you a serial connection, which enables you to watch and interact with the board’s bootloader and operating system through a terminal emulation program on your host platform.

Input and output:

For input and output, you need the following items:
1. Powered USB 3-port hub with Ethernet
2. 5mm barrel power plug-to-USB A male adapter
3. USB mini-A-to-USB A female On-The-Go (OTG) cable (optional; lets it be powered over its USB connection)

These items give you the maximum benefit from using a Linux distribution on your Beagle Board. The built-in Ethernet gives you a network connection. The hub itself gives you a USB port for providing power to the Beagle Board with the 5mm power plug.

Keyboard, video, mouse :

For keyboard-video-mouse (KVM) functionality, you need the following items:
1. HDMI male-to-DVI-D male cable
2. Digital monitor
3. USB keyboard
4. USB mouse

You may be tempted to use a PS/2 keyboard with a converter. Take my advice: buy a USB keyboard. A PS/2 keyboard would probably work with the Ångström Linux distribution, the demo described in this article, but you may well go further than this in the future, and not all distributions include a PS/2 driver.

You may also be tempted to try to use an analog (VGA) monitor or a DVI-D-to-VGA conversion cable. The Beagle Board does not emit the analog signal that would drive this setup, so using a converter or analog monitor would be fruitless. If your monitor does not accept digital (HDMI or DVI-D) input, consider using a TV and a 4-pin S-video cable, instead. Also note that audio does not work acceptably yet on Ångström, so don’t spend too much time trying to track down speakers or headphones.

SD cards :

You need at least one SD card to store Linux and its bootloaders. If you do not want to go through the process of downloading the software and partitioning the card, Special Computing (see Resources for a link) has a deal: You can order a 4GB SD card with the Ångström demo preloaded.

Connecting the components :

When you have all of the parts, it’s time to start plugging things in. First, connect the serial port by performing the following steps:
1. Plug the IDC10 cable into the Beagle Board with the cable’s pin 1 going to pin 1 of the connector (the pink wire on the ribbon cable faces the outer corner of the board).
2. Plug the DB9M end into the null-modem DB9F/DB9F cable.
3. Plug the DB9F/DB9F cable into your host platform, if it has a DB9 port. Otherwise, plug the cable into a DB9M/USB cable, then plug that into the host.

Next, connect USB and power:
1. Plug the USB mini-A end of the mini-A/USB A female cable into the Beagle Board’s USB mini-A connector.
2. Plug the powered USB hub into the USB A female end of the same cable.
3. Plug the USB end of the USB/5mm barrel cable into the hub.
4. Plug the 5mm barrel end into the Beagle Board’s barrel connector.

Note: Do not connect power to the hub yet.

Now, connect the keyboard, mouse, and video:
1. Plug the HDMI end of video cable into the Beagle Board’s HDMI connector.
2. Plug the DVI-D end into your monitor.
3. Plug the USB keyboard into the hub.
4. Plug the USB mouse into the hub.

Setting up the operating system:

The host system is ready and the Beagle Board is set up. All you need now is an operating system.

Downloadable binaries exist for many Linux distributions that run on the Beagle Board, with Ångström, Maemo, Ubuntu, and Android being the most popular. All are under active development, and all have been demonstrated in public by professionals and hobbyists alike. This article covers the Ångström distribution, which is well tested and lean enough that it turns the Beagle Board into a viable Linux desktop machine and not-so-thin client. See Resources for links to video demonstrations as well as to the Ångström binary download.

The Ångström Linux distribution :

1. First-stage bootloader
2. Second-stage bootloader
3. Linux boot image (uImage)
4. Linux file system

The Beagle Board’s firmware contains a first-stage bootloader called X-loader. X-loader can also be loaded from a removable storage space (such as an SD card) in a signed file called MLO. X-loader bootstraps the system only enough to load the second-stage bootloader, which otherwise would not fit into memory.

The second-stage bootloader provided in flash memory on the Beagle Board is U-boot, although most distributions provide their own version of U-boot in a file called u-boot.bin. U-boot initializes the system, then boots the Linux kernel. It can also be run from the console.

The Linux boot image, named uImage, finally boots the Linux kernel, which resides in the Linux file system in the /boot directory.

There are several ways to set up the file system; the method shown here requires a bit of work at the beginning but is flexible. Also note that this is the way the pre-built Ångström SD cards arrive if you order them from Special Computing.

How Linux Boot (For Intel x86 Architecture) :

Stage 1 Boot Loader : 

The primary boot loader that resides in the MBR is a 512-byte image containing both program code and a small partition table (see Figure 2). The first 446 bytes are the primary boot loader, which contains both executable code and error message text. The next sixty-four bytes are the partition table, which contains a record for each of four partitions (sixteen bytes each). The MBR ends with two bytes that are defined as the magic number (0xAA55). The magic number serves as a validation check of the MBR.

The job of the primary boot loader is to find and load the secondary boot loader (stage 2). It does this by looking through the partition table for an active partition. When it finds an active partition, it scans the remaining partitions in the table to ensure that they’re all inactive. When this is verified, the active partition’s boot record is read from the device into RAM and executed.

Stage 2 Bootloader :

The secondary, or second-stage, boot loader could be more aptly called the kernel loader. The task at this stage is to load the Linux kernel and optional initial RAM disk.

The first- and second-stage boot loaders combined are called Linux Loader (LILO) or GRand Unified Bootloader (GRUB) in the x86 PC environment. Because LILO has some disadvantages that were corrected in GRUB, let’s look into GRUB.

The great thing about GRUB is that it includes knowledge of Linux file systems. Instead of using raw sectors on the disk, as LILO does, GRUB can load a Linux kernel from an ext2 or ext3 file system. It does this by making the two-stage boot loader into a three-stage boot loader. Stage 1 (MBR) boots a stage 1.5 boot loader that understands the particular file system containing the Linux kernel image. Examples include reiserfs_stage1_5 (to load from a Reiser journaling file system) or e2fs_stage1_5 (to load from an ext2 or ext3 file system). When the stage 1.5 boot loader is loaded and running, the stage 2 boot loader can be loaded.

With stage 2 loaded, GRUB can, upon request, display a list of available kernels (defined in /etc/grub.conf, with soft links from /etc/grub/menu.lst and /etc/grub.conf). You can select a kernel and even amend it with additional kernel parameters. Optionally, you can use a command-line shell for greater manual control over the boot process.

With the second-stage boot loader in memory, the file system is consulted, and the default kernel image and initrd image are loaded into memory. With the images ready, the stage 2 boot loader invokes the kernel image.

Kernel Image : 

With the kernel image in memory and control given from the stage 2 boot loader, the kernel stage begins. The kernel image isn’t so much an executable kernel, but a compressed kernel image. Typically this is a zImage (compressed image, less than 512KB) or a bzImage (big compressed image, greater than 512KB), that has been previously compressed with zlib. At the head of this kernel image is a routine that does some minimal amount of hardware setup and then decompresses the kernel contained within the kernel image and places it into high memory. If an initial RAM disk image is present, this routine moves it into memory and notes it for later use. The routine then calls the kernel and the kernel boot begins.

When the bzImage (for an i386 image) is invoked, you begin at ./arch/i386/boot/head.S in the start assembly routine (see Figure 3 for the major flow). This routine does some basic hardware setup and invokes the startup_32 routine in ./arch/i386/boot/compressed/head.S. This routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS). The kernel is then decompressed through a call to a C function called decompress_kernel (located in ./arch/i386/boot/compressed/misc.c). When the kernel is decompressed into memory, it is called. This is yet another startup_32 function, but this function is in ./arch/i386/kernel/head.S.

In the new startup_32 function (also called the swapper or process 0), the page tables are initialized and memory paging is enabled. The type of CPU is detected along with any optional floating-point unit (FPU) and stored away for later use. The start_kernel function is then invoked (init/main.c), which takes you to the non-architecture specific Linux kernel. This is, in essence, the main function for the Linux kernel.

With the call to start_kernel, a long list of initialization functions are called to set up interrupts, perform further memory configuration, and load the initial RAM disk. In the end, a call is made to kernel_thread (in arch/i386/kernel/process.c) to start the init function, which is the first user-space process. Finally, the idle task is started and the scheduler can now take control (after the call to cpu_idle). With interrupts enabled, the pre-emptive scheduler periodically takes control to provide multitasking.

During the boot of the kernel, the initial-RAM disk (initrd) that was loaded into memory by the stage 2 boot loader is copied into RAM and mounted. This initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical disks. Since the necessary modules needed to interface with peripherals can be part of the initrd, the kernel can be very small, but still support a large number of possible hardware configurations. After the kernel is booted, the root file system is pivoted (via pivot_root) where the initrd root file system is unmounted and the real root file system is mounted.

The initrd function allows you to create a small Linux kernel with drivers compiled as loadable modules. These loadable modules give the kernel the means to access disks and the file systems on those disks, as well as drivers for other hardware assets. Because the root file system is a file system on a disk, the initrd function provides a means of bootstrapping to gain access to the disk and mount the real root file system. In an embedded target without a hard disk, the initrd can be the final root file system, or the final root file system can be mounted via the Network File System (NFS).

Root File System (Init Process):

After the kernel is booted and initialized, the kernel starts the first user-space application. This is the first program invoked that is compiled with the standard C library. Prior to this point in the process, no standard C applications have been executed.

In a desktop Linux system, the first application started is commonly /sbin/init. But it need not be. Rarely do embedded systems require the extensive initialization provided by init (as configured through /etc/inittab). In many cases, you can invoke a simple shell script that starts the necessary embedded applications.

Resources : 

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

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