Uwe Hermann | A slightly paranoid Debian developer

When trying to port coreboot (previously LinuxBIOS) to a new mainboard you're often confronted with a big problem: the BIOS/ROM chip on the respective motherboard is soldered onto the board (i.e., not in a socket).

This means that you cannot easily (hot-)swap the chip during development or for recovery purposes. So you basically have exactly one try to flash the ROM chip with a fully working/booting coreboot image. If that goes wrong your board is bricked.

This makes it pretty much impossible to develop a coreboot port for such boards (and soldered-on ROM chips are becoming more and more common, unfortunately).

However, I've recently tried to replace the soldered-on (PLCC) ROM chip on one of my boards with a socket. What sounds pretty scary at first, especially given that I have almost non-existant soldering skills, turned out to be really not that hard. Also, it can be done with relatively cheap and readily available equipment.

I have written a short HOWTO for desoldering chips and soldering on sockets in the coreboot wiki, and also finished a video showing most of the process, which I hope will be helpful for others:

• archive.org: Ogg Theora, small (32 MB), Ogg Theora, big (154 MB)
• Youtube (FLV, small, 13 MB). Direct download:
  

    $ youtube-dl -t 'http://www.youtube.com/watch?v=30x4oxyczH4'
  

• blip.tv: FLV, small (20 MB)

The video is CC-BY-SA 3.0, music is taken from ccmixter.org and is CC-NC 3.0 licensed. Video editing was done using Kino (which uses ffmpeg2theora for Ogg Theora export).

