view se_k200i/flash-notes @ 402:1b83d07576bf

compal/boot/c123-boot.disasm: missed vector branch at 0x1c
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 15 Jan 2023 00:06:59 +0000
parents 00f5287db832
children
line wrap: on
line source

SE K200 family phones have 16 MiB of flash total, physically presented to the
Calypso chip as two banks of 8 MiB each.  Their official fw architecture uses
the following flash organization:

Flash bank 1, first 64 KiB sector:

This part of the flash naturally contains the boot entry point.  The word at
0x2000 equals 1, telling Calypso boot ROM to move itself out of the way and
perform a watchdog reset, and then the reset entry point is at 0.  The code
implemented by SE or their ODM in this flash sector is a boot stage of their
own invention, eventually passing control to the main fw entry point at
0x20000.

Flash bank 1, 64 KiB sector at 0x10000:

This sector holds two items of factory-programmed data, apparently intended to
remain immutable for the lifetime of each hw unit:

 7 bytes at 0x10000: the phone's IMEI, format obvious, no obfuscation
 1 byte  at 0x10007: 0xFF filler
64 bytes at 0x10008: appear to be cryptographically random filler

Flash bank 1 starting at 0x20000:

The main firmware image resides here, entry point right at 0x20000.

Flash bank 2, first 13 sectors of 256 KiB each:

The firmware on this phone model uses classic TIFFS.  Their TIFFS organization
is 256x13 (a little smaller than Pirelli's 256x18), sitting at the beginning of
flash bank 2, mapped into Calypso address space at 0x01800000.  FFS design
appears to be self-regenerating: if the fw is booted with all FFS sectors
erased, it will not only format a new FFS like Pirelli's fw, but also fill it
with all necessary data.  In contrast with Pirelli's fw architecture, the FFS
in these SE K200 phones appears to NOT contain any static asset files that must
be loaded externally.

Flash bank 2, area starting at 0x01B40000, right after TIFFS:

This area appears to be an extension of the firmware.  Without a lot more
reverse eng work, it is not obvious if this area contains any executable code,
or if it is only data bits like UI pixel images, MIDI ringtones, language
strings etc.

Flash bank 2, 64 KiB sector at 0x01FD0000:

This sector holds factory calibration data, including RF, AFC (VCXO) and MADC
calibrations.  When the firmware reinitializes a freshly formatted FFS, it must
be copying calibration bits from this sector.

Flash bank 2, 64 KiB sector at 0x01FF0000 (end of flash):

First 0x2C8 bytes: purpose unknown, but they are fed into the hash function
that determines whether or not the firmware is allowed to boot.

8 bytes at 0x01FF02C8: output of some kind of cryptographic hash function

There is a hash function implemented in the custom bootloader in sector 0 (not
studied in detail) whose inputs are the IMEI record at 0x10000, the block of
0x2C8 bytes at 0x01FF0000 and the block of 64 bytes at 0x10008 in this order.
The output must match the 8 bytes at 0x01FF02C8, or the code refuses to boot
and goes into a dead hang instead.