FSOSS 2010 Plug Computing Workshop

This page outlines the Plug Computing workshop held at FSOSS 2010 - Thursday, October 28, 2010, room T2108.

ARM Chips, Fedora, and Plug Computers, Oh My!

The ARM Processor

ARM CPUs were originally created as 32-bit desktop RISC processors. They have become highly valued as low-power-consumption processors, and are widely used in cellphones, tablets, and embedded systems; over 5 billion ARM devices are now manufactured annually.

ARM Ltd. does not actually produce any physical chips -- they license the designs to various chipmakers, who then incorporate them into their products, often integrating other peripherals in the process -- peripherals such as camera controllers, network interfaces, or cellphone logic. ARM licensees include Marvell, Texas Instruments, Samsung, Freescale, and many others.

Plug Computing

Two models of Plug Computers: A SheevaPlug (left) and GuruPlug (right)

The PlugComputer concept was created by Marvell to promote the use of ARM processors in non-mobile environments -- as a power-saving server option. Each PlugComputer contains a Marvell system-on-a-chip (SOC) and flash-based storage.

The model of PlugComputer we're using today is the GuruPlug Server Plus, made by GlobalScale Technologies, Inc as a development system. This unit features:

• 512MB of DDR2 RAM
• 512MB of built-in NAND flash memory
• a microSD/microSDHC card reader
• dual gigabit ethernet interfaces
• an eSATA disk connector
• two USB ports
• 802.11bg wireless
• bluetooth

The total power consumption of the GuruPlug is typically under 5W - about that of a small nightlight.

Fedora

The Fedora Project is a community sponsored by Red Hat which produces a Linux distribution. The Fedora distribution is typically used on 32- and 64-bit Intel/AMD-compatible processors, which are known as the "Primary Architectures". However, there are a number of special interest groups within Fedora which compile the distribution for use on other, secondary architectures, including PowerPC, IA64 (Itanium), SPARC, MIPS, IBM mainframe (Z9), and ARM systems.

Fedora software is maintained as a large collection of separate packages -- over 15,000 at the present time. These packages can be combined in various combinations to meet different needs (desktop, server, mobile).

Fedora utilizes the Koji client-server based build system which permits any package maintainer to submit a build request to a build master, which they passes jobs off to individual builders. Seneca College is hosting the Fedora ARM Koji system, which is being used to compile Fedora 13 and subsequent releases.

How Computing with ARM is Different from Computing on a PC

Bootloader and Console

A PC typically contains BIOS or EFI software in a ROM or flash memory. This code initializes the system and then loads and executes a bootloader, using features and conventions such as disk partitioning and video BIOS extensions.

The BIOS standard is very closely tied to the Intel/AMD architecture, and generally relies upon the presence of a video card through the boot process. ARM systems typically use a light-weight bootloader named das u-Boot (or just u-Boot, for universal bootloader). Some systems, such as the BeagleBoard, use an earlier bootloader (x-loader) that load u-Boot; others run u-Boot directly.

u-Boot may be used interactively through a console interface, which may be provided through a video connection, or more commonly, through a serial port. Some systems, such as the SheevaPlug, provide a built-in USB-to-serial converter; on the GuruPlug, the console capability is provided by an external adapter.

JTAG

Since u-Boot is stored in flash memory, a failure during the programming of the flash memory may leave a device in an unbootable and non-updatable state ("bricked"). In this state, the only option for reprogramming the flash memory is to use a low-level chip-testing technology known as IEEE 1149.1 or JTAG (from the Joint Test Action Group which created the standard). Almost all modern semiconductor devices feature a JTAG port for testing during manufacture; many ARM devices provide access to this port for unbricking. On the GuruPlug, JTAG access is provided through the same external adapter used for console access.

Storage

Although ARM devices can use normal mechanical disk drives, most use flash memory. Flash memory is non-volatile, consumes little power, and is quite fast for reading, but most types of flash have a limitation of as little as 10,000 write cycles and may be slow for writing. Expandable storage is often provided in the form of SD or microSD cards.

In order to accommodate the performance characteristics of flash memory, the Linux kernel provides the MTD (Memory Technology Device) subsystem, as well as the UBI (Unsorted Block Image) and JFS (Journalled Flash File System) subsystems.

Setting up the GuruPlug

Before you can use the GuruPlug for useful work, you need to install Fedora on a microSD flash memory card, verify that it boots properly, and connect it to the network.

Getting the Root Filesystem Image

1. Check that the file rootfs-f12.tar.bz2 is in your Downloads directory (go to the menu option Places>Downloads). If not, download and save this file: http://australia.senecac.on.ca/fsoss/rootfs-f12.tar.bz2

Copying the rootfs to the microSD Card

1. Remove the microSD card from the GuruPlug.
2. Insert the card into the card reader on your PC. A window should appear; it is OK to leave this window open.
3. Open a terminal window (menu option Applications>System Tools>Terminal).
4. Request administrator/superuser privilege by typing: su
5. Change to the directory containing the microSD card: cd /media/*
6. Erase everything on the card (type this command very carefully!): rm -rf /media/*/*
7. Unpack the rootfs onto the microSD card: tar xvf ~fsoss/Downloads/rootfs-f12.tar.bz2
8. The files have been unpacked into a directory named rootfs-12. Move them out of that directory: mv rootfs-f12/* .

Preparing the rootfs Image: Turning On the Lights

Since the GuruPlug doesn't have a screen, it's hard to know if the system has booted properly. Fortunately, the GuruPlug has LEDs on it, and we can use those LEDs to check that the system is booting properly. The Linux kernel has direct device support for the LEDs, and they can be set to flash at various rates; indicate disk, flash memory, or wireless activity; or show a heartbeat pattern (double flash, indicating that the system is running).

Let's program the red LEDs to show a heartbeat when the system is booted.

1. Change to the directory containing the startup scripts: cd /media/*/etc/rc.d
2. Add code to the rc.local script to flash the lights:

for LAMP in /sys/class/leds/*/trigger
do
        echo heartbeat >$LAMP
done

Try it!

1. Umount the microSD card.
2. Remove the card from your PC.
3. Insert the card into your GuruPlug.
4. Remove the GuruPlug power cable connector.
5. Attach the GuruPlug power prongs.
6. Plug the GuruPlug into a power jack.
7. Give it some time to boot up.
8. If the red LEDs are flashing, success! (If not, find out what's going wrong and fix it).

Plug your Plug into the Network

1. Remove the GuruPlug power prongs.
2. Re-attach the GuruPlug power cable connector.
3. Add your GuruPlug into the network shelves at the front of the room.

Connect to your GuruPlug

To connect to your plug over the network, you'll need to connect to the computer managing the GuruPlug cluster, which is named "HongKong".

1. Connect to HongKong: ssh -p 2222 -XC hongkong (password is "fsoss10")
2. Connect to your plug: ssh nameOfYourPlug