Winterm S10 thin client

Back to homepage

This is mostly my notes from messing around with this AMD/NSC Geode based thin client. They may be incomplete, or not make up a logical whole in some places. I will try to edit some of it to make it useful.

I have tried to boot some operating systems, in the end installed NetBSD/i386 8.0. I was able to run FreeDOS, Linux 2.4 and OpenBSD on it.

Winterm S10 board revision A1. They are stackable with standoffs!

Some time ago I made a video about booting linux with loadlin and DOS on them, I was booting that on the newer revision B4. That revision refuses to boot any medium bigger than 2GB

6 Jan 2019 - Installing an OS

Winterm s10 is a WYSE thin client. Internally runs a custom operating system that looks and feels like a Windows-based thing. It has an AMD Geode 366Mhz CPU and my units came with a 128MB 2.5V 333Mhz DDR1 SO-DIMM ram stick.

I have five of them, 3 have a gray chassis and 2 white. The gray chassis ones have the A1 board revision in them and the white ones, revision B4. Bios in both rev A1 board and rev B4 board that I have been playing with is version 1.14, build date 04/23/2006.

Winterm s10 can boot of a usb-sdcard reader, revision A1 boots media without problems, revision B4 seems to ignore media bigger than 2GiB.

Both revisions of the motherboard feature a 44 pin, 2.5'' IDE connector. I'm using an IDE to CF card converter that works fine. If you are using a right angle converter then you have to select one where the IDE key pin is faced to the edge of the PCB, as converters the other way around don't fit unless you remove the board from the chassis and desolder and attach the pc speaker with a pair of wires.

Booting my rev A1 board is quite weird as for some reason the system won't react to the power button being pressed, instead I connect the DC jack, wait for the orange led to go off and strike the Del key. This brings up the BIOS menu. BIOS password is "Fireport" and cannot be disabled, only changed. Maybe you can set it empty, did not try this.

The above problem can be solved by setting "Power Control: Always On", this way the unit starts whenever there is power connected.

NetBSD/i386 8.0 booted from a USB SD card reader. The image written to the SD card was the install.img file.

Using default options it hangs on a message about pckbc0. Disabling that device helps, to do that press 4 at boot menu and type "boot -c", this will drop you to userconf(4) after the kernel loads, where you disable the AT keyboard controller with "disable pckbc0". This allows you to boot the kernel and get into systinst(8). At first i went too far and disabled whole ISA bus but that caused the system to not see my CF card!

If you are disabling or otherwise need to edit boot options or userconf, the system has you covered as you can put the boot command line in /boot.cfg file. In my case the line is:

      "userconf disable pckbc0; boot netbsd"

With pckbc0 disabled the system has successfully booted up and I was greeted by the white-on-blue menu of sysinst(8). Apart from that pckbc0 quirk, it is a typical NetBSD/i386 installation.

At first i messed up the partition scheme. Reinstalled it with a good partition scheme. Works

7 Jan 2019 - Hardware

DC jumper
There is an unpopulated jumper on rev A1, designation JDC1. Its directly connected to the DC jack and can be used to provide 12VDC power to the board. Located top right, board oriented ports up, ram right. Designation is hidden under the ram stick. Pinout as follows: Upper pin (closer to mouting hole) - 12VDC, lower pin is GND. I've soldered 12V and GND cables from a female molex connector, this way I'm able to power if off an ATX psu. It's a good idea to tie it to the mounting hole with a ziptie for strain relief :)

GPIO devices and other unpopulated connectors
The chipset chip U3, ("Companion device"), AMD Geode CS5536AD has some GPIO devices that NetBSD is able to pick up and assign /dev/gpio0 to this port. Those do not seem to be broken out on any jumper on the board but board revision A1 has got a lot of vias under the chip and it should be possible to probe or connect a jumper wire to one of the vias. The silkscreen printing carries a very nice legend that helps identifying the correct ball. This chip is very interesting because it controls a bunch of low level stuff. Some of them include boot option select, and SMBus (G3 - CLK, F1 - I/O), and UART/IRDA 1 and 2

CS5536AD datasheet is available online, ball assignments page 25 onwards.

Other jumpers and interesting points include (board rev A1):

BT1 - Top pin connected to Vbat [A3], bottom to GND (board orientation the same as in point 1).
Vbat pin is described as "RTC battery". Chapter 7.1.4 of the datasheet shows voltage range from min 3.14 to max 3.46, typical 3.3 - according to the datasheet a simple CR2032 will not work!

JFS1 - some JTAG

rest of the jumpers unindentified. This is pretty difficult due to this being a multilayer board!

7 vias in a copper fill next to the big cap near power button, looks like -12V output from a DCDC.

Serial interface running on +/-9V, should work with everything.

Kernel stuff

I'm curious why the NetBSD kernel hangs on boot if pckbc0 is not disabled. The kernel boots fine if you compile it without pckbc, but that causes some other problems. For example no keyboard until the kernel initialized the USB devices, which leaves you without keyboard access for that time.

When I first installed NetBSD on it I managed to screw up the partition table (on i386 partition C and D is whole NetBSD MBR partition and whole disk respectively). I could not reproduce that screwup. It might have been something to do with OpenBSD being installed previously on that (but when OpenBSD froze on it's kernel relink stage for 30 minutes (this is a 366MHz Geode and a slow IDE interface, remember?) i just yanked the power cord and installed NetBSD on it).

So far I've managed to find the exact bus_space_write_1 call that hangs the CPU!

The kernel hangs when trying to write a value to IO port 0x64, which is the PS/2 command register.

The CS5536AD Companion Devive emulates a PS/2 keyboard controller. It maps I/O port writes to the right MSRs (Model Specific Registers - special registers in x86 based CPUs available with rdmsr and wrmsr instructions, since Pentium). IO ports 60h and 64h are mapped to allow BIOS and such to interface with the emulated PS/2 keyboard "the old way".

Furthermore, the kernel also hangs when using the serial console (albeit while trying to write a different value - 0x60 for VGA console and 0xAA for serial console

I'm trying to find the cause of that problem

Back to homepage