I also tried to upload the video to Vimeo, but first they told me to install the Flash 10 abomination (and there's no way I will do that). After browsing the help/forum pages a bit I found a traditional, non-flash upload form, but that then tells me that I cannot upload Ogg Theora videos. WTF?

The Ogg Theora video support feature request has been open for more that a year. Until that issue is fixed I'll just use other video services, thanks...

Note to self: If you do suspend-to-disk with 2.6.24, do not try to resume with 2.6.28 or any other version of the kernel, it won't work.

When asked whether you want to continue, say "no" and reboot with the correct kernel, in order to not lose your suspended data...

I recently got my hands on a Lenovo IdeaPad S9e netbook for a short amount of time (I don't own it), so I did a few tests with Debian unstable (more or less Lenny right now) and a Linux 2.6.28 kernel on it, see results below.

The machine type is 4187-42G, and it features an Intel Atom N270 CPU (with HyperThreading) at 1.6 GHz, 1 GB of DDR2 RAM, an 80 GB SATA drive, an 8.9" WSVGA 1024x600 (glossy) screen, VGA port, LAN, wifi, bluetooth, 2xUSB, SD card slot, PCI ExpressCard slot, built-in microphone, and a webcam.

BIOS

You can enter the BIOS by pressing F2, the boot menu by pressing F12 during boot. Booting from USB works fine on this netbook. There's a Splashtop installation on the netbook (called "Lenovo Quickstart" here) which you can disable in the BIOS.

Installation

There's no CD-ROM drive, so the simplest way is to use a USB thumb drive for installation. Here's how you can prepare one containing a Lenny installer (assuming your USB thumb drive is /dev/sda):

  $ wget http://cdimage.debian.org/debian-cd/5.0.1/i386/iso-cd/debian-501-i386-netinst.iso
  $ wget http://ftp.nl.debian.org/debian/dists/lenny/main/installer-i386/current/images/hd-media/boot.img.gz
  $ gunzip boot.img.gz
  $ dd if=boot.img of=/dev/sda1
  $ mount -t vfat /dev/sda1 /mnt
  $ cp debian-500-i386-netinst.iso /mnt
  $ umount /mnt

If the above USB thumb drive doesn't boot correctly (which it did not in my case: GRUB error 17) it's probably because of a messed-up MBR. This is how you can fix it:

  $ apt-get install mbr
  $ install-mbr /dev/sda

Then insert the USB thumb drive in the Lenovo IdeaPad S9e, choose USB boot in the BIOS, and start the installer. Most of the process works as usual, the only small difference is that you might want to load the "parted" installer module in order to resize the Windows-partition on the disk (if you want to keep it) to make space for Linux. The second (fat32) partition seems to keep a restore image and/or the Splashtop stuff, not sure.

Audio

Works out of the box using the snd_hda_intel driver. The hardware is onboard audio in the southbridge (82801G / ICH7) and uses the Realtek ALC269 codec. If some programs don't have working audio, try modprobe snd-pcm-oss.

Built-in microphone

Untested so far.

Bluetooth

Works out of the box using the bluetooth and btusb driver. The laptop's Bluetooth device is USB-attached internally and shows up in lsusb as:

  $ lsusb
  Bus 003 Device 002: ID 0a5c:2150 Broadcom Corp.
  $ dmesg
  usb 3-2: Product: BCM2046 Bluetooth Device

After modprobe btusb you can use hcitool / hciconfig etc. as usual, and/or enable more related stuff with /etc/init.d/bluetooth start.

Sensors

The lm-sensors script detects the lm75, eeprom, i2c-dev, and i2c_i801 modules. The following is the 'sensors' output:

  $ sensors
  acpitz-virtual-0
  Adapter: Virtual device
  temp1:       +36.0 °C  (crit = +95.0 °C)    

The hard drive temperature can be viewed with:

  $ hddtemp /dev/sda
  /dev/sda: FUJITSU MHZ2080BH G1: 44 °C

HPET

The Intel ICH7 southbridge in this laptop supports High Performance Event Timers (HPET) which allows for more power savings and thus improved battery life.

  $ dmesg | grep -i hpet
  ACPI: HPET 3F6E1E41, 0038 (r1 INTEL  CALISTGA  6040000 LOHR       5A)
  ACPI: HPET id: 0x8086a201 base: 0xfed00000
  hpet clockevent registered
  HPET: 3 timers in total, 0 timers will be used for per-cpu timer
  hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
  hpet0: 3 comparators, 64-bit 14.318180 MHz counter

You can check the wakeups-per-second with powertop.

SD card slot

Works out of the box. It seems to be attached via USB internally (usb-storage driver).

  $ lsusb
  Bus 001 Device 004: ID 0bda:0158 Realtek Semiconductor Corp. Mass Stroage Device

PCI ExpressCard slot

Untested so far.

ACPI

Works fine, see comments for "acpitool" output.

Network card

Works out of the box using the tg3 driver.

  $ modprobe tg3
  tg3.c:v3.94 (August 14, 2008)
  tg3 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
  tg3 0000:02:00.0: setting latency timer to 64
  eth0: Tigon3 [partno(BCM95906) rev c002 PHY(5906)] (PCI Express) 10/100Base-TX Ethernet 00:11:22:33:44:55
  eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[0]
  eth0: dma_rwctrl[76180000] dma_mask[64-bit]

Touchpad

Works out of the box, both in X as well as in the console using gpm.

  $ dmesg
  Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04731/0xa40000

Suspend-to-disk and suspend-to-RAM

I'm using the hibernate Debian package. You can explicitly force the usage of either method in /etc/hibernate/hibernate.conf by uncommenting the respective lines.

  TryMethod disk.conf
  # TryMethod ram.conf

Suspend does not yet work out of the box, however, as the machine is unknown:

  $ s2ram -n
  Machine unknown
  This machine can be identified by:
      sys_vendor   = "LENOVO                          "
      sys_product  = "418742G         "
      sys_version  = "Lenovo                  "
      bios_version = "14CN51WW  "
  See http://suspend.sf.net/s2ram-support.html for details.

After a few test I found that s2ram -f -a 3 works fine (tested from console only so far). Now this needs to be integrated upstream and in the Debian package (I'll file a bug report). Update: Submitted bug #520848, and an email to the upstream mailing list.

Wireless

There doesn't seem to be a mainline driver for the Broadcom BCM4312 wifi card in the laptop, yet:

  $ lspci -nn
  05:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)

Neither the b43 nor the b43legacy drivers work as of 2.6.28. For now, one of two possible options is to build a (partly non-free) driver provided by Broadcom from source (option 2 would be to use ndiswrapper, I guess, but that's untested):

  $ wget http://people.debian.org/~adamm/kernel/linux-kbuild-2.6.28_2.6.28-0.1_i386.deb
  $ dpkg -i linux-kbuild-2.6.28_2.6.28-0.1_i386.deb (currently needed in unstable due to bug #518115)
  $ apt-get install build-essential linux-headers-2.6.28-1-686
  $ mkdir temp; cd temp
  $ wget http://www.broadcom.com/docs/linux_sta/hybrid-portsrc-x86_32-v5_10_79_10.tar.gz
  $ tar xfvz hybrid-portsrc-x86_32-v5_10_79_10.tar.gz
  $ make -C /lib/modules/`uname -r`/build M=`pwd` clean
  $ make -C /lib/modules/`uname -r`/build M=`pwd` modules

If that worked, you can load the driver via:

  $ rmmod bcm43xx; rmmod b43; rmmod b43legacy (you could also permanently blacklist these modules)
  $ modprobe ieee80211_crypt_tkip
  $ insmod ./wl.ko
  $ dmesg
  wl: module license '' taints kernel.
  wl 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
  wl 0000:05:00.0: setting latency timer to 64
  eth1: Broadcom BCM4315 802.11 Wireless Controller 5.10.79.10

You can now run iwconfig, iwlist, etc. from the command line, or use some GUIs such as kwifimanager.

In order to disable wireless, run:

  $ rmmod wl

So far, I only tested WEP (but not WPA).

CPU frequency scaling

Works out of the box using the acpi_cpufreq driver. Use cpufreq-set -c 0 -g performance if you need full CPU power, cpufreq-set -c 0 -g powersave otherwise. Use -c 1 to do the same with the other CPU/core.

PC speaker

Works fine out of the box using the pcspkr module, tested with beep.

Graphics card

Works out of the box using the intel X.org driver.

  $ xrandr
  Screen 0: minimum 320 x 200, current 1024 x 600, maximum 1024 x 1024
  VGA disconnected (normal left inverted right x axis y axis)
  LVDS connected 1024x600+0+0 (normal left inverted right x axis y axis) 195mm x 113mm
     1024x600      60.0*+
     800x600        60.3  
     640x480        59.9  
  TV disconnected (normal left inverted right x axis y axis)

DRI works out of the box with the (mainline, open-source) driver:

  $ glxinfo | grep direct
  direct rendering: Yes

If you attach an external monitor or projector, you can enable it using xrandr as usual:

  $ xrandr --output VGA --auto

You can also use a dual-head setup by adding this to your "Screen" section in /etc/X11/xorg.conf:

  SubSection "Display"
    Virtual 2048 2048
  EndSubSection

After restarting the X server, you can play with xrandr and move the external screen (VGA) "below" the laptop's LCD screen (LVDS) for a simple dual-head setup. The GUI tools arandr or grandr are probably a bit simpler to use than plain command line xrandr.

USB

Works fine, of course. The only small problem is that there are only two USB ports, more would have been better.

Disk drive

Works fine, it's an 80 GB SATA drive.

Webcam

Works out of the box using the uvcvideo driver.

  $ lsusb
  Bus 001 Device 005: ID 5986:0141 Acer, Inc
  $ modprobe uvcvideo
  uvcvideo: Found UVC 1.00 device Lenovo EasyCamera (5986:0141)
  input: Lenovo EasyCamera as /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0/input/input9
  usb 1-3: New USB device found, idVendor=5986, idProduct=0141
  usb 1-3: New USB device strings: Mfr=3, Product=1, SerialNumber=0
  usb 1-3: Product: Lenovo EasyCamera
  usb 1-3: Manufacturer: BISON Corporation

You can use luvcvideo for webcam viewing.

Battery

Lasts for ca. 3.5 hours, probably less if the system is under high load.

Special keys

Fn+CursorUp / Fn+CursorDown (brightness), Fn+ESC (enable/disable webcam), Fn+F1 (sleep mode), Fn+F2 (enable/disable TFT backlight), Fn+F6 (enable/disable thouchpad), Fn+F7 (Num lock), Fn+F8 (scroll lock), and Fn+F11 (F12 key) all work fine.

Fn+F3, Fn+F5, Fn+F9, Fn+F10, and all other special keys are untested.

LEDs

The power, disk activity, CAPS lock, Num lock, and battery charging LEDs all work fine out of the box.

lspci -tvnn

  -[0000:00]-+-00.0  Intel Corporation Mobile 945GME Express Memory Controller Hub [8086:27ac]
           +-02.0  Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae]
           +-02.1  Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6]
           +-1b.0  Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8]
           +-1c.0-[0000:02]----00.0  Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express [14e4:1713]
           +-1c.1-[0000:03-04]--
           +-1c.2-[0000:05]----00.0  Broadcom Corporation BCM4312 802.11b/g [14e4:4315]
           +-1d.0  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8]
           +-1d.1  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9]
           +-1d.2  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca]
           +-1d.3  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb]
           +-1d.7  Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc]
           +-1e.0-[0000:06]--
           +-1f.0  Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9]
           +-1f.1  Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df]
           +-1f.2  Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4]
           \-1f.3  Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da]

