Creating a Visual Studio 2008 application that uses Cairo

One day or another, you'll want to produce quick 2D data with your code for visualization, and after looking through hordes of libraries that do not satisfy your needs at all (listen, it's not that hard: I don't want graphing, I don't want 3D, and I certainly don't want proprietary closed source paying software! I just want something that gives me a simple canvas to draw elementary stuff like text fields or simple graphics using 2D coordinates), you'll settle down on Cairo as the best trade-off for quick and easy generic 2D output. If it's used by Firefox for SVG output, it certainly should satisfy our needs.

Unfortunately, or should I say, as usual, whenever you want a nice step by step tutorial on how to get you started with using Cairo on Windows, you'll get nothing but a handful of incomplete snippets here and there. This short step by step tutorial attempts to remedy that.

For this exercise, we'll just create a C console application that outputs "Hello, World" to a PNG file using Cairo using Visual Studio 2008.

1. Create a new Win32 Console Application in Visual Studio. Let's call it cairo_test. And since we don't wanna get bogged down by Microsoft's crap on a simple hello world app, on Application Settings -> Additional Options, make sure you check "Empty Project".
   
   
2. Create a new source file - let's call it main.c - and fill it with the following content (which I picked up from here):

   #define LIBCAIRO_EXPORTS
   
   #include <cairo/cairo.h>
   
   int main(int argc, char** argv)
   {
   cairo_surface_t *surface;
   cairo_t *cr;
   
   surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 240, 80);
   cr = cairo_create (surface);
   
   cairo_select_font_face (cr, "serif", CAIRO_FONT_SLANT_NORMAL, CAIRO_FONT_WEIGHT_BOLD);
   cairo_set_font_size (cr, 32.0);
   cairo_set_source_rgb (cr, 0.0, 0.0, 1.0);
   cairo_move_to (cr, 10.0, 50.0);
   cairo_show_text (cr, "Hello, World");
   cairo_destroy (cr);
   cairo_surface_write_to_png (surface, "hello.png");
   cairo_surface_destroy (surface);
   
   return 0;
   }

   Don't worry about the "#include <cairo.h>" for now, we'll sort it out in a second
   
   
3. Download the latest Cairo Dev package files for Windows from http://www.gtk.org/download.html by picking up either Windows 32 or 64. At the time of this article, the latest Dev is cairo 1.8.8.
   Extract the package directories "lib" and "include" at the root of your Visual Studio project. You can safely ignore the other directories from the archive.
   
   
