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~ _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
