The Wyse Sx0 BIOS is a strange beast and it is difficult to fathom out exactly what it is up to. Every time I revisit the Sx0 range of thin clients I find that some of my earlier suppositions were possibly not correct. One thing that is guaranteed though is that it may well be a bit hit-and-miss in getting one to boot your version of Linux.
For experimentation I currently have available:
Using Tiny Core 4.7.6 my current findings are:
| early model -xx | Later model -xxL | |
|---|---|---|
| Loader | Tiny Core will not boot on the S30/S90 using syslinux as the loader. There is no problem with grub. | With syslinux the S10 will not boot from USB unless something is connected to the IDE interface. With nothing connected it enters an endless load-syslinux-and-then-reboot cycle. Using Grub you can boot from USB irrespective of whether anything is connected to the IDE interface. |
| Speed | The kernel/core loading speeds from USB are slow - they seem to be around USB 1.0 speeds despite them being USB2.0 ports. | The kernel/core loading speeds from USB are slow - they seem to be around USB 1.0 speeds despite them being USB2.0 ports. |
| IDE interface | out-of-the-box Tiny Core does not find the onboard flash on the S30 as it does not include the driver for the CS5535. At the time of writing the driver is marked as 'experimental' which is why it is not included in the standard build. | The BIOS marks the IDE interface as disabled - even if it has just booted from something attached to that interface. As a result anything connected to the IDE interface is not accessible. This applies to both USB and IDE booting. |
| Kernel initialisation | Tiny Core has no problems initialising everything and starting the GUI. | The kernel may well hang whilst finding the cs5536 during the PCI initialisation phase.
This happens if a timer interrupt occurs at the wrong moment. This can be fixed by patching the driver. [No longer necessary in the 4.2.9 kernel used in Tiny Core 7.2] |
| Media size | There maybe issues with large (>1GB) boot partitions. A 2GB pen drive with Grub installed hung after displaying the word GRUB. My standard 'test' pen drives - 1GB in size - are fine. | There maybe issues with large (>1GB) boot partitions. I've had problems with a 2GB Compact Flash card that just displayed the syslinux header and then hung. Repartitioning the compact flash so that the boot partition (sda1) was only 100MB fixed it. My standard 'test' pen drives - 1GB in size - are fine. |
Some of these are discussed in more detail below.
The syslinux loader does not appear to work at all with the older hardware.
With a newer S10 a USB drive prepared with Core2usb would not boot. There was a brief flash at the top of the screen of the syslinux opening line and then the S10 would reboot. This repeated forever. I now believe this to be an issue with the newer hardware with nothing connected to the IDE interface. i.e You'll get it with an unmodified S10 but shouldn't see this on an S30 or S50 unless you've removed the flash.
The fix is easy - use grub.
This didn't take long as there was some useful guidance here. It might be worth reading through the 'step 5' section of that article if you are uncertain about what exactly is being described below.
Briefly what I did, and what you need to do is:
default 0 timeout 10 title tinycore kernel /boot/vmlinuz kmap=qwerty/uk initrd /boot/core.gz
This worked perfectly on the older model. With the newer model it actually managed to boot once in a while but more often than not hung whilst the kernel was busy initialising everything.
When you have problems with Linux starting up it is often useful to see as many of the kernel messages on the screen that you can. When I tried adding the parameter vga=791 to the command line to get a 1024 x 768 display things just hung. I found that vga=788 for an 800 x 600 display worked. However the following day it didn't! The safest thing appears to be to leave it off unless it is essential that you increase the screen resolution whilst booting. If you do try it out, it looks like it is pot luck as to whether it will work or not.
[Update March 2014: This may have been sorted with the recent patch to the CS5536 driver]
To get some idea of where the problem lay I ended up adding ignore_loglevel to the command line. This produces a verbose output from the kernel and from this I could see that the kernel always ground to a halt whilst probing the CS5536 device.
........... pci 0000:00:0f.0: [1022:2090] type 0 class 0x000601 pci 0000:00:0f.0: reg 10: [io 0x6000-0x6007] pci 0000:00:0f.0: reg 14: [io 0x6100-0x61ff] pci 0000:00:0f.0: reg 18: [io 0x6200-0x623f] [Hangs here +/- a line or two]
Originally (May 2013) I played around with various command line switches and settled on pci=nobios as a way of reducing the incidence of the bug. Now (March 2014) I know the reason for this bug and how to get rid of it. (See below).
It looks like the S10 BIOS runs the IDE interface at USB1.0 speeds. The Tiny Core kernel (2.4MB) loads in ~12 seconds and the core.gz (5.1MB) in about ~23 seconds. So it takes ~35 seconds to load 7.5MB of data which is a throughput of ~220KB/s (1.8Mb/s).
With both models you will have problems if you use a boot partition that is >1GB. This is also true of any USB pen drive you are using. Large pen drives can be used if you partition them first in order to create a smaller boot partition.
The old hardware uses the CS5535 companion chip. The CS5535 driver is currently tagged as 'experimental' and is so excluded from the Tiny Core kernel. This means the internal flash drive on the S30, S50 or S90 can't be seen. This is easily fixed by recompiling the kernel and including the driver.
The new hardware uses the CS5536 companion chip. There are a couple of problems associated with it, both of which are documented more fully below.
[Feb 2017 revisit: Found first point to be fixed and patch is no longer needed - Linux Kernel 4.2.9 ]
The second point came to light when I revisited the S10 using Tiny Core 4.7.6 installed on a Compact Flash card connected to the IDE interface. When I booted it it stopped at the command prompt and did not go on to load the graphical desktop. I didn't notice this in my initial testing a few years previously as at that time the Tiny Core ram disk included the graphical interface. That is now split out and loaded from the physical disk after the basic system is running.
A quick check of the log file showed why there was no graphical desktop:
.... pata_amd 0000:00:0f.2: version 0.4.1 scsi0 : pata_amd scsi1 : pata_amd ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xeef0 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xeef8 irq 15 ata1: port disabled. ignoring. .... ata2: port disabled. ignoring. ....
Note: This is also true when booting from USB.
The latest kernel finds the IDE interface is disabled and so doesn't use it. As a result, when booting from a Compact Flash card on the IDE interface, the Compact Flash card disappears once the memory based kernel and core.gz files have been loaded and the tce directory with the GUI files vanishes with it.
Both these problems can be fixed with simple modifications to the pata_cs5336 driver and recompiling the kernel.
The process of recompiling the kernel is documented here and the results can be found under the TinyCore tab above.
Note: The following patches were made to the driver in the 3.8.13 kernel. There have been some changes to the driver code since my previous set of patches (3.0.21 kernel) and things may be slightly different again with a later kernel.
[Feb 2017 revisit: Found this to be fixed and patch is no longer needed - Linux Kernel 4.2.9 ]
I now know the reason for this behaviour. Back in June 2013 Karol pointed me at a posting in the kernel list about a problem with some MIPS hardware. I've only just got round to checking it out (March 2014!) and it turns out this does solve the start-up problem. In the words of Aaro Koskinen:
"Some Loongson boards (e.g. Lemote FuLoong mini-PC) use ISA/southbridge device (CS5536 general purpose timer) for the timer interrupt. It starts running early and is already enabled during the PCI configuration, during which there is a small window in pci_read_base() when the register access is temporarily disabled. If the timer interrupts at this point, the system will hang. Fix this by adding a fixup that keeps the register access always enabled."
The accompanying patch was applied to the driver that's in the MIPS architecture source tree. What we need to do is add the following code to the driver pata_cs5536.c that we're using which is in the directory drivers/ata/:
/*
* The mfgpt timer interrupt is running early, so we must keep the south bridge
* mmio always enabled. Otherwise we may race with the PCI configuration which
* may temporarily disable it. When that happens and the timer interrupt fires,
* we are not able to clear it and the system will hang.
*/
static void cs5536_isa_mmio_always_on(struct pci_dev *dev)
{
dev->mmio_always_on = 1;
}
DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA,
PCI_CLASS_BRIDGE_ISA, 8, cs5536_isa_mmio_always_on);
I added it at the start of the functions following all the #includes.
My thanks to Karol for pointing me at the fix - and my apologies to him for taking so long to do something about it. (My S10 based web server rarely gets rebooted).
This is a matter of adding some code to set a bit in one of the registers. I also took the approach of telling the driver to use the Machine Specific Registers (MSRs) rather than the pci interface registers.
At the start of the driver, immediately following the listing of the include files, you will find the declaration of the module interface. I set the default for the variable use_msr to 1. (It saves having to add the switch to the kernel command line). The file should now look like:
... #ifdef CONFIG_X86_32 #include <asm/msr.h> static int use_msr = 1; ...
Next locate the function cs5536_init_one() and change:
.....
if (use_msr)
printk(KERN_ERR DRV_NAME ": Using MSR regs instead of PCI\n");
.....
to read
.....
if (use_msr)
{
printk(KERN_ERR DRV_NAME ": Using MSR regs instead of PCI\n");
cs5536_write( dev, CFG, 0x00010002 );
cs5536_write( dev, DTC, 0x20200000 );
cs5536_write( dev, CAST, 0x20000000 );
cs5536_write( dev, ETC, 0x00000000 );
}
.....
For the purposes of checking things (and without any particular reason) I initialised the IDE interface for PIO mode 4. I also took the opportunity to set the bit in the configuration register to indicate an 80-way cable on the IDE interface. Without this the interface is limited to UDMA/33 whatever you may have plugged into it.