More D-Sample revelations

Mychaela Falconia falcon at ivan.Harhan.ORG
Sun Nov 29 22:12:42 CET 2015


Hello fellow hackers,

This post will primarily be of interest to those who took a curious
look at the flash dump from our D-Sample find which I posted back when
I first powered it up and got fc-loadtool to work with it through the
MODEM UART port.

The first thing any reverse engineer will typically do when faced with
an unknown binary is to run the Unix strings command on it.  If you
ran strings on the D-Sample flash dump I posted a while back, you have
undoubtedly seen these very interesting strings right near the
beginning:

   Press all RED keys ONCE      

Quick selftest:
FManual tests:
 Check mic/speaker loop
 Check that all LEDs are ON
  (charge power is required)
 LCD backlight is ON
 LCD colors are OK
 Buzzer ringing
 Keypad passed
 Keypad failed
 U409 is OK
 U409 failed
 U410 is OK
 U410 failed
 U411 is OK
 U411 failed
 U419/U420 is OK
 U419/U420 failed
FSELFTEST PASS
SELFTEST FAIL
 X401/U401-3 are OK
 X401/U401-3 failed
 Press any key... 

FPlaying D-Sample TETRIS
< PAUSE                EXIT >

Score : 
F< RESUME   (PAUSED)          
< PAUSE                EXIT >
FSorry, game over....   

Self-test?  Manual hardware tests?  A tetris game?  Oh, and that
"Press any key..." string sure seems like the very same string as
seen displayed on the LCD in this historical TI photo:

https://www.freecalypso.org/boards/d-sample.jpeg

And the whole picture on the LCD in that photo sure seems like some
kind of hardware test, doesn't it?

So it looks like we got this code in the flash, yet I could never get
it to run: when I power this D-Sample up and let it boot the fw image
in its flash (dated 20020917), the display stays completely dark
(LED-B backlight off) and there are no signs of any UI code running -
instead all that seems to be running is GSM fw, taking control via AT
commands on the MODEM UART.

The answer came to me as soon as I took a few quick disassembly peeks
at the flash dump, but first let's review the structure of TI's classic
fw images for the Calypso.  TI's standard fw is structured so it will
boot the same way whether the on-chip boot ROM is enabled or disabled:

* They put 0x00000001 in the word at 0x2000, telling the boot ROM (if
  it's enabled) to boot the flash fw image by disabling itself and
  restarting the CPU with the watchdog, so the flash image will boot
  the same way as if the boot ROM weren't there, after the boot ROM
  has given the serial boot diversion opportunity.

* They put their own boot code (which we only have in binary form and
  which I never bothered to RE) at 0 that provides its own mechanism
  for serially interrupting and diverting the boot process for
  reflashing the fw, as an alternative to the mechanism provided by
  the boot ROM.  I never bothered to reverse this code and its serial
  protocol as the boot ROM is totally superior (physically unbrickable)
  when it's enabled in the hardware, and on Compal phones we have to
  use Compal's non-TI bootloader protocol to make the initial entry,
  so it makes the most sense to just keep using the same.

* The main (non-bootloader) part of the fw starts at 0x10000 in TI's
  standard fws of TCS211 era: exception and interrupt vectors at
  0x10000 and the boot entry point at 0x10058.

When I first did a cursory hex dump on the D-Sample flash image, I saw
the same familiar TI fw boot code at 0, a 0x00000001 word at 0x2000,
and it seemed that the main part of the fw started at 0x4000 instead
of 0x10000.  At first I chalked it up to the different flash erase
block layout: the 8 MiB Intel flash chip on the D-Sample seems to have
the first 64 KiB (and possibly the last 64 KiB too) broken up into
small 8 KiB "boot" sectors, so they could have moved it up from 0x10000
to 0x4000 and still been on an erase block boundary.

But today's revelation occurred when I ran my simple hacky disassembler
on the image and saw that the 7 exception vector redirection branch
instructions in the boot code jump to 0x10000 and not to 0x4000.  And
sure enough, the main fw entry point to which the boot code jumps after
not having been serially diverted is at 0x10050: OK, not quite the same
as 0x10058 in the more familiar fw versions, but still, the image
clearly starts at 0x10000, not at 0x4000.

So what do we make then of the 48 KiB of code found in the flash dump
in the [0x4000,0xFFFF] range?  Answer: it can only be a *remnant* of
what was in the flash before the currently booting image has been
flashed.  I never bothered to RE TI's flasher (FLUID), but it is
reasonable to assume that in its default mode of operation it may only
erase those sectors into which some new bits are to be programmed as
given in the m0 S-record file.  If the m0 file corresponding to the
20020917 fw image this D-Sample came with put the boot code bits at 0,
then 0x00000001 at 0x2000, then the rest of the code at 0x10000 and
onward, then indeed FLUID may have skipped the 6 8 KiB sectors in the
[0x4000,0xFFFF] range and left them with their previous bit content.

And as you have probably guessed by now, all those interesting ASCII
strings regarding hardware tests and "D-Sample TETRIS" are located in
this [0x4000,0xFFFF] range: these strings are therefore not part of
the functional fw image currently flashed into the board, but remnants
from a different image which was there before.  And no, we don't have
any way to reconstruct that previous image in its entirety: the part
before 0x4000 is lost, and so is everything past the 0x10000 mark.
Thus we will probably never get a chance to play D-Sample Tetris or to
recreate that interesting LCD picture in TI's old photo. :-(

But the history of this D-Sample is starting to make a little more
sense now.  The hardware was in total mint condition, looking like it
wasn't touched at all since it left the factory well over a decade ago,
but the fw image it came with makes no use of the LCD or the keypad.
It just seemed odd to me: wouldn't TI have shipped their D-Sample kits
from the factory with some fw image that actually exercised and showed
off their hardware?  But what if the UI code in the GSM fw for the
D-Sample wasn't ready yet at that time, back in 2002?  Thinking about
it, it seems quite logical that TI's board group (in Aalborg?) probably
put together their own hardware test code that exercised the LCD and
other peripheral hardware w/o GSM, used it to prove their hardware as
good, and then let the UI software team do their job on their own
schedule.

If my hypothesis is correct, then they probably flashed each D-Sample
board with the hw test code first, verified that the LCD etc hardware
is good, then reflashed it with sans-UI (no LCD, AT commands only) GSM
firmware, verified and calibrated the RF tract with this fw, and then
shipped the boards in that state.

All right, enough curiosity for this round...

M~


More information about the Community mailing list