4. Change the Active configuration if needed and right click on your project in the Solution Explorer panel to access the properties page.
   
   • In Configuration Properties -> C/C++ -> Additional Include Directories, create a new entry and point it to "<your project root>\include". Be mindful that there is a cairo subdirectory there, which is why we used cairo/cairo.h in our source. Just make sure the source and your include paths match.
   • In Configuration Properties -> Linker -> Input -> Additional Dependencies, type "cairo.lib"
   • In Configuration Properties -> Linker -> Gener al -> Additional Library Directories, create a new entry and point it to the "<your project root>\lib" directory you extracted above. (Oh, and why oh why are the Additional Dependencies and Additional Library Directories on 2 different pages Microsoft?!? Where's the twisted UI logic behind that?)
     
     
5. Try to compile your project. It should complete without errors. Note that if you picked up the Windows 64 libraries, you MUST create a new x64 configuration, or the process will fail with "fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'". Just follow these guidelines if you don't know how to do that.
   
   
6. Bet you didn't wait and tried to run your executable already. And of course, you got the DLL not found errors. Why of course, now you need to install the bunch of DLLs Cairo needs to be happy. Basically, what you should do is pick up the DLLs from ALL the binary packages below (still provided by the GTK+ Windows 32 or Windows 64 Project binaries) and extract them into the Release or Debug directory that contains your executable. For all of the archives, you j ust need to extract the DLL - all the other files are irrelevant:
   
   • cairo Binaries (yes you need the binaries package too, as the Dev one doesn't contain the DLL) -> libcairo-2.dll
     
   • zlib Binaries -> zlib1.dll
   • libpng Binaries -> libpng12-0.dll
     
   • Freetype Binaries -> freetype6.dll
     
   • FontConfig Binaries -> libfontconfig-1.dll
     
   • expat Binaries -> libexpat-1.dll
   If you're gonna produce JPEG or TIFF images with your application, you probably want to install those DLLs too, but you already guessed that.
   
   
7. Now you can actually run your test program. It should produce an "hello.png" file that looks like the one below:
   
   

Alrighty then. Now you can get going and visualize the hell out of whatever ground-breaking application you've been thinking of!

Formatting node titles in drupal

Bit disappointed in Drupal. Of course it's a great tool (and it's GPL), but they probably won't be 'there' till version 8 at best with regards to full fledged & intuitive customization.
Not that I really mind modifying the PHP code anyway, but I'd rather create actual content instead of doing that.

So, of course you have installed the cck module to create fields, and it's oh so convenient (although customizing the field formatting can be a bit of a pain there too), but unfortunately, the title field for a node does not fall under the cck realm, and thus you don't have means of applying any of the default or custom formatters you might be using with cck. Bummer!

Let's say you have created a new content type, with type 'my_ct' then (would be listed along with 'book', 'page', 'story'), and you are using a numeric title field (again, with no possibility of setting a content type for node titles and check input, Drupal is quite limited). Now you want to display your title in a custom format. Eg. if your node title value is '12', you want your displayed title to be "My_Content_000012", with leading zeroes.
For that, assuming you are using the default garland theme of Drupal v.6, edit the file drupal/themes/garland/template.php and in "function phptemplate_preprocess_page(&$vars)" add the following:

  // Custom format for my_ct node titles
 if ($vars['node']->type == 'my_ct') {
   $value = $vars['node']->title;
   // Don't apply formatting unless numeric
   if (!is_numeric($value))
     $vars['title'] = $value;
   else
     $vars['title'] = sprintf("My_Content_%06d", $value);
 }

Now, if you want better customization or input validation for titles, you can probably get started on that with the following article.

Don't use Nero, period

Growing tired of Nero's inability to handle cue sheets (wanna make Nero crash? Just pick up a cue sheet here and there). This program has so many drawbacks, it's a wonder they still manage to sell it (yes, Ahead, it is normal in 2009 for a computer to become totally unusable for about 30 seconds whenever you insert a CD and Nero is running - background poll-wah?).

The answer: use cdrecord and get back the time and coaster you'd have gotten with Nero.
To burn a CDDA with text from a CUE sheet using cdrecord:

cdrecord dev=1,0,0 -eject - copy -v -text -useinfo -dao cuefile=<some file>.cue

Now, once I get a 64 bit, non cygwin1.dll dependent version of cdrecord in MinGW, I'll be a happy man.

Task Manager Windows Shortcut

Found that one totally by accident (and yes, sometimes it doesn't hurt checking the official Microsoft documentation): <Ctrl> <Shift> <Esc> = bring up the Task Manager

Now, give me a shortcut to bring up the Device Manager (well, you can go there in 2 steps, through <Windows <Pause/Break> (= System Information) -> Device Manager, but still...

Oh, and of course, you want to replace the default Task Manager with Process Explorer, as the shortcut works for it too.

Compiling OpenOCD on Windows 64 systems

This time with libftdi/libusb - just follow the leader. ;)

Or, if you just want my latest (development) installable zip of OpenOCD for Windows 7 64 / Vista 64, try here. Just extract, follow the instructions, and you should have OpenOCD 0.3.0 running on Windows 64 bit in no time.

Took a little while to get this stuff working, because of a very nasty libFTDI bug, as well as the usual hurdle of driver signing for Windows 64. I think the FSF should establish a free driver signing program for well established GPL projects, like OpenOCD, so that we get "Microsoft Approved" signed drivers. That would foil Redmond's obvious attempts to oust OpenSource from Vista 64 / Windows 7 64 (although they'd have to walk into the scheme and pay Microsoft/Verisign for the signing privilege).

There's got to be a way to restore freedom back to the users of Windows OS!

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:

1. 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
   
   
2. 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.
   
   
3. 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)
   
   
4. 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.
   
   
5. 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.
   
   
6. 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.
   
   
7. 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

8. 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

   
   

Using the SheevaPlug as an iSCSI target for Vista or Windows 7

(Updated 2010.08.08)

Well, since I played with this iScsi stuff just for the sake of it, I might as well post a quick guide.

For this setup, I will be using the SheevaPlug running Slackware 13.0 (armedslack) on an SDIO card, a 100 GB HDD connected to the plug through USB (/dev/sda, but you could use a partition or even an image file) and a version of Windows that supports iSCSI (Vista or later). The SheevaPlug server has been creatively named "sheeva".

Compiling