cat /proc/cpuinfo

See comments.

Resources

• Lenovo/IBM announcement (German), specs (German), S9e/S10e overview
• Wikipedia: IdeaPad
• s10lenovo.com wiki
• Thinkwiki entry

All in all it's a really nice hardware, and it works (more or less) flawlessly without much hassle with recent distros/kernels.

Update 2009-03-22: Updated various sections, added more info. Added resources section.

Back in 2008 I wrote a small article about resizing LVM physical volumes. I had to do something similar, but slighly more complicated, recently. My /usr logical volume (LV) was getting full on my laptop disk, thus I wanted to shrink another LV and move some of that space to /usr. Here's one way you can do that.

Requirements: a Live CD containing all required utilities (cryptsetup, LVM tools, resize2fs), I used grml.

Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned!

First, shutdown the laptop and boot using the Live CD. Then, open the dm-crypt device (/dev/hda3 in my case) by entering your passphrase:

  $ cryptsetup luksOpen /dev/hda3 foo

Activate all (newly available) LVM volume groups in that encrypted device:

  $ vgchange -a y

(maybe you also need a vgscan and/or lvscan, not sure)

Check how much free space we have for putting into our /usr LV:

  $ vgdisplay | grep Free
  Free  PE / Size       0 / 0   

OK, so we have none. Thus, we need to shrink another LV (/home, in my case) and put that newly freed space into the /usr LV. In order to do that, we have to check the current size of the /home LV:

  $ mount -t ext3 /dev/vg-whole/lv-home /mnt
  $ df --block-size=1M | grep -C 1 /mnt
  $ umount /mnt

