Skip to content
July 31, 2012 / gus3

A Month With Raspbian

Three months on, my Raspberry Pi is still proving a delight. I have settled on the Raspbian distribution as my tinkerer’s habitat, giving me access to the floating-point unit in the glibc libraries (especially libm.so).

However, being mostly uninitiated in Debian administration, I have spent some time learning “the Debian way” of doing things. This article will therefore be a shameless hodge-podge of Raspbian review and Debian ignorance, plus a handy (for me) trick at the end.

Installing Raspbian

Raspbian is a Debian-based distribution, tailored specifically for the Raspberry Pi’s hardware and capabilities. The Raspbian download isn’t actually an installer, but rather an image to copy to a 2G SD card, ready to boot, almost ready to run, and pre-configured for the Raspberry Pi’s on-board hardware. The kernel and X server are configured for maximum peripheral compatibility, so Raspbian should work with most (spec-conformant) USB keyboards, USB pointing devices, and HDMI or SDTV console displays.

 About the Raspberry Pi’s boot process: On power-up, the VideoCore GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the GPU’s PROM requires a DOS-style partition table; a FAT-formatted first partition; and the files “bootcode.bin”, “loader.bin”, and “start.elf” in that partition. (see note 1) The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it. The boot sequence carries out several pre-boot tasks:

  • configures the memory split for the CPU and GPU
  • reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings)
  • loads the “kernel.img” file, again from the same partition
  • activates the CPU to begin executing the loaded kernel image

The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU. The 256M on-board RAM is not expandable.

Until recently, pre-alpha releases of Raspbian came from independent developers. That changed on 2012-July-15, when Raspbian became an officially supported distubition with the Raspberry Pi project. Raspbian underwent much clean-up and stabilization for this change, including the addition of the Squeak and Scratch programming environments.

First boot

One excellent clean-up in Raspbian is running “raspi-config” automatically during the first boot. This tool can perform some useful setup tasks:

  • Expand the root filesystem to fill the SD card
  • Enable/disable HDMI overscan (wider margins)
  • Configure the keyboard layout
  • Set the password for the ‘pi’ user
  • Configure the locale
  • Configure the timezone
  • Change the CPU/GPU memory split
  • Enable/disable SSH on boot
  • Enable/disable GUI login on boot
  • Update the “raspi-config” tool itself

