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:
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)
My development set up is fairly simple:
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.
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.
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.
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*
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