I've got a netvista thinclient serving as jukebox in my bedroom. Recently I wanted to switch to a faster wireless adapter, which required moving to the 2.6 kernel series. This is especially painful for the netvistas, but nevertheless possible (despite some sources claiming that it won't work). Here's the rundown.

Netvistas are odd creatures: the bios loader understands ext2 but not compressed kernels, and only ELF objects with a program header count of 1. The hardware doesn't have a real time clock, and no text mode: a framebuffer console is a must. With 2.2 and 2.4 kernels, the netvistas can get relevant command line info from the bios/loader; but the bios doesn't know how to feed this to a 2.6 kernel, causing additional problems. Furthermore, the volatility of the kernel structures and APIs between 2.6.14- and 2.6.20+ makes life interesting: most stuff for kernels before .20 fails with newer ones and vice versa. (The folks responsible for this huge set of changes in the supposedly stable kernel series will be the first against the wall when the revolution comes.)

Here is the list of things required to get a stock 2.6.24.3 kernel to work:

• Patch the sources: look mum, no clock!
  No hardware clock means trying to set it is doomed. Normally you either live with 1.1.1943 or use ntp. The kernel calls update_persistent_clock() a lot when you use ntp, and this messes up syslog etc. Patch nr. 1 comments the one relevant line.

• Patch the sources: <NULL> as root dev
  On 2.6 I couldn't get any suitable kernel command line from the bios, which means the thing panics on boot, complaining about NULL not being a valid root device. Not surprising at all. However, the stupid loader not understanding anything but raw, uncompressed ELF kernels means that the usual "clean" way of presetting the kernel command line (using rdev on the bootable kernel binary) is out.

  A potential fix I read about somewhere is to use an initrd (I hate these), but I went for Brute Force and Ignorance: my netvista kernel always boots from the CF card, so I simply created patch nr. 2, which sets /dev/hda1 as bootdev.

• Configure the kernel suitably
  The kernel config must include the Geode GX1 framebuffer console, apparently must not include the VESA framebuffer (which worked fine on 2.4, but doesn't boot now), and should not include the CS5530 ide driver (because that tries DMA but DMA for disks is fucked with that particular Cyrix chipset). Here is my latest config which works (but might not be optimal).

• Build it
  make vmlinux is what you'd expect to use if you have built 2.4 for a Netvista before. Well, not quite. That make target is fine, but do not use ...whereever your kernel is.../vmlinux, that one won't boot (I don't know why). You must instead use ...whereever.../arch/x86/boot/compressed/vmlinux (on 2.6.22+, with earlier kernels the correct file is ...whereever.../arch/i386/boot/compressed/vmlinux). That kernel file is relatively small, 1.2Mb in my case.

• Patch the Binary!
  Now this is where things get really really ugly. Citing this explanation:

  The Netvista loads an elf-file directly. The elf-file has some information in the header of the file. There is a section called "Program Header". Here is describeed where in the file the exeutable code starts and other things. There is also a count which says how much of these entries are there. In the Linux-kernel programm-headers other than the first are only for misc. description and not really needed to load the kernel. The problem is that the netvista can't handle more than one entry even if the first is the right one. A simple changing of the count to one helps. This count sits at offset 0x2c of the file.

  I used hexl, some people have cobbled up their own "patchers" in

• Install and Enjoy.
  As always, the kernel must be stored as /kernel.2x00 on the Netvista's root partition. Don't forget to copy the modules (if any) to your netvista. Hand a suitable env var INSTALL_MOD_PATH to make modules_install if you cross-compile.

There is one problem I haven't been able to fix yet: the MPD and the LCDd step on each other's toes, load avg goes through the roof and music playback skips iff the LCDd has many screen updates (ie. more than two scrolling lines at a time). This sucks very very badly, especially as this very software combo (same versions etc.) worked fine on 2.4.35 (even with the extra overhead of nfs over openvpn over wifi, which I've eliminated in favour of wired ether). Somewhere there must be a tweak to get this to work properly; SCHED_RR doesn't seem to help (it messes things up even worse, at least in the experiments I've conducted so far). But that's a comparatively minor problem.

My list of netvista-related resources:

• Berlios Linux 2200: good info sets but the distro is horrible
• Linux 2.4 on the Netvista: good info but outdated
• Selfservix Kernel and Distro: some links
• Dennis Dingeldein: nice set of infos in German re recent kernels on netvistas
• how to build a 2.6 kernel with built-in initrd
• This claims that the stock kernel cannot be used, ever, and suggests a truly horrible workaround. Included for completeness' sake only.
• Puspus, a small debian-derived distro for the netvista. Site seems to come and go, but infos and software are quite useful.

I just heard that Antonio Cardoso Martin has been more successful wrt sound latency issues by running a kernel with real-time options on his netvista.