Tiptoi firmware update

The firmware update files can directly be downloaded from Ravensburger’s website. The file names for the German version are Update3202.upd (~10.8 MiB) and update.upd (~6.1 MiB).

String analysis

The strings command can be run on those files to check for any insights into how the embedded system works or how updates are carried out. It would also be interesting to find out what is actually written to the NAND flash memory and possibly also other non-volatile memories.

Interesting entries:

  • List of NAND flash names (including the Hynix HY27UF084G2B with several others from Samsung, Hynix, Toshiba, Micron, ST and Intel)
  • Hints about the NTFL (NAND Flash Translation Layer)
  • Library/function names: FSLib (FS probably stands for filesystem), NandMtd, MtdLib (Mtd probably stands for “Memory Technology Device”), FatLib, MediaLib, Utl_*
  • Version strings
  • “Serial trace is active!”
  • File system names: FAT32, FAT16, FAT12
  • List of German words: Apfel, Auto, Baum, …, Wort, Wurm, Zelt – What could they be used for?
  • Strings containing references to media files (“ID3x”, “RIFF”, “WAVEfm”)
  • Strings containing the word “battery”
  • Strings referring to possible SCSI data transfers
  • Firmware version strings at the end, e.g. “ANYKA_IDRAV_N0038” and “RAV_V0136”
  • C file names (e.g. “medium.c”)
  • “End of userware”, “This is userware”
  • Warning and error messages, probably also debug strings

Both firmware update files seem to contain RIFF wave files. As a first indicator the number of matches is counted:

$ strings update.upd | grep RIFF | wc -l
49
$ strings Update3202.upd | grep RIFF | wc -l
58

Using burntool

There is a burntool for the AK98 / AK37 / AK39 / AK10L / 10xx / 11xx MCUs.

Firmware update files

Using the burntool the firmware update files are split up and stored separately in the subdirectory /Update_Files when being imported:

  • BOOT.bin (~27 kB; “nandboot”)
  • codepage.bin (~880 kB; “download_to_nand2”)
  • producer.bin (~111/88 kB; “producer”)
  • PROG.bin (~3.7 MB/1 MB; “download_to_nand1”)
  • voice/Chomp_Voice.bin (~4.3 MB; “download_to_udisk1”)
  • Language/BatLowUpdate[DUTCH|FRENCH|GERMAN].wav
  • Language/Update[DUTCH|FRENCH|GERMAN].wav

The tool can also be used to re-assemble those files to a single .upd firmware update file (export function).

Configuration

The burntool also comes with a configuration file (config.txt) where several settings can or need to be defined:

  • run address for the producer binary
  • MAC addresses and serial numbers to be written
  • chipset specific settings
    • MCU chip type (AK_*)
    • mode (there seems to be a reference to JTAG on the AK_11XX devices)
  • Download to different sections:
    • udisk: contents from PC directory /voice go here (audio files),
      UDISK destination is “A:VOIMG”
    • MTD: root file system files(?) from PC (root.jffs2, root.sqsh4) to be stored in device’s disks A and B; not sure if applicable for Tiptoi pen
    • Flash: PROG.bin and codepage.bin fo to the Flash memory
  • formatting with partition table
  • number of supported flash devices and
  • lists of those supported NAND flash, SPI NAND flash and SD card flash devices
  • definition of USB VID and PID
  • command line support

NAND flash configuration

The definition list of the NAND flash devices includes the following details: chip ID and chip organization:

  • page size (usually 512, 2048 or 4096 Bytes)
  • pages per block (usually 32, 64, 128)
  • total block count (e.g. 4096)
  • group block number[?]
  • plane block number[?]
  • spare size (16 or 64; Byte per page!)
  • column address cycle + last column address cycle mask bit
  • row address cycle + last column address cycle mask bit
  • custom NAND flash configuration (reserved for future use?)
  • flag (set of bits)
  • command length for timing considerations
  • data length for timing considerations
  • descriptor string (device name)

Those settings can be both read and written from the burntool GUI. So changes in the GUI can be tracked in the config.txt file and its file format can be understood.

Example configuration entry for a NAND flash device:

burntool NAND flash configuration list
burntool NAND flash configuration list

Corresponding entry in the config.txt (the entry no. is automatically filled in). You can see that some values are defined in decimal, others in hex:

nand supported count = ...
nand 1 = 0x2,    3,   4, 5, 6, 7,   8, 9, 10, 11,  12, 0xd, 0x14, 0x15, 0x16, 17

