Logo

Wyse 3125SE: Development 


Home


Summary


10Zig

Axel

Compaq

DT Research

Thintune

Futro

HP

IGEL

NComputing

NEC

Neoware

NetVoyager

Optoma

QLXpro

Relisys

VXL

Wyse

WT1200LE

WT3125SE

WT3150SE

WT3235LE

WT3630LE

WT941GXL

WT9450XE

WT9650XE

SX0

VX0

Xn0L

General Points

I have not yet got the video to work on the WT3125SE - the screen remains blank once the Linux kernel loads. This is no great hardship as the WT3125SE does have a serial port. A keyboard is required as you'll need this to invoke the NetXfer protocol at some point by hitting the 'p' key on power up. Having a screen attached is useful for feedback that NetXfer is running, but, at a pinch, you could manage without.

The DHCP server on my local LAN is embedded in the Netgear router that provides the interface to the outside world. All it does is serve up IP addresses and can't be configured to do anything else. I've set it to use addresses in the range 192.168.10.2-192.168.10.99 so that I'm free to use addresses from .100 upwards without fear of any conflict.

To get Linux running on the WT3125SE we need:

  1. A computer to act as a development machine.
  2. The kernel source files.
  3. An initrd to go with the above.
  4. An original Wyse WT3125SE firmware file.
  5. A compiler to build a custom kernel.
  6. Software to package up the kernel/initrd.
  7. A DHCP server/SFTP server to download files to the WT3125SE

For [1] I use an old Shuttle computer with a dual core processor running Fedora Core 16.
For [2] & [3] I use the Tiny Core Linux distribution.
[4] can be downloaded from Wyse's site.
[5] & [7] can be downloaded and installed on your development machine from that distributions app repository.
For [6] I've written a program that greatly simplifies this task. (It's downloadable from this site)

Hardware setup

My development set up is fairly simple:

Wyse WT3125SE development setup

The WT3125SE (with attached screen and keyboard) is connected to my local LAN. Also sitting on the LAN is my development system - a Shuttle computer currently running Fedora Core 16. The COM ports of these two machines are also connected by an original 'laplink' cable. (Showing my age here!). You can find 'null modem' cables on ebay for a couple of pounds - make sure that they are 'null modem' cables as some of the female-to-female cables on offer are wired straight through and are intended for use as cable extenders/gender changers.

The serial connection is not essential but is highly recommended for use in the early stages of your kernel development cycle. Whilst you can configure the kernel to send debug messages over the LAN by using the 'Netconsole' feature, these messages only appear once the ethernet interface is up and running. If things go wrong before that point you see nothing - which provides zero help in finding the problem! Also you may need to sort out problems with the initialisation scripts that bring the system up. Again, without a console you'll be in trouble. At one point (when I had no working console) I ended up adding a printk statement in the execve system call so that I could track the sequence of commands that init was running.

Configuration

As a minimum you'll need to download and install a DHCP server, an SFTP server and a compiler. I also downloaded and installed a communications program to use with the serial port. Whilst I used CuteCom to start off with I found it much more convenient to use Putty, the source of which can be downloaded from here. (Putty does support direct connection to a COM port as well as the more usual network connections). Unlike Putty, CuteCom is not a terminal emulator. This means the display gets a bit messy when the initialisation scripts run and spit out the various escape sequences that change the colour of the font. Putty acts as a proper console.

For the development work I've created a user 'thin' and do my development work under this user id. In thin's root directory I've created a bin directory for tools that I use such as makebootp and odd script files that make life easier.

One nice thing with the WT3125SE is that, if you use the 'p' key to invoke NetXfer, it looks on the non-standard port of 10069 for the DHCP server. This means that we can connect the development machine and the WT3125SE to the LAN without disrupting normal service - there's no need for a dedicated LAN.

We need to configure the DHCP server and the SFTP server. As part of this we need to embed our servers's IP address in the DHCP's configuration file. (The DHCP server tells the WT3125SE where to find the SFTP server). However my development machine is assigned an address by the local DHCP server every time its powered on. Whilst it always seems to be assigned the same address there is always a chance that it may change. Previously I addressed the problem by running the machine with a fixed IP address. This time I've written a script that puts the right address in the DHCP's configuration file.

One final issue with Fedora is that, by default, the permissions on the serial port are such that it cannot be opened by 'thin'. One more line in the startup script fixes this.

DHCP

By default the DHCP server uses the configuration file /etc/dhcpd.conf. I edited this to:

# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

default-lease-time 120;
max-lease-time 120;
server-name "hammerhead";
option domain-name-servers 192.168.10.1;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# This is a very basic subnet declaration.

subnet 192.168.10.0 netmask 255.255.255.0 {
 local-port 10067;
 range dynamic-bootp 192.168.10.200 192.168.10.240;
 option routers 192.168.10.1;
 filename "bootp.bin";
 next-server 192.168.10.20;
}

(hammerhead is the name of my Linux box). As the Netgear router doesn't recognise hammerhead as a local host we add the actual IP address in the next-server configuration field.

TFTP Server

The TFTP daemon normally runs under xinetd, but when I tried this I found I was unable to specify the ports that it uses without editing the system file /etc/services which I preferred to leave untouched. The -a switch only seems to work in conjunction with the -l switch (run a local copy) so I gave up the idea of having it started via the standard services and xinetd.

Starting the servers

I use a very simple script which lacks the sophistication of the netxfer.sh from Karl Mowatt-Wilson. Mine is just:

#!/bin/sh
#
# Script to start our NetXfer server
#

# For this to work we need to be root

if [[ $UID -ne 0 ]]; then
    echo "$0 must be run as root"
    exit 1
fi

# As we're running with an IP address handed out by the DHCP server
# we need to ensure that the correct IP address is set in our
# dhcpd.conf file.

# First determine what IP address we've been given.

IP=`ifconfig`
IP=${IP#*inet addr:}
IP=${IP%% *}
echo $hostname ip address is: $IP

# Update the DHCP configuration file to reflect this address

sed -i -e "/next-server/s/[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+/$IP/" /etc/dhcp/dhcpd.conf

#start the servers

dhcpd -p 10067
/usr/sbin/in.tftpd -l -a:10069 -s /home/thin/ftp

# We also need to access the serial port

chmod 666 /dev/ttyS*

Firewall

You either love them or hate them. If you have one in place then remember to open up the ports for the services you are using. In my case I ensured ssh was enabled and added under 'other ports':
10067 udp
10069 udp
6666 udp

The first two are for the DHCP/SFTP whilst the last is for netconsole should you use it.

 


Any comments? email me. Last update January 2012