Anyway, whilst adjusting the BIOS settings for the LCD panel I managed to set them to something which meant that neither the LCD panel nor the external VGA would display anything. Since both displays were dead during boot up and since I hadn't made a note of the key presses required to navigate the BIOS screens to undo the change I was in a bit of a bind; the device booted OK and I could continue to work on is using a telnet session.

Since neither option was 'easy' I bounced between the two as problems came up. The first thing I did was install a pre-built version of dillo on my dev box from an rpm. I figured I'd put the executable and the dynamic libs that it needed on the target machine and see what happened. That's when I was introduced to the wonderful world of 'different versions of libc'... This is much more like DLL hell than the rpm problem I had last week ;) Due to the wonders of dynamic linking most things directly, or indirectly, rely on a dynamicly linked version of the c runtime library, libc. Of course, everything that a program links to that links with libc has to agree on the same version of libc... My pre-built version of dillo for Fedora Core 4 was linked with a different version of libc to the version that's available on the target machine... To follow the advice that James Antill gave in his comment to my earlier post I'd need to find a prebuilt version of dillo for the correct version of libc...

I briefly considered going back to building my own version from source and decided against it, for now, instead I grabbed the Fedora Core 1 ISO images and installed them in a virtual machine. Fedora Core 1 uses the same version of libc that my target device does... Around this time I realised that even though my target device is x86 Linux and my development box is x86 Linux I'm still, effectively, cross-compiling - I expect there's a better way to do this than the way I'm currently doing it but we need a proof of concept by the end of the week and right now the 'hack around the problems' approach appears to be working well enough.

So, whilst I kicked off the Fedora 1 download I took a look at Pixil's Viewml browser. This had the, by now, standard list of prerequisites to be downloaded and built. They all built fine and then the pixil stuff failed because it didn't like my version of GCC. Now, call me old fashioned but I like an OS where, if you need two versions of a compiler, you can just install one version in one place and one version in another. I've been working with Microsoft's Visual Studio like that since they brought out the .Net ones... I've had all versions of Visual Studio installed since they came out and I compile my code with most of them on a regular basis. It doesn't seem quite so simple on Linux... Of course I haven't investigated it fully but... Well, it failed the 'Nike' test... I couldn't 'just do it'...

The Pixil code didn't compile because my newer compiler was stricter than the one they'd used. I did some web searches and found their newsgroup. I found some patches but not a full set. They spoke of making a set of patches available; that was in October. They didn't seem to have done so. That was pretty much enough of a reason for me to drop that particular piece of software from our evaluation. File it in the 'not really as active as we'd like' bin.

So it was back to Dillo. By now I'd downloaded and installed Fedora 1, found that there wasn't an RPM for Fedora 1 (or if there was one, failed to find it), grabbed the source and built it. It ran fine on my VMWare box but of course that had all the requirements installed. Requirement number 0 was X11...

After a while I'd managed to work out that I needed a minimal X11 system on the device. I'd downloaded some prebuilt binaries and started to do a trial and error thing to copy just the bits I needed onto the device. More of my unix heritage was coming back; ldd is your friend, as is the log file that the X server creates... After a little while I realised that a couple of the crashes I was getting could possibly be due to the fact that the binaries were not necessarily built JUST for the i386... I wasn't 100% sure but I pulled down the sources, adjusted the compiler flags and made sure that I built a version with a makefile that knew I wanted it to work on a real 386. I then did the same for the browser itself.

Time passes...

By the end of yesterday I got to the point where I had the basic X background and cursor briefly appearing as xinit ran the browser on the device and then something horrible happened to the display and things died. At this point we pulled the plug until we either get new hardware with a supported display driver or the manufacturer of our existing hardware comes up with a working driver...

The whole experience was fun. I learned a lot. I remembered a lot and I realised why Linux and Open Source appeal to hackers. There are just so many problems to solve. And, after all, the fun is in solving the problems...

I booted into the new kernel on the Vortex86 and it recognised the graphics card. Unfortunately it didn't display correctly in graphics mode.

After much reading of Dr. Thomas Winischhofer's pages on the SiS drivers and much experimentation I'd managed to get graphics to display correctly on an external monitor but had no luck with the LCD panel. I'd fired off some questions to our board supplier and the manufacturer earlier in the day but had got not reply so I figured I'd done enough to be able to ask Dr. Winischhofer some questions about my problem.

Thomas responded pretty quickly and confirmed what I'd begun to fear. It was the graphics card and LCD panel combo that was the problem and at present there's no support for this combo in the current Linux driver sources. Thomas is prepared to do the work if my client is prepared to pay him so I guess I'll have to wait and see what happens.

My next posting about the Vortex86 could be related to installing Windows CE or XP embedded on it as the LCD is supposed to be supported under those OS's...

So now I was in a position to overwrite the hard disk on the Vortex86 with the new ghost image, only that's not how I work ;) Since trashing the disk on the Vortex86 would delay the project by a while I decided to test load the image onto a VMWare machine first... Please wait whilst more boot disks are made and tested...

By this point I'm fairly fed up with things that boot from floppy disks. It takes SO long. During one of the reboots I googled around and found this, WinImage, a program that can create an image file from a floppy (and much more) so that VMWare can boot from a nice fast floppy image rather than a real floppy drive... So I boot the VMWare box from the floppy image, connect to my domain controller, install the ghost image and reboot. It crashes because the kernel doesn't know about SCSI disks and the VMWare default was to make its hard disk a SCSI one... One new VMWare box later and I'm booting into X-Linux R53 under VMWare... Whilst this isn't going to help me a great deal as I need to get the new kernel working with real hardware that I can't emulate in VMWare at least it will speed up the initial games with LILO and booting into the new kernel, etc.

Once I was comfortable that I had all the tools in place I booted the Vortex86 and ghosted the new image onto it, rebooted and everything worked fine.

Fedora installed nicely onto the virtual machine and so far I'm quite impressed. I especially like the way you can run as a normal user and whenever you need to do something that requires root privs it simpy prompts you for the root password and then displays a little warning icon to remind you of the extra power that you have... Why doesn't windows do that ? ;)

Next on the list was grabbing the appropriate kernel sources. The version of X-Linux that's actually on the PC at present is this one (r52) which is based on the 2.4.28 kernel. However r53 has just come out and I'll be upgrading the device to that as soon as I get my floppy cable... R53 is based on 2.4.31 and to enable graphics support I need to rebuild the kernel after setting the appropriate config options. I've decided that the R52 -> R53 upgrade is my first priority as the manufacturer is bound to tell me to upgrade as soon as I have any problems, so I might as well do it now. What's more R53 uses Lilo as the boot loader and I'm more familar with that then the SYSLINUX loader used in R52, I'll need to have the PC boot into various kernel configs so I'd prefer to be using a loader that I'm used to...

Tech support from the manufacturer implies that the graphics support for the correct chipset (SiS 550)is available as standard in the 2.6.3 kernel and they're a bit vague about support in 2.4.28 and 2.4.31. So I grabbed all three versions of the kernel source from here with the the intention of first trying 2.4.31.

The manufacturer supplies the kernel .config file, so after finding this page, I did what it said and kicked off a build with the same settings that were used for R53.

Of course the build failed with a compile error that moaned about an incomplete array... I checked the source and found an array that used NR_CPUS... A quick google for NR_CPUS 2.4.31 took me here and I downloaded the patches for 2.4.31 and gcc 4.x that were listed here.

The build has just completed, so I guess it must be time to check my mail and see if the floppy drive cable has arrived...