I've used lighttpd in the past and it's ok and I would use it on the Sheeva except I'm more familiar with apache.  Fact is that even though it is starting to dip into the swap the response is still feels snappy.

(psst, you know that website I always mention, its running on the sheeva)

heh.

the disparity between reads and writes seems to only affect samba.  I clocked network file transfer performance for nfs and the read/write performance is about the same.  I have the numbers here:

http://computingplugs.com/index.php/SheevaPlug_Performance#Network_Performance

I went back and looked at the build process after Charles said that it could be build without hacking.  Found out he's right.  I pulled mythtv-0.21 from the source and did:

./configure --disable-dvb --cpu=armv5te
make
make install

and that was it.  I had to disable dvb because it gave me a version error, probably because I had the wrong version installed.  In anycase, the backend works great.  It is scheduling shows that the slave backend records.  Mythweb works also.

I checked my memory usage and the sheeva plug is actually dipping into the swap.  The 3 biggest memory hogs:  apache, mythbackend, mysql in that order.

Cross compiling has its advantages, but I would argue against cross compiling for something like mythtv because of all the libraries that it has to pull in during compile.  I mean, it is pretty easy to cross compile the kernel, you really only need the standard libraries, but when it is pulling in libX, libqt and all the child dependencies.  It becomes a huge chore to gather all the arm versions and then put them in the right place for the cross compiler to pick them up.  Well, I'd rather wait the 3.5 hours...

About qt4 vs qt3, the guys at myth is finally moving to qt4 for version 0.22.  But that's not released yet and I don't really like to build a moving target, so I stuck with 0.21.  Here's a burb about it on their website:

http://www.mythtv.org/wiki/QT4

I misspoke on my website, I meant to say that you can only have the qt3 development libraries install and not the qt4 development libraries.  You can have both qt3 and qt4 runtime libraries installed and it would be fine.  Problem with both development libraries installed is qmake, rightly so, picks the higher version development libraries to link against.  That causes the build to fail.

spend the weekend getting mythtv-0.21 compiled on the sheeva plug.  There was some hacking involved and I created a patch file you use to patch the source.  The patch file and instructions are here:

http://computingplugs.com/index.php/Compiling_Mythtv-0.21_on_the_Sheeva_Plug

After it compiled, I was able to run mythtv-setup and setup the backend.  I was able to create the database and fill it with mythfilldatabase.  I could connect to the plug's database from a separate frontend and could see all the listing information.

What I *did not* try was actually recording anything.  I don't have a usb tuner so I could not test that.  Although all indications is that it *should* work.  But please, if anyone has a usb tuner and is willing to spend some time trying it I would really love to hear the results.

The sheeva plug comes preinstall with the ubuntu jaunty file system and it will boot to prompt as soon as you plug it in.  However, the only service it has is ssh.  There are a number of ways to expand the plug's functionality, mostly just "apt-get <package>".

You can take a look at http://www.computingplugs.com/index.php/Main_Page to get you started.

The easiest way to get gcc on the sheeva plug is to "apt-get build-essential".  GCC is then installed and I had no problems building hello world on the plug.  Message back if you still have problems after apt-get'ting build-essential.

Problem is that all my passwords, settings, webpages, would be shared with everyone.  Probably not what I want.

Maybe it is possible to release an image that has the latest kernel and fixes to the default filesystem.  All other software pretty much is just an apt-get away.

I've changed the wiki to include the new steps, so hopfully it'll be more clear now.

So did you manage to get ext2 to work correctly?  I've just changed my sda1 partition to ext2 and documented how I did it.

I did a bunch of SDHC benchmarks with the stock kernel and the results were unimpressive.  8.4MB/s read and 1.7MB/s write.  Yesterday I compiled a new kernel from mainline 2.6.30-rc3 and patched it with the MMC patch.  I reran my test and the SDHC performance is MUCH better. 19.03MB read and 6.5MB writes.  The new numbers matched what I get when I run the same memory card on a fast machines.

I think Marvell should push out the new kernel as soon as possible, and perhaps provide a new jffs image that can be burned into the flash.

bfmorgan,

I will update the wiki so that the mtd mount points shown a bit more clear. 

As far as /dev/sda1.  I checked the kernel tree that came with the sheeva plug and saw that vfat and fat is NOT compiled in as part of the kernel but as a kernel module.  That would explain why it tries to insmod vfat.ko in rc.local.  The stupid thing is that fat.ko and vfat.ko that came with the filesystem does not work with the supplied kernel.

So, I guess it comes down to:

compile your own kernel and make sure vfat is compiled into the kernel instead of a module (this is what I did)
compile the kernel module to match the running kernel.
change /dev/sda1 so that it uses ext2 instead of vfat.  Ext2 is already available to the kernel.  Running ext2 is not a bad idea considering what happened to tomtom.
boot the kernel from NAND flash, and boot the filesystem from /dev/sda2.

That's a lot of choices, I would *like* to add them all to the wiki but will definitely take some time.....

I suggest rTorrent as well.  It is console base, which I like and very light weight.  It will do everything GUI base torrents do and a bit extra.

Here's a good way to start rTorrent, put this in your cron jobs
@reboot screen -dms torrent rtorrent

That will create a screen session name "torrent" at every boot.  Then, if you want to look at and see what rTorrent is doing, type

screen -r

Its great.

I've got a set of performance and power usage numbers here:

http://www.computingplugs.com/index.php/SheevaPlug_Performance

It has cpu nbench performance, usb throughput, sdhc throughput, network performance and power usage under various conditions.

be careful with the rc.local.  If you look a little higher in the file you'd see

insmod fat.ko
insmod vfat.ko

Then if you look at the serial output when the kernel boots, it complains that those modules cannot be loaded and the system stops processing the rest of rc.local.  So if you comment out those insmod lines, the system clock will be set to Jan 26, 2009.

I just removed the entire rc.local and used ntp.  The clocks on my sheeva plug is working fine.

Is there a hardware watchdog that could be enabled by U-Boot?  I find that I could hang the sheeva plug with a bad kernel image or filesystem.  A hardware watchdog would be a great help if you do remote development.