On powering up, after a delay whilst things are initialised, the FT01 displays a blue screen with the word 'loading' filling it. This is subsequently replaced by the running on-board firmware.
As well as the usual keys of DEL, F1, F2, F4, F10 I've tried every key on the keyboard and have still failed to interrupt the loading sequence and bring up a BIOS setup screen instead.....HELP!
Unless we can get to the BIOS settings I don't see how we can run any alternative software.
I found a posting from somebody who had a Compal FT01 stolen and then recovered a few months
later. It came back with a BIOS password set. He eventually fixed this by clearing the CMOS
which is backed up by a battery - BATT2. This is can be found just under the casing adjacent
to the RAM memory. Unfortunately the battery is soldered to the board which gave him a certain
amount of grief. However I did manage
to track down some additional information and shorting out J5 should clear the CMOS.
With the front edge of the laptop towards you J5 can be found at the right hand end
of the RAM bay as shown in the photograph. It is just a couple of PCB traces that can be bridged
by a screwdriver blade or other metal object.
With the standard firmware there are two possible error messages:
boot failure error code 17 - I can't find any mass storage.
boot failure error code 4 - I can find mass storage but I don't recognise the data that is on it.
The standard firmware is setup for interaction with Sun servers and so is really of no interest to me unless there is someway we could subvert it to gain control. In my brief look so far it doesn't look like we can as, as far as I can see, the operating system is loaded from elsewhere before it accesses this flash memory.
For those who wish to use it 'as is' I tracked down copies of the user manual and the administrator's manual on the Flextronics website. (Flextronics took over complete support for the range in December 2013).
This is my current guess how the standard setup works.
The core of the operating system is embedded (maybe) in the BIOS flash chip. It is somewhere - the Pulsar hardware was easy to check and I didn't see any added memory elsewhere. I haven't had the FT01 fully apart to see what's on the motherboard. As it's a standard laptop I think it unlikely that there's an extra chip.
When the system boots the default boot device is something like the ROM FLOPPY DRIVE as identified in the Pulsar BIOS. This then loads the core of the operating system. Once loaded it searches any disk drives to find the rest of the operating system - the 'apps' and configuration information.
I have proved the 'auto search' aspect by copying the image of the supplied Flash Memory
to a Compact Flash card, removing the original flash and connecting the Compact Flash card to
the SATA socket via a CF-to-SATA adapter. The standard software ran happily as before.
The Flash memory contains two partitions: One holds the basic apps for the terminal server...
root@pike:/mnt# ls -al sdc1 total 52732 drwxrwxrwx 2 root root 16384 Jan 1 1970 . drwxrwxr-x 7 root staff 140 Aug 4 13:02 .. -rwxrwxrwx 1 root root 1992280 Jul 31 2012 0base.tle -rwxrwxrwx 1 root root 280 Jul 31 2012 0bootarg.ime -rwxrwxrwx 1 root root 10520056 Jul 31 2012 0browser.tle -rwxrwxrwx 1 root root 2124376 Jul 31 2012 0client.tle -rwxrwxrwx 1 root root 2001688 Jul 31 2012 0drivers.tle -rwxrwxrwx 1 root root 980584 Jul 31 2012 0initrd.ime -rwxrwxrwx 1 root root 6386 Jul 31 2012 0meteor.bom -rwxrwxrwx 1 root root 12952 Jul 31 2012 0misc.tle -rwxrwxrwx 1 root root 868456 Jul 31 2012 0network.tle -rwxrwxrwx 1 root root 3272856 Jul 31 2012 0opengl.tle -rwxrwxrwx 1 root root 2276872 Jul 31 2012 0os.ime -rwxrwxrwx 1 root root 463144 Jul 31 2012 0oss.tle -rwxrwxrwx 1 root root 1320 Jul 31 2012 0platfrm.tle -rwxrwxrwx 1 root root 162952 Jul 31 2012 0sc.tle -rwxrwxrwx 1 root root 2263080 Jul 31 2012 0video.tle -rwxrwxrwx 1 root root 1992280 Jul 31 2012 1base.tle -rwxrwxrwx 1 root root 280 Jul 31 2012 1bootarg.ime -rwxrwxrwx 1 root root 10520056 Jul 31 2012 1browser.tle -rwxrwxrwx 1 root root 2124376 Jul 31 2012 1client.tle -rwxrwxrwx 1 root root 2001688 Jul 31 2012 1drivers.tle -rwxrwxrwx 1 root root 980584 Jul 31 2012 1initrd.ime -rwxrwxrwx 1 root root 6386 Jul 31 2012 1meteor.bom -rwxrwxrwx 1 root root 12952 Jul 31 2012 1misc.tle -rwxrwxrwx 1 root root 868456 Jul 31 2012 1network.tle -rwxrwxrwx 1 root root 3272856 Jul 31 2012 1opengl.tle -rwxrwxrwx 1 root root 2276872 Jul 31 2012 1os.ime -rwxrwxrwx 1 root root 463144 Jul 31 2012 1oss.tle -rwxrwxrwx 1 root root 1320 Jul 31 2012 1platfrm.tle -rwxrwxrwx 1 root root 162952 Jul 31 2012 1sc.tle -rwxrwxrwx 1 root root 2263080 Jul 31 2012 1video.tle -rwxrwxrwx 1 root root 23 Jul 31 2012 factory.conf -rwxrwxrwx 1 root root 80 May 8 2008 features -rwxrwxrwx 1 root root 384 May 8 2008 licence
whilst the other appears to hold some security related files.
root@pike:/mnt# ls -l sdc2 total 16384 -rwxrwxrwx 1 root root 4194304 Aug 3 12:22 0certs.img -rwxrwxrwx 1 root root 4194304 Aug 3 12:24 0meteor.cfg -rwxrwxrwx 1 root root 4194304 Jul 31 2012 1certs.img -rwxrwxrwx 1 root root 4194304 Jul 31 2012 1meteor.cfg
These are actually file systems that can be mounted.
root@pike:/mnt# mount -o loop sdc2/0certs.img img root@pike:/mnt# ls -l img total 6 drwxr-xr-x 2 root root 2048 Feb 27 2009 ca_root drwxr-xr-x 2 root root 2048 Jul 31 2012 pending drwxr-xr-x 2 root root 2048 Jul 31 2012 pkcs12 root@pike:/mnt#
If you have an interest in exploring the standard firmware I suggest a visit to Cameron Kaiser's blog posting would be worth your while.
Just a few notes on how to look around the firmware on a Linux system starting with
a 'dd' image of the Tadpole DOM. In my case I named the file TadpoleFirmwareImage
The various file systems in the image can be mounted as 'loop' devices. Luckily there
is a handy utility losetup that will check the partition table and set up
the necessary devices for us. This is part of the util-linux.tcz package.
A quick look at the basic structure of the DOM using fdisk:
tc@mirror:~$ fdisk -l TadpoleFlashImage Disk TadpoleFlashImage: 244.5 MiB, 256376832 bytes, 500736 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x28c186b3 Device Boot Start End Sectors Size Id Type TadpoleFlashImage1 * 2048 432127 430080 210M 6 FAT16 TadpoleFlashImage2 432128 499711 67584 33M 6 FAT16
...which shows us the disk image includes two partitions. Next we need to setup the loop devices for these partitions:
tc@mirror:~$ sudo losetup --partscan --find --show TadpoleFlashImage /dev/loop307
..which reports that the 'device' it has set up is /dev/loop307. It will also have set up
/dev/loop307p1 and /dev/loop307p2 for the two partitions that are on it. These
can be mounted in the usual way:
tc@mirror:~$ mkdir /mnt/tp1 /mnt/tp2 tc@mirror:~$ sudo mount /dev/loop307p1 /mnt/tp1 tc@mirror:~$ sudo mount /dev/loop307p2 /mnt/tp2
At this point we can explore those file systems. For example we can see what's on the second partition:
tc@mirror:~$ ls -l /mnt/tp2 total 16384 -rwxr-xr-x 1 root root 4194304 Apr 23 2019 0certs.img -rwxr-xr-x 1 root root 4194304 Jun 16 17:51 0meteor.cfg -rwxr-xr-x 1 root root 4194304 Jun 25 2008 1certs.img -rwxr-xr-x 1 root root 4194304 Jun 25 2008 1meteor.cfg
It turns out that some of these files are actually file systems themselves. One such
file which is of interest is 0meteor.cfg. To view the contents it has to
be mounted in it turn:
tc@mirror:~$ mkdir /mnt/meteor tc@mirror:~$ sudo mount /mnt/tp2/0meteor.cfg /mnt/meteor tc@mirror:~$ ls -l /mnt/meteor total 86 -rwxr-xr-x 1 root root 872 Dec 1 2008 base.conf drwxr-xr-x 2 root root 2048 Apr 23 2019 default/ drwxr-xr-x 2 root root 2048 Dec 7 2007 profile.1/ drwxr-xr-x 2 root root 2048 Dec 7 2007 profile.10/ ........................................ drwxr-xr-x 2 root root 2048 Dec 7 2007 profile.9/ -rwxr-xr-x 1 root root 86 Apr 23 2019 profiles.conf tc@mirror:~$
In Cameron's write up he describes finding four entries in the firmware files:
Password_Enc=d8f98565418640e8ef37dfc640ebec01e2b00284and found that by corrupting the name the system no longer asked for a password when you went into the main configuration menu. (You get there by pressing the 'menu' key along with 'M'). I followed his lead by patching these entries to see what happened.
I had a 'dd' image of the 256MB IDE DOM as a file TadpoleFirmwareImage. I found the
ideal tool to edit this file was the free Windows utility Hex Editor Neo. This was quick and
easy to use and not worried by the size of the file.
It was just a case of opening the file, searching for 'Password', changing the 'P' to another letter
and then doing 'find again'. After having done all four entries, saving the file.
The final step was to use 'dd' to copy the image to an 8GB SATA SSD I had to hand which was connected via a USB-to-SATA adapter. (Easier than trying to find my old IDE adapters). This I then transferred to the FT01.
On pressing Menu-M the opening screen with no password prompt
Clicking on 'Controls' brought up an option to update the BIOS:
which then failed:
The embedded firmware tried to go off to download a file from somewhere and failed. As always a 'one step forward and then two back' situation.
More digging is required to see from where it is trying to load the BIOS file, what it is called and what format is it in. Does it also download the program to flash the new BIOS?
My original intention here was to find some non-invasive way to replace the BIOS. That's not looking hopeful and the only answer might well be using a programmer to reprogram the BIOS chip directly which will require the FT01 to be dismantled and maybe desoldering the BIOS chip.