Instead of using this reverse engineering approach – there is one version of the burntool the data contained in the .upd file can be read on import and is then stored in the config.txt file. For the specific Flash IC mentioned above the line in the configuration file is:

nandXXX = 0x9510dcad, 2048,  64, 4096, 4096, 2048,  64, 2, 15, 3,   7, 0x2, 0x1, 0xf5ad1, 0x40203, Hynix HY27UF084G2B
  • chip ID: 0x9510dcad (seems to be a little endian representation of the ID which can be read from the IC with the READ ID command,
    i.e. 0xAD =Manufacturer Code for Hynix, 0xDC = Device Identifier,
    0x10 0x95 = Device Details, 0x54 = Multiplane info is missing however)
  • page size: 2048 Bytes
  • pages per block: 64
  • total block count: 4096
  • group block number[?]: 4096
  • plane block number[?]: 2048
  • spare size: 64 Byte per page
  • column address cycle + last column address cycle mask bit: 2, 15
  • row address cycle + last column address cycle mask bit: 3, 7
  • custom NAND flash configuration (reserved for future use?): 2
  • flag (set of bits): 0x1
  • command length for timing considerations: 0xf5ad1 = 1’006’289d
  • data length for timing considerations: 0x40203 = 262’659d
  • descriptor string (device name): Hynix HY27UF084G2B

The list of SPI flash configurations is not too important for us as the Tiptoi does not use SPI flash.

Partition table configuration

The data structure for a partition includes:

  • symbol (seen: A/B, probably A..G)
  • user disk (seen: yes/no)
  • “infor” (seen: normal/check/read-only)
  • attribute (seen: primary/slave/MMI/STANDARD/UNSTANDARD)
  • size
  • volume label (string)

Back to the .upd firmware update file

Maybe we can find out something about the format of the firmware update files. As we know that the string of the flash device is stored in the .upd file let’s have a look for its location and the area around it within the file using the strings command with option -t (-td for decimal, -tx for hex):

$ strings update.upd -tx | grep 'Hynix HY27UF084G2B'
   2ef8 Hynix HY27UF084G2B
$ strings Update3202.upd -td | grep 'Hynix HY27UF084G2B'
   3552 Hynix HY27UF084G2B

The firmware update files pretty much start with a list of the supported flash devices.

The entries have a fixed width/spacing of 287 bytes (measured between the start of strings) in update.upd. The entries end with the string (NULL-terminated, up to 255 bytes), the other information (32 byte) can be found before it:

flash_device_descriptor

  • 32-bit Chip ID (0x9510DCAD)
  • 16-bit: page size: value is 0x0800 = 2048 Bytes (little endian)
  • 16-bit: pages per block is 0x0040 = 64
  • 16-bit: total block count is 0x1000 = 4096
  • 16-bit: group block number[?] is 0x1000 = 4096
  • 16-bit: plane block number[?] is 0x0800 =2048
  • 8-bit: spare size is 0x40 = 64 Byte per page
  • 8-bit: column address cycle is 0x02 = 2
  • 8-bit: last column address cycle mask bit: 0x0F = 15
  • 8-bit: row address cycle: 0x03 = 3
  • 8-bit: last column address cycle mask bit:  0x0B = 11 != 7 (?)
  • 8-bit: custom NAND flash configuration (reserved for future use?): 0x02 = 2
  • 32-bit flag (set of bits): 0x09000001 != 0x1 (masked?)
  • 32-bit command length for timing considerations: 0xf5ad1 = 1’006’289d
  • 32-bit data length for timing considerations: 0x40203 = 262’659d (shifted by 4 bit?)
  • 255 byte NULL-terminated descriptor string (device name): Hynix HY27UF084G2B

The format used by Update32.upd is slightly different: the width/spacing of each entry is 64 bytes:

flash_device_descriptor_2

It’s just a more dense representation saving some NULL bytes in the descriptor string. The string may now only take up to 32 bytes instead of 255.

burntool program

About the burntool itself: BurnTool.exe (~1-2 MB): it is a PE32 executable (GUI) Intel 80386, for MS Windows. There’s different versions of the burntool available in the internet. Also found source code around the web for the burntool itself!

Open questions

  • Which sections of the .upd files are transferred to the Tiptoi device?
  • How to build a valid config.txt configuration file?
  • Which sections include actual firmware code and in which instruction set?
  • Which addresses are used and where are the peripherals mapped?
  • What is the difference in the firmware update files for the different languages?
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s