(if you know how to find out the size of an ext3 file system without mounting it, please let me know) Update: See comments for suggestions.

Write down the total amount of 1M chunks of space on the file system (116857 in my case), we'll need that later. Now run 'fsck' on the /home LVM logical volume, which is needed for the 'resize2fs' step afterwards. This will take quite a while.

  $ fsck -f /dev/vg-whole/lv-home

Next step is resizing the ext3 file system in the /home LVM logical volume, making it 1GB smaller than before (of course you must have >= 1 GB of free space on /home for that to work). We use fancy bash calculations to do the math.

Note: I'm not so sure about the sizes here, in my first attempt something went wrong and resize2fs said "filesystem too small" or the like. Maybe I'm confusing the size units from 'df' and 'resize2fs', or the bash calculation goes wrong? Please leave a comment if you know more!

  $ resize2fs /dev/vg-whole/lv-home $((116857-1024))M

Then, we can safely reduce the LV itself. Note: order is very important here, you must shrink the ext3 filesystem first, and then shrink the LV! Doing it the other way around will destroy your filesystem!

  $ lvreduce -L -1G /dev/vg-whole/lv-home

Now that we have 1 GB of free space to spend on LVs, we assign that space to the /usr LVM logical volume like this:

  $ lvextend -L +1G /dev/vg-whole/lv-usr

As usual, we then run 'fsck' on the filesystem in order to be able to use 'resize2fs' to resize it to the biggest possible size (that's the default if resize2fs gets no parameters):

  $ fsck -f /dev/vg-whole/lv-usr
  $ resize2fs /dev/vg-whole/lv-usr

That's it. You can now shutdown the Live CD system and boot into the normal OS with the new space allocations:

  $ vgchange -a n
  $ cryptsetup luksClose foo
  $ halt

I've been planning to write about building custom ARM toolchains for a while (I used stuff from gnuarm.com in the past, but I switched to the lastest and greatest upstream versions at some point). Among other things, recent upstream versions now have ARM Cortex support.

First you will need a few base utilities and libs (this list may not be complete):

  $ apt-get install flex bison libgmp3-dev libmpfr-dev libncurses5-dev libmpc-dev autoconf texinfo build-essential

Then you can use my tiny build-arm-toolchain script, which will download, build, and install the whole toolchain:

  $ cat build-arm-toolchain
  #!/bin/sh
  # Written by Uwe Hermann <uwe@hermann-uwe.de>, released as public domain.
  [...]

The final toolchain is located in /tmp/arm-cortex-toolchain per default, and is ca. 170 MB in size. I explicitly created the build script in such a way that it minimizes the amount of disk space used during the build (ca. 1.2 GB or so, compared to more than 3 GB in the "naive" approach).

Using the "-j 2" option for make (see script) you can speed up the build quite a bit on multi-core machines (ca. 30 minutes vs. 60 minutes on an AMD X2 dual-core box). Also, you can change the script to build for other target variants if you want to (arm-elf or arm-none-eabi, for example).

Checkout the blog entry How to build arm gnu gcc toolchain for Mac OS X by Piotr Esden-Tempski for similar instructions for Mac OS X users.

Oh, and while I'm at it — does anybody have any idea why there are no pre-built toolchains for embedded (microcontroller) ARM targets in Debian? There are some toolchains for other microcontroller architectures (avr, m68hc1x, h8300, z80) but not too much other stuff. Is there some specific reason for the missing ARM toolchains (other than "nobody cared enough yet")?

I have heard about Emdebian, but from a quick look that seems to be more intended for toolchains with Linux/libc, not for microcontroller firmware (i.e. no MMU, no Linux, no libc etc.), but maybe I'm wrong?