The de-facto iSCSI target server tool for Linux is the Linux SCSI target framework (tgt) project (NB: you know you need to come up with better designation when your URL is actually shorter than your project name), so off we go and download the latest version (Important note: at the time of this post update, version 1.0.7 doesn't appear to work for the SheevaPlug, but 1.0.5 does).
We're pretty much going to follow the "./doc/README.iscsi" from the archive, so you might want to keep that file open for reference.
Once extracted on the SheevaPlug, cd to the usr/ directory and issue a "make ISCSI=1; make install". This package is not that big, so we can compile it on the Plug directly. Remember to add ISCSI=1, as default make will not have iSCSI.

Starting the target server daemon

After that, as root, you need to launch the daemon with

tgtd

The syslog should tell you that everything's rolling with a line like

Oct  9 12:46:23 sheeva tgtd: Target daemon logger with pid=1897 started!

Setting up the iSCSI target

This is where the bulk of our configuration occurs. What we're going to set below is an iSCSI drive named "sheeva:hd100" that maps to our /dev/sda HDD.

1. First we need to create that device:
   

   root@sheeva:~# tgtadm --lld iscsi --mode target --op new --tid 1 --target sheeva:hd100
   root@sheeva:~# tgtadm --lld iscsi --mode target --op show
   Target 1: sheeva:hd100
   System information:
   Driver: iscsi
   State: ready
   I_T nexus information:
   LUN information:
   LUN: 0
       Type: controller
       SCSI ID: IET     00010000
       SCSI SN: beaf10
       Size: 0 MB
       Online: Yes
       Removable media: No
       Backing store type: rdwr
       Backing store path: None
   Account information:
   ACL information:
   root@sheeva:~#

2. Now, despite the fact that a device with LUN0 was created as shown above, this is just a virtual controller device, not a physical target, and we still need to create a LUN for our device:

   root@sheeva:~# tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 --backing-store /dev/sda
   root@sheeva:~# tgtadm --lld iscsi --mode target --op show
   Target 1: sheeva:hd100
   System information:
   Driver: iscsi
   State: ready
   I_T nexus information:
   LUN information:
   LUN: 0
       Type: controller
       SCSI ID: IET     00010000
       SCSI SN: beaf10
       Size: 0 MB
       Online: Yes
       Removable media: No
       Backing store type: rdwr
       Backing store path: None
   LUN: 1
       Type: disk
       SCSI ID: IET     00010001
       SCSI SN: beaf11
       Size: 100030 MB
       Online: Yes
       Removable media: No
       Backing store type: rdwr
       Backing store path: /dev/sda
   Account information:
   ACL information:
   root@sheeva:~#

   This time, we have our physical device listed. Note that you could also mount a partition instead of a whole device, and make it appear as a device through iSCSI
   
   
3. At this stage, we have a target, but it doesn't accept inbound connections ("ACL information" is empty), so:

   root@sheeva:~# tgtadm --lld iscsi --mode target --op bind --tid 1 --initiator-address ALL
   root@sheeva:~# tgtadm --lld iscsi --mode target --op show
   Target 1: sheeva:hd100
   System information:
   Driver: iscsi
   State: ready
   I_T nexus information:
   LUN information:
   LUN: 0
       Type: controller
       SCSI ID: IET     00010000
       SCSI SN: beaf10
       Size: 0 MB
       Online: Yes
       Removable media: No
       Backing store type: rdwr
       Backing store path: None
   LUN: 1
       Type: disk
       SCSI ID: IET     00010001
       SCSI SN: beaf11
       Size: 100030 MB
       Online: Yes
       Removable media: No
       Backing store type: rdwr
       Backing store path: /dev/sda
   Account information:
   ACL information:
   ALL
   root@sheeva:~#

4. Here you might want to find out if Windows is able to see our target, so you can fire up the iSCSI Initiator (in Control Panel -> Administrative Tools). If you are prompted to enable the iSCSI service on startup and modify the firewall rules, accept it.
   Now, if you go to the "Targets" tab and press Refresh, you'll probably see that your target is not yet detected.
   To make it appear in the target list, you want to go to the "Discovery" tab and click "Add/Discover Portal". Then provide the IP/DNS of your server. Port 3260 should be fine as it's used by the Target daemon on the Linux server.
   After doing this, if you go to the "Targets" tab again, you should see something like this listed:

   sheeva:hd100              Inactive

   If not, you might want to check your daemon, firewall, etc. as you should be able to detect the target at this stage.
   
   
5. If you're fine with anybody being able to connect to our iSCSI target on your network, then you can just try to press "Log On" in the Targets tab, and you should be able to connect. You can then go to Computer Management, and you should be able to see the disk!
   You should also see who is connect to your target in the "I_T nexus information" section from tgtadm in Linux:

   root@sheeva:~# tgtadm --lld iscsi --mode target --op show
   Target 1: sheeva:hd100
   System information:
   Driver: iscsi
   State: ready
   I_T nexus information:
   I_T nexus: 4
       Initiator: iqn.1991-05.com.microsoft:dusk
       Connection: 1
           IP Address: 192.168.1.184
   LUN information:
   LUN: 0
       Type: controller
       SCSI ID: IET     00010000
       SCSI SN: beaf10
       Size: 0 MB
       Online: Yes
       Removable media: No
       Backing store type: rdwr
       Backing store path: None
   LUN: 1
       Type: disk
       SCSI ID: IET     00010001
       SCSI SN: beaf11
       Size: 100030 MB
       Online: Yes
       Removable media: No
       Backing store type: rdwr
       Backing store path: /dev/sda
   Account information:
   ACL information:
   ALL
   root@sheeva:~#

   Pretty cool, heh?
   If you do want to restrict access, you should of course follow the README.iscsi and add iSCSI target accounts. Then you can provide these credentials to the CHAP logon parameters in Windows (which can be accessed by clicking "Advanced" in the "Log On to Target" dialog. Be warned however that Windows will return a "CHAP secret given does not conform to the standard" error if your password is too short, so you need to make it at least 10 characters or more.
   To disconnect from a target, on Vista, simply click on "Details", select its Identifier and click "Log off...". For Windows 7, Microsoft did the wise thing and added a "Disconnect" button.
   
   IMPORTANT NOTE: Because we used LUN 1, and not LUN 0, if you attempt to boot from this newly created iSCSI disk, you MUST fill in the LUN parameter in the iSCSI root path syntax (the sequence of 4 columns that most guides will leave blank). In our case, if we wanted to use the device above for booting with gpxe/dnsmasq, we would add the following in dnsmasq.conf:

   dhcp-option=net:gpxe,17,"iscsi:192.168.1.3:::1:sheeva:hd1"

   Notice that there is a "1" for the LUN before "sheeva:hd1" and that we used :::1: instead of ::::. Likewise if you use a nonstandard port (different than 3260), you would use something like ::<custom port>:<LUN>:<target name>. This is detailed in RFC 4173, or you can find more information here.
   

Checking removable media for badblocks on Linux

This comes handy when you are flashing firmwares from USB and don't want to take any risk with data corruptions (most firmwares images have checksums or CRCs, but who knows...)

Linux provides a badblock command to do just that. Obviously, this is a DESTRUCTIVE test (all data on your media will be erased without warning), and you'll need to reformat your media afterwards. Oh, and of course the badblocks command is available on the SheevaPlug.

badblocks -t random -svw <your_device>

Flashing a new kernel on the SheevaPlug

This is the last piece of the puzzle with regards to our using a customized Ubuntu on the internal Flash. After that, we'll switch to using ArmedSlack on the MMC (but we'll keep that rescue Ubuntu image on the internal Flash).
Because we've pretty much done that before, flashing the new kernel is very straightforward, so I'm going to comment a little bit about the U-Boot commands we use.

As you'd expect, the "fatload usb 0 0x00800000 uImage" just takes the uImage file from the USB and loads it in RAM @ address 0x00800000, and it's this RAM image that we are going to flash. Because of the

mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)

option we pass to our U-Boot boot command (see what the command "printenv bootargs" reports in the Marvell>> prompt, or refer to the setenv we did previously), U-Boot expects the kernel uImage to be 0x400000 bytes in length (that's 4 MB) starting at address 0x100000 on the NAND Flash. Therefore, we will need to write the 4MB from our RAM containing the loaded uImage to 0x100000 on the Flash.
But before we can write the Flash we need to erase it.
Oh, and don't worry about our kernel image not being exactly 4 MB in length. As long as its size is less that 4 MB, you'll be fine.
If it's more though, then you will need to move the rootfs starting at 0x100000 + 4MB = 0x500000, and change your bootargs parameters accordingly.

All in all, to replace the existing kernel with a new

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 uImage
reading uImage
...................................................................................................................................................................................................................................................................................................................

3152056 bytes read
Marvell>> nand erase clean 0x00100000 0x00400000

NAND erase: device 0 offset 0x100000, size 0x400000
Erasing at 0x4e0000 -- 100% complete. Cleanmarker written at 0x4e0000.
OK
Marvell>> nand write.e 0x00800000 0x00100000 0x00400000

NAND write: device 0 offset 0x100000, size 0x400000

Writing data at 0x4ff800 -- 100% complete.
4194304 bytes written: OK
Marvell>> reset

The bootup sequence shouldn't be that much different from the one you got when testing the new kernel in RAM

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:

1. Compiling a cross compiler manually is absolute hell!
2. 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.

Upgrading the factory SheevaPlug nand to a more efficient version

If you've had a look at openplug.org, as you should have, you've read that the default installed NAND kind of blows (slow MMC/NAND accesses, old U-Boot version that lacks versatility to install newer kernels, etc.), so you'll want to upgrade the default NAND (u-boot and Ubuntu) to something that's more up to date.

Well, the good guys at openplug.org heard you and made a readily available package for ya (see SheevaPlug Installer in the HowTo's section), so off you go an download the big tarball.
Only thing is, well, they've customized their packages for the masses (that still run a 32 bit OS), not the classes (x64), and they insist on using a PHP installer (eeeeew!!!).
Are we gonna trust a one size-fits-all installer to cover our needs? Of course not!

The purpose of this guide then is to show you how to manually install the SheevaPlug Installer v1.0 from a Linux x86_64 environment, since, if you followed the previous post, you should now have a working openocd there. Of course, this stuff will work on 32 bit Linux as well.

For the purpose of this exercise, we'll assume that you have extracted the tar in /usr/src, and thus you have a /usr/src/sheevaplug-installer-v1.0/ directory and that you have a FAT32 formatted USB stick mounted in /mnt/usb

First we need to populate the USB stick.

cd /usr/src/sheevaplug-installer-v1.0/installer/
cp * /mnt/usb
sync

That's really all there is to it for the USB part. Once syncing is done, just plug the USB stick on the sheevaplug.

Then, log on the sheeva with the serial console, and reboot it. When you see the prompt "Hit any key to stop autoboot:" press a key. Now that the plug is in idle state, we'll start by re-flashing the U-Boot using openocd, which is definitely something you want to know how to do in case of trouble. Please note that, as shown below, you MUST launch openocd from the directory where your uboot.bin image is located. Also note that the flashing itself takes about 2-3 minutes, during which NOTHING will happen in the openocd console, so be patient.

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

Then from another Linux terminal

# telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>  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
> sheevaplug_reflash_uboot
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
NAND flash device 'NAND 512MiB 3,3V 8-bit' found
erased blocks 0 to 5 on NAND flash device #0 'NAND 512MiB 3,3V 8-bit'
[!!!! THE 2-3 MINUTES PAUSE HAPPENS HERE - BE PATIENT!!!!]
wrote file uboot.bin to NAND flash 0 up to offset 0x00074000 in 217.873932s
>

After that, the plug will reboot (into the new U-Boot), so make sure you have your serial console still running. The upgraded U-Boot should still let you boot the old factory installed Ubuntu Linux, so you might wanna check that everything's copacetic.

So far so good? Alright then, let's move to the next stage and flash that up to date Linux image.
This time we're not gonna use openocd but the flashing capabilities of the U-Boot, so you can "shutdown" (i.e. exit) openocd if not already done.

Once again, you need to reset the plug & interrupt the boot process to get to the Marvel>> prompt. There, we will install the new Ubuntu image by using the various commands from the U-Boot environment.
Three points that you need to know before starting this procedure:

1. Please note that it is necessary to boot the RAM image at the end to setup the NAND filesystem. Failure to do so will result in an unbootable Linux image, but this can be rectified by reloading the USB images and issuing the last command listed.
   
2. It is also a good idea, before you start this whole procedure, to spare a copy of your environment variables, which you'll get with the command 'printenv', as we're going to modify/create some of those. This way you should be able to revert back to your old environment if anything happens
3. The initial setup of the Linux image requires access to the USB stick, so make sure you leave it plugged in.

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 uImage
reading uImage
...............................................................................................................................................................................................................................................................

2620504 bytes read
Marvell>> fatload usb 0 0x01100000 initrd
reading initrd
.....................................................................................................................................................................................................................................................................................................................................

3331626 bytes read
Marvell>> nand erase clean 0x00100000 0x00400000;

NAND erase: device 0 offset 0x100000, size 0x400000
Erasing at 0x4e0000 -- 100% complete. Cleanmarker written at 0x4e0000.
OK
Marvell>> nand write.e 0x00800000 0x00100000 0x00400000

NAND write: device 0 offset 0x100000, size 0x400000

Writing data at 0x4ff800 -- 100% complete.
 4194304 bytes written: OK
Marvell>> setenv mainlineLinux yes
Marvell>> setenv arcNumber 2097
Marvell>> setenv bootargs_root ubi.mtd=1 root=ubi0:rootfs rootfstype=ubifs
Marvell>> setenv mtdpartitions mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
Marvell>> setenv bootargs_console console=ttyS0,115200
Marvell>> setenv bootargs $(bootargs_console) $(mtdpartitions) $(bootargs_root)
Marvell>> saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
Marvell>> setenv bootargs $(bootargs_console) $(mtdpartitions) root=/dev/ram0 rw ramdisk=0x01100000,8M install_type=nand; bootm 0x00800000 0x01100000

Now, because of the "bootm" command after the semicolon, this last command will make the plug boot automatically into the Linux copy in RAM, which needs to be done at least once to setup your initial system on the NAND. If all is well, this one time Linux installer will run & setup your system, restart the plug, and you'll get the new Ubuntu 9.04 booting which you'll find is A LOT faster than the factory one!

Next, we'll see how to recompile and install a vanilla kernel to boot the new distro.

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.

1. 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


2. • 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

3. 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
   
   
4. 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)

5. 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.
   
   
6. 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)

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.

Watching the Daily Show if you're not in the US

Well, it finally happened. Daily video streaming for the last episode of the "The Daily Show" is no longer available from the Republic Of Ireland (was working fine 'till yesterday).

The solution:

• Get a VPS, private server, whatever box in the US with enough bandwidth and an ssh server
  
• Using putty add the following tunnel:
  - source port: 80
  - Destination: media.mtvnservices.com:80
• Edit your C:\Windows\System32\drivers\etc\hosts file and add the line:
  127.0.0.1 media.mtvnservices.com
• Establish an ssh connection, and then open a browser to www.thedailyshow.com

"No soup for you"? Yeah, I'd like to see you try!

SheevaPlug - Let's get cracking!

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

1. 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!
   
   
2. 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.
   
   
3. 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.
   
   
4. 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!
   
   
5. 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.
   
   
6. "-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.
   
   
7. 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

• That very well done removable socket/cord plug concealer

From SheevaPlug

• Opening the plug (just remove the rubber pads to find the screws)
  

From SheevaPlug

• Mainboard - top

From SheevaPlug

• Mainboard - underside, with heatsink

From SheevaPlug

• Mainboard - underside, without heatsink

From SheevaPlug

• The device in action

From SheevaPlug

LILO Warning: The initial RAM disk is too big

Just re-installed Slackware 13.0 x64 on the HTPC, this time using a small boot partition on the extra non fakeRAIDed HDD, which I recently added to the whole rig. This 4th HDD is now the boot disk for the whole rig, and contains the kernel and initrd (while the Linux partition itself is on the RAID5 set).

Install went without much of a hitch, and even the first few kernel recompilations we fine, but lately, after adding more kernel features, I got the following LILO warning and the kernel simply doesn't boot:

    Warning: The initial RAM disk is too big to fit between the kernel and
   the 15M-16M memory hole.  It will be loaded in the highest memory as
   though the configuration file specified "large-memory" and it will
   be assumed that the BIOS supports memory moves above 16M.

So much for checking the "Optimizing for size" kernel option.

The root of the matter seems to be that uncompressed kernel + uncompressed initrd must fit within the 0-15 MB low memory addresses, and it looks like a bzipped 4.5 MB kernel + a gzipped 1.4 MB initrd don't cut it, regardless of whether your BIOS has set a hole for the 15M-16M range.

Unlike what you might read elsewhere ("Remove options from your kernel to reduce its size! / Why are you using such a huge kernel?" - how's that helpful, guys?), there is a solution right there in the kernel conf, through the "General Setup -> Initramfs source file(s)" option.
Somehow when you do that, the kernel is able to find all the RAM it needs for the initrd.

Now, I'll grant you that this makes it less convenient to modify your initrd options on the fly, yet I believe this is better than being restricted in your choice of kernel features. Plus it appears that the kernel boots a little bit faster when using the emebedded initrd.

Of course, that means that you need to create your uncompressed cpio archive from your initrd-tree before you can point to it, which can easily be done as follows:

cd /boot/initrd-tree
find . | cpio -H newc -o > ../initrd.cpio