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.
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:
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:
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.
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:
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.
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:
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.
"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.".
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.
Any comments? email me. Last update April 2010