>NIL:'s Techno Feats: Sheevaplug

Showing posts with label Sheevaplug. Show all posts

2009-10-09

Installing Slackware on the SheevaPlug

And so, finally, we come to the final part of our series regarding the setting up of our SheevaPlug with Linux. Thanks to the good guys at armedslack, we will have the best Linux distro ever, running on one of the coolest little devices around.

For this setup, we will install Slackware on an 8 GB High speed SDIO MMC card, and leave the NAND flash untouched with its updated Ubuntu version. This will also suppose that you have a working kernel that supports ext4 and all the features you want already installed on the flash (if not, refer to this post to to set it up). Now, we are going to deviate a little bit from the "official" armedslack intallation guide for the SheevaPlug, as we are not going to use TFTP for our packages but instead read them directly from an USB device.

And so, without further ado:

Download the packages from armedslack.org. The only directories you really need are the "slackware", "isolinux" and "kernels" directory from ftp://ftp.armedslack.org/armedslack/armedslack-current/. If you're downloading from a Linux system, one way to do it, as advertised in the armedslack installation readme is:
```
rsync --exclude '*/source/*' --delete -Pavv ftp.armedslack.org::armedslack/armedslack-current .
```
(NB: If you use Filezilla to download from FTP, please note that it seems to default to ASCII mode instead of binary, so don't be surprised if your files are corrupted!)
This amounts to about 2 GB of files, so it will take a while, but the filesystem used for the target shouldn't matter much, as long as it is accessible from the default armedslack kernel. So if you have a FAT formatted USB stick lying around, with more than 3 GB space available, you should probably use that.
I also have to point out that we are downloading slackware-current, which contains an up-to-date version of the packages, but is different from a dot release, so you might see some versioning differences between current and what you get on the official x86 dot releases.
For the remainder of this guide, I will assume that you have the directories (slackware/, isolinux/ and kernels/) in an "armedslack/" directory at the root of a FAT formatted USB device. Note that if you're not using a FAT formatted device, you will need to copy the kernel and initrd image on a separate device that can be read from U-boot

Alright, time to reboot the system, with your USB and MMC card plugged in and enter the Marvell>> U-boot prompt through the serial console. There, you need to issue the following:

Marvell>> usb start

(Re)start USB...

USB:   scanning bus for devices... 2 USB Device(s) found

scanning bus for storage devices... 1 Storage Device(s) found

Marvell>> fatload usb 0 0x00800000 armedslack/kernels/kirkwood/uImage-kirkwood

reading armedslack/kernels/kirkwood/uImage-kirkwood

...

................................................................................



1887248 bytes read

Marvell>> fatload usb 0 0x01100000 armedslack/isolinux/uinitrd-kirkwood.img

reading armedslack/isolinux/uinitrd-kirkwood.img

...

................................................................................



10985095 bytes read

Marvell>> setenv bootargs console=ttyS0,115200 nodhcp kbd=uk root=/dev/ram rw;bootm 0x00800000 0x01100000

If all is well, you should be seeing your usual Slackware installation screen.
Please note that because of the "kbd=uk" line above, your keyboard will be automatically set to uk, so change it accordingly.
Also, if you want to use a network session rather than the serial console, you should issue:

dhcpcd eth0

/etc/rc.d/rc.dropbear start

Then you can find your IP address through ifconfig and ssh to it.

If needed, you should use fdisk to partition your MMC device:
```
fdisk /dev/mmcblk0
```
On my system, I created a 512MB /dev/mmcblk0p1 partition for Swap (type 0x82) and left the rest as /dev/mmcblk0p2 for Linux (type 0x83)
If you had a look at dmesg, you should see that your USB device has been detected by the kernel (normally as /dev/sda). Since we have our Slackware package on that device, this is what we are going to use for the source. I have found out however that:
- If you attempt to mount the directory manually and chose the Install from a pre-mounted directory option in SOURCE MEDIA SELECTION, MAKE SURE that your path ends with the slackware/ directory where the a/, ap/, d/... packages reside and NOT the one where extra/, isolinux/, kernels/... reside. If you don't, setup will happily list the packages but fail to install them and produce a completely irrelevant error!
- If you select "Install from a hard drive partition" but haven't previously mounted the partition, it will fail to mount the directory properly.
For now, we will use the "Install from a hard drive partition" option, but we first need to mount that partition manually.
And remember that the Slackware setup process uses /mnt for its own purpose, so you should not use that location as a mountpoint. So:
```
mkdir /usb

mount /dev/sda1 /usb

echo "mmc0" > /sys/class/leds/plug\:green\:health/trigger

setup
```
The "echo mmc0" line in there is a trick to get the blue LED act as an MMC card access indicator, as, if you're like me, you want to see some indication of r/w access to your root device.
Setup should be smart enough to detect your Swap & Linux mmc partitions, and format them (the default ext4 is a good choice for a filesystem). With regards to the SOURCE MEDIA SELECTION screen, you should now select "2 Install from a hard drive partition" then enter "/dev/sda1" as the device and "/armedslack" as the path (or whatever you called your directory on the USB). If you did mount your partition beforehand, this will work and you will then be able to select the packages straight off the USB.
From there, it's your run-of-the-mill package selection and installation. On my 8 GB SD Card, I found that selecting everything but GNU Emacs, TeX, KDEI and the Kernel sources resulted in a 3.7 GB installation, thus leaving about 2.9 GB free space, which is fine. Of course, if you want more space, you can fine tune your package selection or use a bigger SD card.

After you've gone through the rest of the configuration (network, etc) you can reboot the system and get back to the Marvell>> U-Boot prompt. There we will want to test that the custom kernel we've been using to boot Ubuntu can also boot our Slackware installation. Again, this supposes that you followed the steps from my earlier post regarding custom kernel installation and flashing. If not, now is probably a good time to follow this post to to flash the uImage-kirkwood kernel that you used for setup.

To test that your current NAND kernel can boot Slackware:

# Preliminary check to see if your bootargs_console variable is

# properly defined. if not, make sure you set it up

Marvell>> printenv bootargs_console

bootargs_console=console=ttyS0,115200

# This defines our root device. Make sure that use the right device, and that you mount it "ro"

Marvell>> setenv bootargs_root root=/dev/mmcblk0p2 rootfs=ext4 ro

Marvell>> setenv bootargs $(bootargs_console) $(bootargs_root)

Marvell>> printenv bootcmd

bootcmd=nand read.e 0x800000 0x100000 0x400000; bootm 0x800000

# Your bootcmd should only read the kernel and boot from it.

# If not, just issue the 2 commands above instead of what follows

Marvell>> run bootcmd

You should then be able to boot into your newly installed Slackware Linux. If not, you might want to check your parameters and install & flash a kernel that works.
Now, while we have confirmed that your system can indeed boot, we haven't yet saved anything on the flash to make it the default, so you need to reboot into the Marvell prompt once more, and this time:

# First, we start by saving the current working bootargs so that if you ever want

# to get back to Ubuntu, you can issue a "setenv bootargs $(bootargs_rescue)"

Marvell>> setenv bootargs_rescue $(bootargs)

Marvell>> setenv bootargs_root root=/dev/mmcblk0p2 rootfs=ext4 rootwait ro

Marvell>> setenv bootargs $(bootargs_console) $(bootargs_root)

Marvell>> saveenv

Saving Environment to NAND...

Erasing Nand...Writing to Nand... done

Marvell>> reset

After this last command, the plug should automatically boot into Slackware and you can finalize your installation.

IMPORTANT: You VERY MUCH want to add a rootwait parameter to your bootargs, which ensures that the SD is ready before the kernel attempts to mount it as rootfs. Otherwise, you may end up with maddening kernel panics when mounting rootfs, especially after a power failure, that are really due to the SD card not being ready yet.
Another alternative would be to add rootdelay=## but if you read here, you'll see that rootwait is the smarter option.

One thing you might want to do, as we did during the install, is set the blue LED as an MMC access indicator.
On my system, I did that by editing /etc/rc.d/rc.S and adding the line:
```
# Set the blue LED as SD access indicator

echo "mmc0" > /sys/class/leds/plug\:green\:health/trigger
```
just before the section
```
# Enable swapping:

/sbin/swapon -a
```

2009-10-06

Using the blue LED on the SheevaPlug

As mentioned here, it is possible to control the blue LED on the Plug and use it for notification.
The LED itself is accessible as /sys/class/leds/plug\:green\:health, and as mentioned in the Linux LED Documentation, it is possible to find out the available LED functions (triggers) through:

~# cat /sys/class/leds/plug\:green\:health/trigger
none nand-disk mmc0 timer heartbeat [default-on]

Thus, if you want a heartbeat effect, you would issue the command:

echo "heartbeat" > /sys/class/leds/plug\:green\:health/trigger

Now, on the more useful side, with a default Linux image running on the NAND flash, you might want to enable "nand-disk" to monitor said flash activity. Please be aware however that the LED behaviour in this case is quite different from your run-of-the-mill HDD access activity (which is a good thing - the less actual access to the NAND, the less wear and tear). In short, UBIFS does its job and reduces NAND accesses to the bare minimum, which in turn results in little NAND activity actually going on. A couple of well placed "sync" should suffice to convince you that "nand-disk" works as expected though.

If you're using the default Ubuntu running on the NAND Flash, you probably want to add the following to your /etc/rc.local then:

echo "nand-disk" > /sys/class/leds/plug\:green\:health/trigger

Recompiling a new kernel for the SheevaPlug

There are many reasons why you would want to use a custom kernel on the plug. As far as I am concerned, the lack of ext4 and ntfs support in the kernel provided with the otherwise excellent SheevaPlug installer 1.0 system make a clear case for a custom kernel. After all, you might wanna mount external HDDs that are NTFS formatted, or, more important, you might want to install/access a Linux system running with ext4 (which I hear is nicer on flash based media devices than ext3), as we will do when we install armedslack on an SDIO card.

Setting up a cross-compiler for the SheevaPlug on Linux x86_64

While it is definitely possible to recompile a kernel on the SheevaPlug itself, let us just consider the raw compilation times observed when compiling a 2.6.31.2 kernel (exact same .config) on the Sheeva and on a more up to date PC:
- Quad Core PC (Slackware 13.0 x86_64 w/ ext4 fs on a RAID5 array) - 3:03 mins (183 secs)
- SheevaPlug (Ubuntu 9.04 w/ ext4 fs on a high speed SDIO card) - 57:42 mins (3462 secs)

That's one full order of magnitude right there (or about 20x slower)! And if you need a further case for cross-compilation, remember that extracting the kernel source takes ALOT of space. You will run out of space if you try to extract it on the internal flash NAND - it's just too big for what's left of the 512 MB space, and even on external media, you might want to think twice about using the limited space you have there.

If you're familiar with this blog, you know that there's no way we'll want to use any of the old, likely outdated, tools that came with the SheevaPlug SDK CD or internet binaries got compiled by people we don't know (and therefore don't trust!). Besides, the Cross compiler tgz I got on the CD has a big fat CRC error to start with, and it's 32 bit while our cross compiling rig is running Linux x86_64. If what we've seen with the 32 bit openocd binaries is any indication of what's in store for 64 bit users, we might as well cut to the chase and ignore anything that's not 64 bit.
What we do want, and always will want, is the most cutting edge and up to date technology we can lay our hands on. Therefore, we will of course recompile our own cross compiler for the SheevaPlug using the latest gcc, glibc and binutils.

Now, we could of course dive in straight ahead, and recompile, by hand, the whole cross-compiling shebang, but let's face it: your time is precious, so is mine, and if you just dive in head first in trying to produce a cross compiler from the GNU vanilla tarballs, whilst having no previous experience in the matter, you'll find soon enough that:

Compiling a cross compiler manually is absolute hell!
glibc and gcc have to be the worst offenders for breaking things that worked perfectly fine before with newer versions. All those rumours you've heard about needing to apply a massive amount of patches to gcc and gblic before you can compile them as cross-compilers? They're true!

Fact of the matter is I wasted more than one afternoon yesterday on the "Heck, I'm smarter than that - I'll go manual!" approach, and, while I now have a clearer idea of how one might get a cross-compiler actually compiled from scratch, I'll just say this: Do yourself a favour - if you value your time, don't waste it in trying to create a cross-compiling toolchain by hand.
Now, if you really, really, insist on compiling a whole toolchain manually, then my advice is to try to stick as close as possible to this guide (trust me!), but don't come whining that I didn't warn you you were about to step through the gates of hell beforehand...

Using CrossTool-NG

The MUCH better approach, to automate the cross compilation setup process is to use Yann E. Morin's most excellent Crosstool-NG. And, yes, despite being an automated tool, it will not compromise on our using the latest versions of gcc, glibc, binutils, etc.

So off we go:

cd /usr/src
mkdir sheeva
cd sheeva
wget http://ymorin.is-a-geek.org/download/crosstool-ng/crosstool-ng-1.4.2.tar.bz2
tar -xjvf crosstool-ng-1.4.2.tar.bz2
cd crosstool-ng-1.4.2
./configure
make
make install
cd ..
ct-ng menuconfig

Well, isn't that nice - a kernel like configuration menu. Alrighty then, here are the options you want to change for the SheevaPlug:

Paths and misc options

Try features marked as EXPERIMENTAL: check
Prefix directory: "/usr/local/${CT_TARGET}" (this will result in all the tools residing in /usr/local/arm-unknown-linux-gnueabi) or, preferred: "/usr/local/sheeva". One important note though: DO NOT USE /usr/local or any directory containing data you plan to keep. THIS DIRECTORY WILL BE ERASED. You have been warned.
Use LAN mirror: Let's try to use a mirror there, so - check

Prefer the mirror: check
Base URL: ftp://ftp.heanet.ie/mirrors/ftp.gnu.org/gnu/ (this is an Irish mirror - not entirely sure it works, as the downloads didn't seem much faster, but worth a try)

Stop after extracting tarballs: check (we'll need to patch glibc!)
Number of parallel jobs: 2x the number of cores you have. In my case that would be 8 (quad core)
Maximum log level to see: change from "INFO" to "EXTRA"

Target Options

Target Architecture: arm
Use EABI: check
Emit assembly for CPU: arm926ej-s
Floating point: change from "hardware (FPU)" to "software"

Toolchain options: don't change anything
Operating System:

Target OS: change from "bare-metal" to "linux"
Get kernel headers from: change from "kernel's 'headers_install'" to "Use custom headers"
Path to custom headers directory/tarball: "/usr/src/sheeva"

GMP and MPFR:

GMP and MPFR: check
GMP version: 4.2.4 (latest)
MPFR version: 2.4.1 (latest)

binutils

binutils version: 2.19.51.0.2

C compiler:

gcc version: 4.3.3
C++: check

C-library:

C library: glibc
glibc version: 2.9
Threading implementation to use: make sure "ntpl" is set.

The rest should be left untouched. For your reference, I am providing the Crosstool-NG .config file I used. Please note that if you use a recent version of glibc, you MUST have a threading implementation set, but you can NOT use linuxthreads, as it's been deprecated (you WILL get errors if you do select it), so the only option to use in nptl.

Kernel headers & glibc 2.9 patch

Before you can run the build, we still need to setup our kernel headers.
At the time of this writing, the most recent kernel is linux-2.6.31.2, so just download and extract it somewhere. Then, within the linux-2.6.31.2/ directory, run the command:

make headers_install ARCH=arm INSTALL_HDR_PATH=/usr/src/sheeva

The INSTALL_HDR_PATH should match exactly what you used for "Path to custom headers directory/tarball" in the menuconfig of Crosstool-NG.
You should now find that you have an "include" directory containing the relevant kernel headers in /usr/src/sheeva

Once you have everything setup, you need to go back to the sheeva directory (because this is where the ct-ng config resides) and launch the build with:

cd /usr/src/sheeva
ct-ng build

If you followed what we did above, you will note that we checked the "Stop after extracting tarballs" option, and indeed the build process stops after "Extracting and patching toolchain components". The reason we did that is because glibc 2.9 needs to be manually patched to prevent the following error (undefined reference to `_begin') from occurring:

[ALL  ]    /usr/src/sheeva/targets/arm-unknown-linux-gnueabi/build/build-libc/elf/librtld.os: In function `_dl_start_final':
[ALL  ]    raise.c:(.text+0x54c): undefined reference to `_begin'
[ALL  ]    /usr/src/sheeva/targets/arm-unknown-linux-gnueabi/build/gcc-core-shared/lib/gcc/arm-unknown-linux-gnueabi/4.3.3/../../../../arm-unknown-linux-gnueabi/bin/ld: /usr/src/sheeva/targets/arm-unknown-linux-gnueabi/build/build-libc/elf/ld.so: hidden symbol `_begin' isn't defined
[ALL  ]    /usr/src/sheeva/targets/arm-unknown-linux-gnueabi/build/gcc-core-shared/lib/gcc/arm-unknown-linux-gnueabi/4.3.3/../../../../arm-unknown-linux-gnueabi/bin/ld: final link failed: Nonrepresentable section on output
[ALL  ]    collect2: ld returned 1 exit status
(...)
[ERROR]    Build failed in step 'Installing C library'

This known problem is documented here and if you have a look at the diff file, you'll see that we can easily manually patch this problem by editing "targets/src/glibc-cvs-2.9/elf/Makefile" and replace, on line 314:

-e 's/\. = 0 + SIZEOF_HEADERS;/& _begin = . - SIZEOF_HEADERS;/' \

with

-e 's/\. = .* + SIZEOF_HEADERS;/& _begin = . - SIZEOF_HEADERS;/' \

Building the cross-compiler

Once you have made this change, just launch ct-ng menuconfig again (from the /usr/src/sheeva directory, as this is where the config file resides) and remove the checkmark on "Stop after extracting tarballs" (in the "Paths and misc options" menu)

Now, you can launch the actual build of the tools with

ct-ng build

This will take a little while (about 15 mins on my machine) but should complete successfully. If you have a multiple core system, hopefully you didn't forget to change the "Number of parallel jobs" option (which is equivalent to the -j option of make, i.e. number of concurrent jobs to run at once), as this dramatically reduces the time it takes to compile the toolchain. The -j option should always be your friend when compiling a large source, like a Linux kernel for instance.

Time for a tea or coffee break!

Note that, near the end of the compilation, you might get the error "[ERROR] libtool.m4: error: problem compiling FC test program". From what I gather however, FC is a test for the Fortran 90 compiler, which we couldn't care less about, so, unless you got another error, I will consider this build process of success, and you should now have the whole set of cross compiler tools in /usr/local/sheeva/bin. Time to compile ourselves a new kernel!

Installing U-boot mkimage

While we now have the tools to create arm binaries, we're still missing the last piece of the puzzle to boot a kernel, and that is the mkimage utility (which is called at the end of a successful kernel compilation), which turns a newly crafted kernel into something U-Boot can actually launch.

You guessed it, no way in hell we're gonna use the Marvell provided mkimage tool - we're gonna recompile our own from source of course!
And once more, the good guys at Debian (never underestimate a Debianer!) provide us with what we need:

cd /usr/src/sheeva
wget http://ftp.de.debian.org/debian/pool/main/u/uboot-mkimage/uboot-mkimage_0.4.tar.gz
tar -xzvf uboot-mkimage_0.4.tar.gz
make
make install

Easy as a pie!

Cross-Compiling a new kernel for the SheevaPlug

At long last, we're ready to compile us some custom kernel!
At this stage, we can more or less follow the Compiling Linux Kernel for the Plug Computer tutorial from openplug.org . Henceforth:

cd /usr/src/sheeva/linux-2.6.31.2
make ARCH=arm kirkwood_defconfig
make ARCH=arm menuconfig

There, change the options that you want. If you plan to keep using UBIFS (which you should have switched to during the SheevaPlug Installer 1.0 upgrade), then make sure that you enable BOTH:

Device Drivers ---> Memory Technology Device (MTD) support ---> UBI - Unsorted block images ---> Enable UBI
File systems ---> Miscellaneous filesystems ---> UBIFS file system support
Device Drivers ---> Generic Driver Options, and make sure that both "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)" and "Automount devtmpfs at /dev" are enabled. Without those, you won't see init messages on the serial console after the root filesystem is mounted.

With this set, and the other default options from kirkwood_defconfig, you should be able to produce a usable kernel. Now is obviously a good time to add ext4 & NTFS suppot, and remove features (802.11 stack) that you do not want. Finally, we're ready to compile, and the kernel makes cross compilation very easy for us, as its CROSS_COMPILE feature enables us to specify exactly which tools it should use instead of the default ones. Thus, because we have an arm-unknown-linux-gnueabi-gcc, arm-unknown-linux-gnueabi-ld, etc. in /usr/local/sheeva/bin, we will use the line:

make -j8 ARCH=arm CROSS_COMPILE=/usr/local/sheeva/bin/arm-unknown-linux-gnueabi- uImage

and in about 3 minutes (vs. one hour if done on the SheevaPlug) you should end up with something like

Image Name:   Linux-2.6.31.2
Created:      Tue Oct  6 14:50:51 2009
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    3151992 Bytes = 3078.12 kB = 3.01 MB
Load Address: 0x00008000
Entry Point:  0x00008000
Image arch/arm/boot/uImage is ready

Building the modules

You probably still have a few modules to compile as well, which you can do as follows

make -j8 ARCH=arm CROSS_COMPILE=/usr/local/sheeva/bin/arm-unknown-linux-gnueabi- modules
make -j8 ARCH=arm CROSS_COMPILE=/usr/local/sheeva/bin/arm-unknown-linux-gnueabi- INSTALL_MOD_PATH=./modules modules_install

Just don't forget that you'll need to copy the content of the ./modules directory to your Ubuntu image to keep the kernel happy

Testing the new kernel on the plug

In a next post, we'll see how to actually flash that kernel on the plug. Before we do that though, we want to ensure that it can boot our current system, so we'll try to launch it from an USB stick.
Off we go then to copy your shiny new kernel to an USB stick with

mount /dev/sde1 /mnt/usb
cp arch/arm/boot/uImage /mnt/usb/
sync
umount /mnt/usb

For the test part, we'll need the serial console ("screen /dev/ttyUSB0 115200,-crtscts" or similar), with which we first reboot our system, and interrupt the autoboot to get to the Marvel >> prompt. From there, the following set of commands should boot the existing system with our new kernel:

usb start
fatload usb 0 0x00800000 uImage
bootm 0x00800000

Success? Then my work here is done.

2009-10-03

OpenOCD and the SheevaPlug on Linux x86_64

This is a tutorial for people like me who want to start with JTAG and OpenOCD access on the SheevaPlug. Most of this stuff regarding the installation of OpenOCD on Linux x86_64 is of course generic and can be used for other FTDI based JTAG devices like.

First of all, if you're running a 64 bit OS (Vista, Win7), a word of advice: Don't waste your time trying to get OpenOCD to work on a 64 bit Windows - there's no ready-made package that works (the 32 bit version just don't), so the only way is to recompile the whole shebang yourself, and it's a complete mess, as you will also need a 64 bit gcc-like compiler, and figure out how to get a 64 bit version of a the FTDI GPL library talk to the 64 bit libUSB drivers.
If I ever manage to get a Windows version going, you'll be the first to hear about it, but for the time being, if you value your time, stick with Linux.

Now, the distro I am using is Slackware x86_64. There are of course tutorials on how to compile OpenOCD for Linux here and there, but things are slightly different for 64 bit version, which is why I'm posting my own version.

Before anything else, you want to have the serial console to the SheevaPlug through the USB FTDI device. For that you need to compile the kernel driver for the "USB FTDI Single Port Serial Driver" either as a module, or directly in your kernel. You will find that option, in the kernel, under: "Device Drivers ---> USB support ---> USB Serial Converter support ---> USB FTDI Single Port Serial Driver"
Once you have the driver loaded, with the USB cable connected to the sheevaplug, you should get a /dev/ttyUSB0 device, which you can use as a regular serial port.
The best way to connect to the SheevaPlug in Linux (or to any serial terminal for that matter) has to be to use screen, with a command like:
```
screen /dev/ttyUSB0 115200,-crtscts
```
Once you have confirmed that you can connect to the plug using the FTDI USB Serial converter driver, you can move to building OpenOCD, as it's a good indication that Linux should have no trouble accessing the rest of the FTDI chip functionalities

OPTION 1: Using the proprietary libftd2xx library from FTDI, provided for completion. Note that using this option will kill any opened serial console whenever you launch openocd, whereas this does not occur with OPTION 2 below, which I strongly advise you to use.
On an x86_64 MUST pick up the 64 bit version of the Linux drivers from the FTDI website. At the time of this post, that means you must download libftd2xx0.4.16_x86_64.tar.gz, NOT libftd2xx0.4.16.tar.gz. What's more, when you install the library, it has to go into lib64, NOT lib else you will get the ominous
```
checking whether ftd2xx library works...
configure: error: Cannot build & run test program using ftd2xx.lib
```
Thus:
```
cd /usr/src
wget http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx0.4.16_x86_64.tar.gz
tar -xzvf libftd2xx0.4.16_x86_64.tar.gz
cp libftd2xx0.4.16_x86_64/libftd2xx.so.0.4.16 /usr/local/lib64
ln -s /usr/local/lib64/libftd2xx.so.0.4.16 /usr/local/lib64/libftd2xx.so
# even if you specify --libdir=/usr/local/lib64 on openocd compilation
# it requires libftd2xx.so.0 in /usr/lib64!
ln -s /usr/local/lib64/libftd2xx.so.0.4.16 /usr/lib64/libftd2xx.so.0
```

OPTION 2 (PREFERRED): Using the GPL/Open source version of the FTDI library

cd /usr/src
wget http://www.intra2net.com/en/developer/libftdi/download/libftdi-0.16.tar.gz
tar -xzvf libftdi-0.16.tar.gz
cd libftdi-0.16
# by default, libftdi will go in /usr/local/lib, whereas, on x86_64, it should go to lib64, thus
./configure --with--libdir=/usr/local/lib64
make
make install
# openocd looks in /usr/lib64
ln -s /usr/local/lib64/libftdi.so.1.16.0 /usr/lib64/libftdi.so.1

Now it's time to get OpenOCD compiled. For that:

svn checkout svn://svn.berlios.de/openocd/trunk openocd
cd openocd
./bootstrap
# OPTION 1 - PROPRIETARY LIB FROM FTDI
./configure --libdir=/usr/local/lib64 --enable-maintainer-mode --enable-ft2232_ftd2xx
# OPTION 2 - GPL FTDI LIBRARY
./configure --libdir=/usr/local/lib64 --enable-maintainer-mode --enable-ft2232_libftdi
make
make install

Note that if you don't use the "--enable-maintainer-mode" option, you will get an error when make reaches the creation of the documentation, which is not a problem per se, but will prevent the openocd configuration scripts to be copied over on make install

If the above completed successfully, then you have openOCD ready to run. To connect to the SheevPlug then, issue a:

openocd -f /usr/local/share/openocd/scripts/board/sheevaplug.cfg

At this stage, if you are getting the following, then you need to reboot the plug and launch openOCD in the early stages of reboot:

Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: feroceon.cpu: IR capture error; saw 0x00 not 0x..1
Warn : Errors during IR capture, continuing anyway...
Error: unexpected Feroceon EICE version signature

What you really want to see when launching openOCD is:

root@stella:/usr/src/openocd# openocd -f /usr/local/share/openocd/scripts/board/sheevaplug.cfg
Open On-Chip Debugger 0.3.0-in-development (2009-10-07-01:35) svn:2808
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
2000 kHz
jtag_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
Info : clock speed 2000 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 0x0a02, ver: 0x2)

OpenOCD is a client server software, so when you launch openOCD, you are really only launching the server part. To actually send JTAG commands and all that Jazz, you need to open a client session with:
```
telnet localhost 4444
```
This should then provide you with the On-Chip Debugger prompt.

Now, JTAG operations are a bit tricky (there are various JTAG states involved) so you can't really send any JTAG command you want (eg. NAND ID) any time you like and expect a meaningful reply. If you looked in the cfg file for the SheevaPlug, you'll see that before any NAND access operation is performed, a "sheevaplug_init" command is being called, so this is what we'll do. Once it's run, you will get a whole lot of interesting commands working, as illustrated with the session below:

> sheevaplug_init
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
0 0 1 0: 00052078
> scan_chain
     TapName            | Enabled |   IdCode      Expected    IrLen IrCap  IrMask Instr
---|--------------------|---------|------------|------------|------|------|------|---------
 0 | feroceon.cpu       |    Y    | 0x20a023d3 | 0x20a023d3 | 0x04 | 0x01 | 0x0f | 0x0c
> nand probe 0
NAND flash device 'NAND 512MiB 3,3V 8-bit' found
> nand list
#0: NAND 512MiB 3,3V 8-bit (Hynix) pagesize: 2048, buswidth: 8,
    blocksize: 131072, blocks: 4096
> nand info 0
#0: NAND 512MiB 3,3V 8-bit (Hynix) pagesize: 2048, buswidth: 8, erasesize: 131072
#0: 0x00000000 (128kB) erase state unknown (block condition unknown)
#1: 0x00020000 (128kB) erase state unknown (block condition unknown)
(...)
#4094: 0x1ffc0000 (128kB) erase state unknown (block condition unknown)
#4095: 0x1ffe0000 (128kB) erase state unknown (block condition unknown)

2009-10-02

Accessing an SD card on the SheevaPlug

Not something I knew beforehand.
USB devices are either auto detected or can be accessed as regular SCSI Disk devices (/dev/sda# - by the way, the SheevaPlug has no problem powering a 7200 rpm 2.5" HDD [UPDATE: until you try it for a few days, and its PSU blows up), but not SD Cards.

The device name to use then is: /dev/mmcblk0 for the raw device and /dev/mmcblk0p1 for the first partition.

SheevaPlug - Let's get cracking!

Alright, now that we have our new shiny SheevaPlug, let's get started.

Of course, first thing we want is a serial console to the Linux OS, so we'll plug the mini <-> std USB cable provided to one of our USB ports and find out if Vista (x64) is able to figure out the FT2232D driver itself... which it can't (surprise, surprise). No big deal. The PDF readme from the DevKit CD tells you that you can find the TeraTerm Windows drivers in the SheevaPlug_Host_SWsupportPackageWindowsHost.zip or, for a more up to date version, at http://www.ftdichip.com/Drivers/D2XX.htm. Installing the drivers with Vista autodetect is still a pain, as you don't get the option to browse to the driver directory (yes, Microsoft, all your users are complete tools - that's why they use your products in the first place!), but with the device manager, you're good to go. Yay, another COM port! Yay a set of USB Serial converters!
Alrighty, if we have our COM port, so we're good to go with the ever versatile putty. The FIRST thing you want to know is that the serial console is set to 115200 bauds, and the SECOND thing is that the default logon is root/nosoup4u (Globalscale: even their passwords are cool!). And we're in... Niiiiiice! dmesg, df -h, top, they're all waiting for you, but first you might as well wanna change the date & time, as mine was set to Apr 22 1953. That's like, way old! Also, since you're gonna wanna try a reboot to see what the console spills out, I'll just mention that there's a very loooong pause during boot after the line "eth0: link up, full duplex, speed 1 Gbps", so just be patient, you will get your logon prompt. Oh and you'll see warnings here and there as well, but what do you expect.
What do we have here? Ubuntu? Huh, well, at least it's Debian based and we have a good chunk of space left. We could have fared much much worse (read anything that's based on Red Hat). We'll install armedslack soon enough but let's get cracking then. Of course, we'll want to recompile stuff on the device itself (something that can't be done on a WRT!). Let's start by compiling the very handy memtester to do a little bit of torture test, and see how much the baby heats up when using RAM.
According to google, installing gcc on the SheevaPlug ios as easy as running: "apt-get install build-essential"... Except that you are missing the cache directory so the command fails. You need to issue a
```
mkdir -p /var/cache/apt/archives/partial
```
before you can use apt-get (and you might want to add this line to your /etc/rc.local as well). But we're still not out of the woods yet, as the package upgrade seems to start up fine, but after a while, you get errors like:
```
Failed to fetch http://ports.ubuntu.com/pool/main/b/binutils/binutils_2.19.0.20090110-0ubuntu1_armel.deb  404 Not Found
```
Checking that URL confirms that the package is no longer hosted there.
Drats!
The easiest solution at this stage is to update your system as a whole with "apt-get update". This might take a while, but it seemed to get the problem sorted, as the subsequent "apt-get install build-essential" completed hapilly. You might also want to run an "apt-get autoremove" after that, to free up some space. Good, now we can compile natively on the plug.
"-bash: wget: command not found"? Who on earth delivers a system without wget? "apt-get install wget" then, but sheesh! But then...
```
root@debian:/usr/src# wget http://pyropus.ca/software/memtester/old-versions/memtester-4.1.2.tar.gz
--2009-10-02 14:05:28--  http://pyropus.ca/software/memtester/old-versions/memtester-4.1.2.tar.gz
Resolving pyropus.ca... failed: Name or service not known.
wget: unable to resolve host address `pyropus.ca'
```
Indeed, DNS resolution doesn't seem to work out of the box and the default /etc/resolv.conf goes something like:
```
domain lan
search lan
nameserver 127.0.0.1
```
It's clear that with only these 3 lines, you're not gonna get very far (it's a wonder apt-get still managed to find its way - must be using direct IPs). Let's just comment the domain & search lines and add our ISP's nameservers before the 127.0.0.1 to get some resolution going. Now, please be aware that any changes you make here won't hold on reboot, so for more details on how to fix the default annoyance, you might as well have a look at the New Plugger Howto from openplug.org.
Good, now we can wget memtester, compile it and run it (and it looks like our RAM is good). Maybe I'll try mprime later on as well... But to complete the setup of a half decent Linux system, let's issue an "apt-get install screen.

Next, we'll try to play with JTAG and OpenOCD...

SheevaPlug - first impressions

At last, my SheevaPlug Development Kit has arrived!

For those who don't know yet what the SheevaPlug is, you can have a look at this short CNET article or Marvell's slightly longer blurb about this wonderful little device.
I ordered mine (UK version) from Globalscale about 2-3 weeks ago, to basically replace my long trusted WRT54G running openWRT with something that has a little more punch and I/O capabilities. The truth of the matter is, I almost never use the WRT for WiFi, but having an always on & completely customizable Linux low power "server" has proved invaluable (Samba share for easy data interchange between any machine, DHCP server, bootp/tftp server, nmap & other networking tools provider, etc.), and I had been waiting for some time to see something like Marvell's plug computer come out, as it's basically a glorified hacked WRT54G, without the unneeded Wifi/network hub features.

For those who can't be bothered to read the whole post (and who can blame them!), I'll jump right into the main points of my first impressions:

The not so good:

Globascale's delays in shipment, and total lack of response when asked for updates. Granted delays are likely unavoidable (I doubt they're shipping Sheevaplugs by the truckload right now), but that doesn't explain why it took about 2 weeks of repeated e-mails to sales to get a simple status update on the order.
No choice but to use Fedex for shipping if you're not in the US. Granted, once it's shipped, the delivery is fast indeed, but considering the shipping delay, you might as well want to use regular post and spare a few bucks.
Also, since Fedex are really happy to help with the obnoxious EU VAT & Customs Duty extortion scheme, you will be hit by 46% retroactive VAT on import (€31.20 - I really wish I was making this up), meaning that, as usual, no matter what you do, amount in $ = amount in €, and you still have to pay €99 for a bloody $99 item. Better believe this is the last time I import anything with Fedex.
HEED MY ADVICE - DO NOT IMPORT ANYTHING WITH FEDEX, EVER!!!
Unlike the most excellent US removable plug (see below), the UK plug is just a common adapter to fit over the US socket, so it's not as sleekly designed. Not that big a deal, but it adds to the overall height of the device when used in plug mode. It would have been nice to see an integrated UK plug in the way the US one is. Also, the Globalscale UK devkit photos don't make that as clear as they could.
The mainboard is now rev. 1.3 and very different from the reference mainboard you see in the documentation (see below). For starters, there is no longer a separate mainboard for JTAG and SDIO, and the solder-able port for an ARM JTAG connector is gone. Gone as well is the generic GPIO connector. There still seems to be a small JTAG port, but with only 8 connectors and a non-standard smaller socket too be fitted in, it will be a pain to interface with. Not sure if many people would put single board vs 2 separate boards design as a disadvantage, but I was kind of planning on using the standalone expansion board as a cheap JTAG device (it has the very well known FT2232 JTAG IC on it) but now using the SheevaPlug hardware as a JTAG interface to other boards, or as a general purpose IO device, is going to be less of a possibility for your regular electronics hobbyist.
UPDATE: for some of the new ports pinouts (still no JTAG desc), have a look here
Even idle, the device seems to run a bit hotter than I anticipated (It's certainly running hotter than my WRT54G). Definitely not that hot (akin to one of the numerous power bricks you have in your house), and most likely the heat is due to the PSU rather than the chip themselves, but still, I've seen power bricks run cooler than that (the 12V DC WRT brick being one of those). Of course, anybody who hears "heat" automatically thinks "increased power consumption", so I don't know how that translates into wasted wattage. My guess is this might be due to using a 110V/220V compatible PSU. Using a localized source voltage PSU for 220V -> 5V delivery would probably reduce the heat.
[UPDATE 2009.10.08] The Plug does run scaringly hot when running at full load for a prolonged period of time, as I just found out through a rogue process.
The metal parts on both USB and network sockets are almost burning when running for a long time at 100% of the CPU, and you wouldn't want to leave something in contact with them then. Still probably not hot enough to light up paper or plastic that would be in contact, yet quite scary... And it looks like the PSU unit does play some part in raising the whole temperature of the plug on full load. I also found that I had to enlarge some of the vents on my plug with a knife because they had been pourly moulded and were not entirely open. Still, I don't think Even then, there are too few vents on the current Plug and I don't think it is designed for adequate cooling! Something that definitely needs some improvement for later models.
My advice: make sure you leave ample space around the plug, and check that all your vents are fully open.

The good:

Brilliant design from Globalscale. As somebody else said, whoever designed that removable socket for corded/plugged needs to have both a raise and a corner office. And despite the point I made above, the single mainboard layout is very well done (and rumour has it there is even an eSata port in there). Those guys have sharp engineers! The whole device itself feels both sturdy, inconspicuous, yet elegant. Even the cardboard packaging the plug is shipped in is very good design, so much so that I almost felt like taking pictures of the packaging. But then I thought, only Apple fanboys ever do something like that...
Does exactly what it says on the tin. The layout design might have changed, but you still get 2 USB ports (1 for debug), 1 SDIO port, 1 Gb Ethernet port and a computer with 512 MB RAM, 512 MB Flash, a most excellent 1.2 GHz ARM CPU, plus a JTAG device that's compatible with OpenOCD. Who could ask for more?
Can power a 2.5" USB HDD (tested with both a 5400 rpm 100 GB and a 7200 rpm 320 GB HDD). Impressive!
Loads of free space on the flash with the default Ubuntu installation

Alright, now it's time for opening the device and posting some pictures! Wait, are you telling me that the first thing you do when receiving a cool new toy is NOT tearing it apart to see what's inside? What on earth are you doing with your life?

Some pictures