Evo T20 Thin Client firmware

Introduction

This section covers various salient elements of the Evo Firmware and the way in which it behaves. The starting point is that in its "Legacy Free" state the T20 doesn't have a standard PC BIOS. On power up it will only boot the embedded operating system from it's flash memory so there is no "just plug in a USB memory stick with a bootable version of Linux and you're away" here.

Note: Some of the higher end models do offer network booting via PXE support, but my Windows CE based unit doesn't. The higher end T20's also have a larger BIOS chip to accommodate the extra functionality.

Caveat:What follows is based on my experience with a Windows CE/16MB flash system. There are some differences in the higher end (NTe/XPe versions) of the T20.

BIOS

When you start delving into the T20 firmware you soon discover that there are two BIOS files around: ulc_code.ce and ulc_code.bin.

The former (ulc_code.ce) is the one that is programmed into the on-board BIOS chip. This contains a simple ROM BIOS and which includes the NETXFER application (see below). You can verify that this is the file programmed in the BIOS chip by using the flashrom application from flashrom.org. This will dump the contents of the Winbond BIOS chip to a file and then you can compare it to the original to confirm this.

The latter file (ulc_code.bin) contains a more sophisticated BIOS and does NOT include the NETXFER code. I guess that has been elbowed out to make room for the additional functionality. The ulc_code.bin file is stored in the onboard 16MB flash along with all the WIndows CE files.

The power-up sequence for the T20 would appear to be:

ulc_code.ce in the ROM gets control and does some preliminary initialisation.
It checks for any P or Q key presses on the keyboard to see if it should invoke NETXFER. If either key is pressed it runs the NETXFER code and doesn't probe further.
If NETXFER hasn't been invoked it then checks that the flash memory is ok and complains and halts if it isn't.
If all is well it loads the ulc_code.bin file from flash and effectively uses that to replace itself.
Finally it boots Windows CE (loads and runs the file nk.bin).

From this behaviour we can see that there is a basic "get-out-of-jail free" mechanism (NETXFER) that can be invoked should the flash memory be corrupted or you want (or need) to install some new firmware. This downloads and executes recovery software from the network. In practice this reformats the flash and installs/reinstalls the Windows CE firmware and applications.

However, if everything is OK, the simple BIOS/NETXFER is dumped in favour of a fully functional BIOS before Windows CE is booted.

This gives us two ways in which we can get our own code to execute on the T20:

Package up our software so that NETXFER will download it and then execute it.
Replace the file nk.bin in a standard firmware bundle so that it's our code that runs rather than Windows CE.

I cover both these options elsewhere.

There is a subtle distinction between the two cases above. In the former case our code is running with the simple BIOS in place whilst in the latter case we have the extra functionality that is present in the ulc_code.bin variant.

NETXFER

screen shot This is really a very simple loading mechanism which is invoked by pressing the P key on the keyboard whilst the T20 is restarting. When the T20 recognises this the following happens:

The T20 puts out a request on the network to a DCHP server which should be listening on port 10067.
The DHCP server responds by allocating the T20 a network address and additionally supplies the address of a TFTP server along with a file name.
The T20 connects to the TFTP server on port 10069 and downloads the file to memory starting at address 0x100000.
The T20 then executes the code in that file.

It's as simple as that! The file format used is described in Draft Net Boot Image Proposal, various copies of which can be found on the Internet. The use of the high numbered non-standard ports means that we can use this mechanism on a LAN without disrupting any normal DHCP or TFTP services we may be using.

NETXFER.EXE is the name of the utility that HP/Compaq/Wyse supply to provide a packaged DHCP/TFTP server that runs in a Windows environment. I haven't bothered with it. As described here it is very easy to setup the required servers in a Linux environment.

Firmware File

The BIN file that HP/Compaq/Wyse provide basically consists of four sections:

The 512-byte header.
All the code necessary to:
- Access the T20's hardware and flash memory.
- The "flashing" application.
- Code to validate and extract the files from the fourth section (File Bundle).
A copy of the full BIOS (ulc_code.bin)
A "Bundle" of files to be written to flash memory.

