FSOSS 2010 Plug Computing Workshop

From CDOT Wiki
Jump to: navigation, search

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
  • u-SNAP connector for home power automation (smart electric meter access)

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


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.


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.


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/SDHC or microSD/microSDHC 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 JFSF (Journalled Flash File System 2) subsystems.


Most ARM operating systems (typically Linux distributions) are not shipped with an installer program; instead, a pre-built root filesystem (rootfs) and a kernal are loaded on an SD card or programmed into flash memory (an initial ram disk -- initrd -- may also be supplied).

The installed system can then be further adapted using the distribution's package management tools, such as apt (Debian) or yum (Fedora).

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. Download and save this file: http://australia.proximity.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 (password is "fsoss10")
  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 this code to the rc.local script to flash the lights:
for LAMP in /sys/class/leds/*/trigger
        echo heartbeat >$LAMP

Preparing the rootfs Image: Setting a Message of the Day

Edit the Message of the Day file so that you can be sure that you've connected to the right plug later in this workshop.

  1. Edit the file /media/*/etc/motd
  2. Add a greeting of your own choice. For example: Welcome to Chris & Diane's GuruPlug!
  3. Save the file.

Try it!

  1. Unmount the microSD card. Find the icon for the card on the desktop, and right-click to select "Unmount"; or enter the command: umount /media/*
  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 -XC nameOfYourPlug@hongkong.proximity.on.ca -- for example, if your GuruPlug is cdot-guru-2-3, then connect with ssh -XC cdot-guru-2-3@hongkong (password is "fsoss10")
  2. Connect to your plug fron HongKong: ssh root@nameOfYourPlug (password is "fedoraarm")
  3. Check the message of the day (printed after you log in) to be sure you have connected to the right GuruPlug.

Making Your Plug Useful

Now it's time to use your plug to do something useful.

Using yum to Add Packages

Fedora uses a package manager named yum. This tool can find, add, remove, and update software packages, automatically downloading them and resolving dependencies as required.

Basic yum commands:

Operation Command Example Notes
List packages yum list yum list "*wiki*" Lists according to package name only.
Search for packages yum search yum search "calendar" Searches package name, summary, and detailed description.
Get information about packages yum info yum info "httpd" Gives detailed information about a package, including license, package size, summary, and description.
Install a package yum install yum install gallery2 Determines the package dependencies, displays package and dependency list and asks for confirmation (unless -y argument given), downloads packages, and installs them.
Updates a package (or updates all packages) yum update yum update bash Determines the availability of updates based on package name, version, and release numbers; handles new dependencies as required. Like yum install, the user is shown the list of packages to be installed and is asked for confirmation (unless -y argument is given).
Removes a package yum remove yum remove httpd Also removes any package which depends on the packages being removed. Prompts for confirmation by default.
Cleans up cached packages and metadata yum clean yum clean all Options include: all, packages, metadata

Accessing Your GuruPlug

Due to the network configuration used in this lab, the GuruPlugs are not directly reachable. However, you can access them from the system HongKong. In particular, you can use remote display capability to run a Firefox web browser on HongKong and display the output on your local computer:

ssh -XC nameOfYourPlug@hongkong.proximity.on.ca
firefox http://nameOfYourPlug/

Put Your Plug to Work

Use your plug to ake a web photo gallery.

Other Uses for a Plug Computer

Here are some other PlugComputer application ideas (which are less suited for demonstration in this workshop):

  • wiki host
  • print server
  • scan server
  • network-attached-storage (NAS) device - attach a large disk and make your files accessible over wired or wireless LAN, or through the Internet
  • automatic weather station - attach USB sensors and create a web-based weather tool
  • streaming media server
  • webcam server
  • home security system
  • backup system in an outbuilding - add a disk and put this in your detached garage, programmed to back up your main household computers at regular intervals via wireless networking and strong encryption
  • small business VOIP phone system - using Asterisk PBX software
  • Internet radio station
  • router, firewall, or intrusion detection system
  • VPN connector
  • mail server with spam filtering
  • e-mail autoresponder or mailing list server
  • rsyslog or syslog-ng server - collecting activity and event logs from a network of systems
  • RSS aggregator
  • IRC bot
  • home automation controller
  • game server for LAN parties
  • small e-commerce system
  • order server for a restaurant - communicating with handheld tablets used by servers
  • moodle server for a school
  • GIT or other version control server
  • automatic wireless backup system for smartphones
  • collaborative editing server using Obby

... the applications go on and on.