I found every option useful, especially the keyboard layout and locale. Raspbian’s base configuration is for a British environment, which has various critical characters in different places on the console keyboard. I had to switch to a US keyboard layout, so that the double-quotes (“), at-sign (@), and hash mark (#) are where I need them to be. Without that, the attached keyboard would be very difficult for me to use. Enabling overscan is useful for shrinking the image, to compensate for my ancient composite monitor’s weak circuits.

Changing the CPU/GPU memory split is buggy. I can copy the desired *_start.elf file to start.elf manually, then reboot, and the system has no complaint. However, using the “raspi-config” tool to choose the *_start.elf image results in a system that won’t boot. The “OK” LED flashes 6 times, indicating that “start.elf” failed a sanity check before receiving control. The fix is simply to pull the power, pull the SD card, insert the SD card into my desktop system, mount the first partition, and make the copy manually. After unmounting the partition and re-inserting the SD card into the Raspberry Pi, it boots just fine. I am grateful to the Raspberry Pi’s designers, that they decided to boot from the SD card: if the modifiable boot code were embedded in an EEPROM, this bug in “raspi-config” would require an expensive JTAG connection to fix.

How I have it set up

Added packages for this section: ntpdate

On my home network, I use DHCP, NFS, and NTP, so the very first thing I did as root was to add my group and user names with the proper ID (12346). That also gives me SSH access from my desktop, once I removed stale keys from the clients’ ~/.ssh/known_hosts. The DHCP server configuration was left over from previous tinkering; as long as the Ethernet address remains the same, the .18 address will be valid from anywhere on the network.

Since the Raspberry Pi has no on-board clock, the time and date must be set either manually or from an external resource. Raspbian includes the “fake-hwclock” package, to maintain an illusion of a stopped clock during power-down.

If NTP is blocked by a firewall (or a setup like mine), a cheap way to set the clock from a Raspbian root login is:

date -s "`ssh othermachine date`"

Or, from othermachine:

ssh root@raspbian-system date -s \"`date`\" # note backslashes!

This will give at most a few seconds’ difference for password typing.

Using NTP is the best option, if it can be made to work.

GUI adjustments

Added packages for this section: xdm

My console monitor is an old Commodore Amiga composite video monitor, and its focus isn’t as strong as it once was. I do like my GUI environments, but on this monitor it would give me severe eyestrain. That’s OK, I can use SSH from my desktop for single-run programs, or XDMCP for an actual remote GUI login. I won’t be using the Raspberry Pi without a network connection, except perhaps for diagnostic purposes. Making XDM available remotely, but not locally, involved three primary steps:

  1. I put the following into /etc/X11/xorg.conf, to hide the X server from the console:
    Section "Device"
        Identifier  "Dummy Framebuffer"
        Driver      "dummy"
    EndSection
    
  2. I enabled XDMCP by commenting out the last line of /etc/X11/xdm/xdm-config (N.B. comments there use exclamation marks!). Since the Raspberry Pi is always on a trusted network (even in public, where it talks only to my netbook), I made all remote X servers accessible by uncommenting the “any host can get a login window” in /etc/X11/xdm/Xaccess.
  3. I launched XDM with “service xdm start” as root, followed by “netstat -ulnp” to confirm XDM was indeed listening for incoming display management requests. I could test the setup with “X -query zacchaeus” on my desktop; a login screen showed that the request was honored.

Once remote login was proven to work, making XDM start at boot was just a matter of “update-rc.d xdm start 2 3 4 5″ as root.

Network proxy

Affected packages for this section: web browsers, downloaders, and Debian package tools

Most of the network requests from Raspbian are HTTP, including Raspbian package updates. I have my own special setup, which I’ll explain below, but there are two points to bear in mind:

  1. Any proxy can be set for CLI programs using the environment variables “http_proxy” and “https_proxy”, so putting these into a profile script in /etc/profile.d/ will save a lot of time.
  2. Using a profile script to set proxies requires special options to “su” to keep the proxy variables, either “su -” to run profile init scripts, or “su -m” to keep the current environment. A plain “su” will discard most of the environment when switching to the root user, for security reasons.

That last point is easy to forget, until an “apt-get update” suddenly reports “404 No such domain” with a functioning network connection.

The Basic GUI Desktop

The “pi” user has three primary programming environments in stock Raspbian: Scratch, Squeak, and Python. The Python installation includes some games, available through the “Python Games” desktop icon (imagine that!).

Scratch’s GUI uses the X shared memory extension, which works only on local video, but reports X protocol errors when run remotely. Without a USB mouse to run Scratch on the console, it is unavailable for me to explore.

The stock installation of Squeak (a dialect of Smalltalk) includes no runnable images. From the Squeak manual page:

Because of licensing issues, a Squeak image or Squeak sources package is not available in Debian yet. So the user must download a proper image in order to get this script useful.

The Squeak web page includes an All-In-One download link, which supports Intel architectures only. The Debian instructions involve adding two lines to /etc/apt/sources.list; the only other option for running Squeak on ARM seems to be building from source. I consider the lack of documentation in Raspbian for installing a Squeak VM image for Raspbian Squeak to be problematic. If a component has to be omitted from the stock image, the statement indicating this (in this case, the man page) should include the instructions for finding and installing that component.

Using Raspbian

Added packages for this section: vim, nedit, ddd, gkrellm, xxgdb, GCC 4.7 toolset

“Using” in this case might be a misnomer, since I don’t “use” the Raspberry Pi for regular work. The Raspberry Pi is more of a t… well, it isn’t a “toy” either. I suppose the best non-computer comparison is a set of metric wrenches for a car mechanic who has needed only Imperial wrenches so far. They do the same thing, but they’re different enough that the mechanic can now do basic work on European and Japanese cars. Since my purpose for the Raspberry Pi is mostly academic, Raspbian serves well to open up the capabilities of its hardware to my curious eyes.

The configured LXDE environment has 2 virtual desktops. This may seem somewhat sparse, but it’s ready to build on, in keeping with the overall Raspberry Pi and Raspbian philosophies. I added the GKrellM system monitor, with its clock showing hours, minutes, and seconds for quick visual confirmation that the system is still up and operational. If the system’s CPU load is pegged at 100%, and the kernel panics, a plain load monitor shows no difference, but GKrellM shows immediately that the system time (and everything else) is stopped.

I don’t use PCmanFM enough to say much about it, but it’s there for those who want it. I prefer to use the CLI for my file management.

One of my favorite tools for tinkering is the “ht” object file examiner, with its support for ELF, Java classes, and several CPU architectures, as well as bi-directional reference decoding via in-line hyperlinks. However, it wouldn’t build with gcc-4.6, due to an “internal compiler error” emitting x86-looking Lisp code. Per Debian’s standard practice, GCC versions can be installed side-by-side, with symlinks providing the regular names of “gcc”, “g++”, etc. I tested that “ht” would build properly with gcc-4.7:

cd path
CC=/usr/bin/gcc-4.7 CXX=/usr/bin/g++-4.7 ./configure && make

I made the switch to GCC 4.7 permanent, by removing the regular symlinks and creating new ones. This is a manual process, since Debian’s “update-alternatives” system doesn’t manage GCC versions.

Exploring the Raspberry Pi

One of the first things I wanted to examine was the math library in /lib/arm-linux-gnueabihf/libm-2.13.so, to see how software used the floating-point unit in complicated calculations. I was surprised to find out that only the basic operations are available–addition, subtraction, multiplication, division, and square roots. There are no trigonometric or logarithmic instructions, so these are carried out through “manual” calculations instead, which are still faster thanks to the hardware floating-point acceleration.

What would I change?

As I said above, I’m not pleased about being unable to run Scratch or Squeak in my current Raspbian environment.

GCC doesn’t yet support linking Thumb and ARM HF (hardware-float) code. Using “-mthumb” with GCC gives a “sorry, unimplemented: Thumb-1 hard-float VFP ABI” error, so that means no Thumb code testing under a debugger. Generating the Thumb assembly is still an option, though.

I would also like Jazelle support, but that isn’t Raspbian’s fault. ARM isn’t forthcoming with Jazelle documentation for public consumption, possibly due to licensing issues from Sun/Oracle. That makes Jazelle support unavailable for GPL’d code.

I missed seeing “oprofile” and “ht” in the Raspbian repository. I was able to build both from source (“ht” needed the latest GCC), but “oprofile” fails to run properly. Even when I see no errors during setup, report generation fails when it succeeds on my desktop.

None of these is a show-stopper. The ones that make me go “drat!” is the lack of Thumb support in the linker and the unusable Scratch and Squeak environments.

Final score: 3.5 out of 5

Making Raspbian portable

Added packages for this section: xdm

If you ignore the three Android devices I own (don’t ask), the Raspberry Pi is the most portable of my general-purpose computing devices. Packed into its shipping box for protection, it fits into a large pants pocket, along with the network and power supply cables. Even my netbook isn’t that small or light. But that doesn’t mean Raspbian would be usable, without some way to receive input and display output. Carrying a keyboard and CRT would turn the RPi into my least portable device.

Following the Unix philosophy of “simple tools for complex tasks” and “don’t re-invent the wheel,” I kept access to the GUI desktop, while reducing the Raspberry Pi’s connections to the bare minimum of two: the power supply and network. The power supply is a microUSB connector, just like the USB data cable connector on my Samsung Gem Android phone. Running the Gem’s data cable between my netbook’s USB port and the RPi’s power connector takes care of that need.

The Ethernet connection is even simpler. The Raspberry Pi’s Ethernet port auto-senses both 10/100Mbit and normal/crossover, so it basically doesn’t care what’s on the other end of the cable. For my purposes, that will also be the netbook. Here is what the connections look like:

The Raspberry Pi, running with just two cables attached. (Click to enlarge.)

Because the Ethernet is the only channel of communication for the RPi, and the RPi is configured to use DHCP for its network configuration, the netbook needs a DHCP server. My Slackware installation on the netbook also uses DHCP for its own network configuration, whether at home or on a public network, so I have a little extra code snippet in /etc/rc.d/rc.local:

/bin/ping -c 2 -q -w 4 andrew # the home server
if [ $? -ne 0 ] ; then # not at home
        # on public network
        echo "Enabling DHCP for Raspberry Pi access."
        /sbin/ifconfig eth0 down
        /sbin/ifconfig eth0 192.168.123.55 netmask 255.255.255.0
        /usr/sbin/dhcpd eth0
fi

This configures the wired Ethernet with a fixed IP address, and starts the DHCP server, listening only on the wired Ethernet, when I’m not using the netbook at home. The netbook has this DHCP server configuration, specifically for the Raspberry Pi:

option domain-name "home";
ddns-update-style none;
default-lease-time 14400;
max-lease-time 28800;
 subnet 192.168.123.0 netmask 255.255.255.0 { }
host zacchaeus { hardware ethernet b8:27:eb:46:65:66;
             fixed-address zacchaeus.home; }

Once the DHCP server is running on the netbook, all I need to do is connect the Ethernet ports, and then connect the netbook’s USB port to the RPi’s power connector. About 30 seconds later, the RPi will be ready for an XDM login.

With a text-mode login (no X) on the netbook, I can login, then type “X -query zacchaeus”. The X server starts, then asks the login manager on the RPi if it would like to use the netbook as an X display. When XDM on the RPi connects to the X server on the netbook, this is the result:

A completely self-contained setup, with no power-cord leash. (Click to enlarge.)

The Raspberry Pi and the netbook thus becomes peripherals for each other. The netbook is a console for the RPi, and the RPi is a peripheral with its only connections to the netbook. I now have a setup that can give me a Raspbian login anywhere I go.

Notes

 Note 1: The “bootcode.bin”, “loader.bin”, and “start.elf” files do not have source available, but their distribution is unrestricted by Broadcom. ^

About these ads

6 Comments

Leave a Comment
  1. horray / Aug 28 2012 10:07 pm

    Have you tried the Xbian fork?

    • gus3 / Aug 29 2012 5:32 pm

      http://xbian.org/

      Hmmm, that does look interesting. One problem afflicting all the Raspbian distros is the reliance on the 3.1.9 kernel, which as the Xbian devs point out, is no longer supported. They now have the 3.2.27 kernel working on the RPi, so hopefully the other RPi distros can take up the example and get support from the Linux dev team.

  2. Reblogged this on Blogaki.

Trackbacks

  1. A Month With Raspbian « I Am, Therefore I Think | Connor Jackson
  2. A Month With Raspbian – Connor Jackson
  3. Connor Jackson

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: