The unit is completely dead. Reset button doesn't work. I think I erased u-boot.

I've installed Ubuntu to a regular computer and did steps form your instruction.

I've got all requierd files installed:
root@stockalerts:/usr/local/lib# ls /usr/lib/libftd2xx.so*
Config.txt  ftd2xx.cfg  libftd2xx0.4.16      libftd2xx.so.0.4.16  libusb-0.1.12  readme.dat  static_lib
faq.txt     ftd2xx.h    libftd2xx.so.0.4.12  lib_table            object         sample      WinTypes.h


Everything went well until I've got some errors:

after adding "none /proc/bus/usb usbdevfs defaults,mode=0666 0 0 " to /etc/fasttab I've got
root@stockalerts:~# mount -a
mount: unknown filesystem type 'usbdevfs'

And:
root@stockalerts:/usr/local/lib# /usr/lib/libftd2xx.so -> /usr/lib/libftd2xx.so.0
-bash: /usr/lib/libftd2xx.so: is a directory


Please advice.

Where would I do that?
Do I have to use another computer or my Sheeva plug.
I can't connect the Sheeva plug using serial port terminal anymore.
Do you have any Windows application that would upload the new firmware or u-boot image or maybe I can use an USB or CD card to boot form it?

Stages information

Here's some information about the stages.

    * Architecture: arm
    * Subarchitecture: armv5tel
    * CHOST: armv5tel-softfloat-linux-gnueabi
    * Profile: default/linux/arm/2008.0

We'll be using the new EABI, also called gnueabi, instead of the old ABI. That is armel on Debian. There's no exact reason for why we should use this EABI and not the old one, apart that this one is better than the old.

Therefore, we need an armv5tel-softfloat-linux-gnueabi stage3, available under the releases/arm/autobuilds directory in your favourite mirror

Well... OK.  Those are probably caused by a lack of proper OOB
information.  Since your device has u-Boot actually booting the device
then the data in there is still fine.

To "fix" this, you could use the following commands:

[some commands removed for your safety]

and then Linux will be happy with 'cat /dev/mtdblock0 > /dev/null'.
Problem is that u-Boot becomes unhappy and ignores its env variable area
which is located at offset 0xa0000. If you set your u-Boot env variables
again and save them then it's Linux that becomes unhappy for data from
offset 0xa0000 again.

Trying to have u-Boot write itself with the bubt command in the hope
that the whole partition would have the same OOB data format all across
doesn't work any better as Linux then complains about errors right from
offset 0.  So I doubt the issue is specific to the SheevaPlug at this
point.