A hint of what's in the file can be found in the download SP22454.EXE which can be found on HP's website. HP's description of SP22454 is:

"Utility - Tools, version: 2.18 A (9 Oct 2002), This contains the Netxfer tool for the Thin Client Evo models listed below. Netxfer is a utility program that allows the customer's IM services to replace the entire binary image stored in flash on an Evo T20 or T30 with a new image.".

Included in the pack is the utility img2UTC.exe and the batch file mkutc.bat. From this it would seem that Compaq referred to this file format as UTC.

There are set of tools available from here that allow you to extract files from a bundle and build new bundles incorporating your own replacement files.

For my T20 the basic Windows CE image would appear to be SP22459. This unpacks to the binary image U441_22_3CMe8.bin. The bundle in this image actually is a list of files:

This seems to be a NetXfer image, skipping the NetXfer bootstrap.
Offset    Size      Checksum  SysFlg  BiosFlag  Time      Filename
0000045b  00040000  b9eed2bc  010000  00010000  3bd086cd  ulc_code.ce
0004045b  00000014  fdf20bf9  010000  00020000  3bd086b2  k
0004046f  0000010d  116dc8fc  010000  00020000  3bd0869d  params.ini
0004057f  00370a17  17d838bb  010000  00020000  3bd086a9  nk.bin
003b0f97  00003728  24dc5849  010000  00020000  3bd08156  poweron.bmp
003b46bf  00040000  1128858a  010000  00020000  3bd0816c  ulc_code.bin
003f46bf  00001166  f7a34780  010000  00020000  3bd086ae  wsnmp.zip
003f5827  00030466  0865766f  010000  00020000  3bd083d1  WBTSetup.exe
00425c8f  0001ac66  8466cb6d  010000  00020000  3bd083d2  WBTWizrd.exe
004408f7  00002063  74929be3  010000  00020000  3bd083d4  RmRDP.dll
0044295b  00002263  544cd2fa  010000  00020000  3bd083d4  RmICA.dll
00444bbf  00002263  d52e67c3  010000  00020000  3bd083d4  RmTEC.dll
00446e23  00002462  f694708a  010000  00020000  3bd083d6  RmIE.dll
00449287  00000c7f  b4a02161  010000  00020000  3bd080e9  RmIE.ini
00449f07  00002066  9502d552  010000  00020000  3bd083d5  RmDIALUP.dll
0044bf6f  00000c67  a71ef87d  010000  00020000  3bd083d5  RmAIRONET.dll
0044cbd7  00000c68  ba6c3aaf  010000  00020000  3bd083d6  RmELOTOUCH.dll
0044d83f  00000a66  95327ca9  010000  00020000  3bd083d6  RmMTOUCH.dll
0044e2a7  00001668  9ad43d2f  010000  00020000  3bd083d6  RmSCRSAVER.dll
0044f90f  00000c65  657ad975  010000  00020000  3bd083d5  RmTRING.dll
00450577  00000c65  949f35d6  010000  00020000  3bd083d5  RmWVLAN.dll
004511df  00001666  c4a53a04  010000  00020000  3bd083d6  RmJETCET.dll
00452847  00000c66  06d4cead  010000  00020000  3bd083d3  Rmfloppy.dll
004534af  00000c63  d1f38b11  010000  00020000  3bd083d4  RmJVM.dll
00454113  00000e67  0fdc96c3  010000  00020000  3bd083d4  RmMPlayer.dll
00454f7b  00003184  f6ab4070  010000  00020000  3bd080e9  RmMPlayer.ini
004580ff  00002263  62f74ad0  010000  00020000  3bd083d5  RmVPN.dll
0045a363  00000a68  ea93058d  010000  00020000  3bd083d7  RmUSBModem.dll

With other models with larger flash chips (and hence more files) the bundle holds a complete image of each flash chip. In this case they are named FILESYS0.IMG, FILESYS1.IMG and FILESYS2.IMG. In these circumstances we use the Linux loop device to mount the and access the contents of the file system image.