TL866 II PLUS/Bootloader - Revision history

Elemecca: /* Write Block */

2018-08-28T22:13:34Z

Write Block

← Older revision		Revision as of 22:13, 28 August 2018
Line 117:		Line 117:
	\| 0 \|\| <tt>bCommand</tt> \|\| 1 \|\| <tt>3B</tt> \|\| the command identifier		\| 0 \|\| <tt>bCommand</tt> \|\| 1 \|\| <tt>3B</tt> \|\| the command identifier
	\|-		\|-
	\| 1 \|\| <tt>~~bUnknown1~~</tt> \|\| 1 \|\|		\| 1 \|\| <tt>bKeyOffset</tt> \|\| 1 \|\|
	\| ~~Copied from~~ the ~~block in~~ the ~~update file. Purpose unknown~~.		\| An offset into the XOR table used for decryption by the bootloader.
	\|-		\|-
	\| 2 \|\| <tt>wBlockSize</tt> \|\| 2 \|\|		\| 2 \|\| <tt>wBlockSize</tt> \|\| 2 \|\|
	\| The size in bytes of the encrypted data to be sent.		\| The size in bytes of the encrypted data to be sent.
	\|-		\|-
	\| 4 \|\| <tt>~~dUnknown2~~</tt> \|\| 4 \|\|		\| 4 \|\| <tt>dAddress</tt> \|\| 4 \|\|
	\| ~~Some kind~~ of ~~checksum? Computed from~~ the block ~~in the update file and a key from the file header~~.		\| The program memory address of the start of the block.
	\|}		\|}

Elemecca: /* Write Block */

2018-08-27T00:10:20Z

Write Block

← Older revision		Revision as of 00:10, 27 August 2018
Line 123:		Line 123:
	\| The size in bytes of the encrypted data to be sent.		\| The size in bytes of the encrypted data to be sent.
	\|-		\|-
	\| 4 \|\| <tt>~~bUnknown2~~</tt> \|\| 4 \|\|		\| 4 \|\| <tt>dUnknown2</tt> \|\| 4 \|\|
	\| Some kind of checksum? Computed from the block in the update file and a key from the file header.		\| Some kind of checksum? Computed from the block in the update file and a key from the file header.
	\|}		\|}

Elemecca: /* USB Protocol */

2018-08-27T00:09:10Z

USB Protocol

← Older revision		Revision as of 00:09, 27 August 2018
Line 6:		Line 6:
	== USB Protocol ==		== USB Protocol ==

	The bootloader and the stock firmware communicate with the host via simple custom USB protocol. It uses three bidirectional bulk endpoints on Interface 0. Endpoint 1 Out is used to send commands and Endpoint 1 In is used to read status responses. For commands that transfer large amounts of data the payload is split evenly between Endpoint 2 and Endpoint 3, presumably to increase transfer speed.		The bootloader and the stock firmware communicate with the host via a simple custom USB protocol. It uses three bidirectional bulk endpoints on Interface 0. Endpoint 1 Out is used to send commands and Endpoint 1 In is used to read status responses. For commands that transfer large amounts of data the payload is split evenly between Endpoint 2 and Endpoint 3, presumably to increase transfer speed.

	When sending a command, the first 8 bytes are always the command header and are written to Endpoint 1. The behavior for the payload — the data, if any, to be sent after the command header — depends on its size. If the payload plus the 8-byte header fit in a single 64-byte packet, the payload is sent in the same packet as the header on Endpoint 1. If the payload is exactly 64 bytes, it's sent in a single packet on Endpoint 2. Otherwise, the payload is split between Endpoint 2 and Endpoint 3. If the total size of the payload is less than 128 bytes, each endpoint gets exactly half, with Endpoint 2 first. Otherwise, the data is split into 64-byte blocks. The first half of the blocks are sent to Endpoint 2 and the other half to Endpoint 3. If there are an odd number of whole blocks Endpoint 3 gets the extra one. If the final block is partial, it is always sent to Endpoint 3.		When sending a command, the first 8 bytes are always the command header and are written to Endpoint 1. The behavior for the payload — the data, if any, to be sent after the command header — depends on its size. If the payload plus the 8-byte header fit in a single 64-byte packet, the payload is sent in the same packet as the header on Endpoint 1. If the payload is exactly 64 bytes, it's sent in a single packet on Endpoint 2. Otherwise, the payload is split between Endpoint 2 and Endpoint 3. If the total size of the payload is less than 128 bytes, each endpoint gets exactly half, with Endpoint 2 first. Otherwise, the data is split into 64-byte blocks. The first half of the blocks are sent to Endpoint 2 and the other half to Endpoint 3. If there are an odd number of whole blocks Endpoint 3 gets the extra one. If the final block is partial, it is always sent to Endpoint 3.

Elemecca at 00:05, 27 August 2018

2018-08-27T00:05:40Z

← Older revision		Revision as of 00:05, 27 August 2018
Line 4:		Line 4:
	The process of reverse engineering the bootloader is still ongoing.		The process of reverse engineering the bootloader is still ongoing.

	== ~~Commands~~ ==		== USB Protocol ==

			The bootloader and the stock firmware communicate with the host via simple custom USB protocol. It uses three bidirectional bulk endpoints on Interface 0. Endpoint 1 Out is used to send commands and Endpoint 1 In is used to read status responses. For commands that transfer large amounts of data the payload is split evenly between Endpoint 2 and Endpoint 3, presumably to increase transfer speed.

			When sending a command, the first 8 bytes are always the command header and are written to Endpoint 1. The behavior for the payload — the data, if any, to be sent after the command header — depends on its size. If the payload plus the 8-byte header fit in a single 64-byte packet, the payload is sent in the same packet as the header on Endpoint 1. If the payload is exactly 64 bytes, it's sent in a single packet on Endpoint 2. Otherwise, the payload is split between Endpoint 2 and Endpoint 3. If the total size of the payload is less than 128 bytes, each endpoint gets exactly half, with Endpoint 2 first. Otherwise, the data is split into 64-byte blocks. The first half of the blocks are sent to Endpoint 2 and the other half to Endpoint 3. If there are an odd number of whole blocks Endpoint 3 gets the extra one. If the final block is partial, it is always sent to Endpoint 3.

	=== Reset ===		=== Reset ===

	~~Command <tt>3F</tt> seems to be used to~~ reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.		The reset command asks the device to reboot. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.

	{\| class="wikitable"		{\| class="wikitable"

Elemecca: /* Reset */

2018-08-26T23:45:26Z

Reset

← Older revision		Revision as of 23:45, 26 August 2018
Line 19:		Line 19:
	\|}		\|}

	When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset~~? Unknown until~~ the firmware ~~is dumped and analyzed~~.		When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset. If this command isn't sent first, the reset command appears to succeed but the device reboots to the stock firmware, not the bootloader.

	{\| class="wikitable"		{\| class="wikitable"

Elemecca: /* Commands */

2018-08-26T23:42:53Z

Commands

← Older revision		Revision as of 23:42, 26 August 2018
Line 32:		Line 32:
	\| unknown, maybe just a fixed key? Set statically in the official client.		\| unknown, maybe just a fixed key? Set statically in the official client.
	\|}		\|}


	=== Report ===		=== Report ===
Line 104:		Line 103:
	\| 1 \|\| ''unknown'' \|\| 7 \|\| \|\|		\| 1 \|\| ''unknown'' \|\| 7 \|\| \|\|
	\|}		\|}


	=== Write Block ===		=== Write Block ===

Elemecca: /* Report */

2018-08-26T23:42:01Z

Report

← Older revision		Revision as of 23:42, 26 August 2018
Line 54:		Line 54:
	\| 0 \|\| <tt>bCommand</tt> \|\| 1 \|\| <tt>00</tt> \|\| the command, echoed		\| 0 \|\| <tt>bCommand</tt> \|\| 1 \|\| <tt>00</tt> \|\| the command, echoed
	\|-		\|-
	\| 1 \|\| <tt>bStatus</tt> \|\| 1 \|\|		\| 1 \|\| <tt>bStatus</tt> \|\| 1 \|\| <tt>01</tt> \|\| no longer used?
	~~\| which firmware is running:~~ <tt>01</tt> ~~is the stock firmware, <tt>02</tt> is the bootloader~~
	\|-		\|-
	\| 2 \|\| ''unknown'' \|\| 2 \|\| \|\|		\| 2 \|\| ''unknown'' \|\| 2 \|\| \|\|
Line 82:		Line 81:
	\|}		\|}

			In versions of the TL866 A/CS firmware 03.2.82 and earlier, the <tt>bStatus</tt> field was used to indicate whether the device was currently running the stock firmware (value <tt>01</tt>) or the bootloader (value <tt>02</tt>). A/CS firmware 03.2.85 and the TL866II-Plus appear to always return <tt>01</tt>. The only difference in the report output between the stock firmware and the bootloader on the TL866II-Plus is the version number, for which the bootloader always returns 1.0.

	=== Erase ===		=== Erase ===

Elemecca: /* Commands */

2018-08-26T23:33:57Z

Commands

@@ Line 80: / Line 80: @@
 | 40 || <tt>bDeviceVersion</tt> || 1 ||
 | firmware version device part: xx.0.00
 |}

Elemecca: /* Report */

2018-08-26T21:16:05Z

Report

← Older revision		Revision as of 21:16, 26 August 2018
Line 47:		Line 47:
	\|}		\|}

	The device will respond with a 64-byte structure:		The device will respond with a 41-byte structure:

	{\| class="wikitable"		{\| class="wikitable"

Elemecca: /* Report */

2018-08-26T20:07:07Z

Report

← Older revision		Revision as of 20:07, 26 August 2018
Line 47:		Line 47:
	\|}		\|}

	The device will respond with a 64-byte structure ~~(unknown fields omitted)~~:		The device will respond with a 64-byte structure:

	{\| class="wikitable"		{\| class="wikitable"
Line 54:		Line 54:
	\| 0 \|\| <tt>bCommand</tt> \|\| 1 \|\| <tt>00</tt> \|\| the command, echoed		\| 0 \|\| <tt>bCommand</tt> \|\| 1 \|\| <tt>00</tt> \|\| the command, echoed
	\|-		\|-
	\| 1 \|\| <tt>bStatus</tt> \|\| 1 \|\| ??		\| 1 \|\| <tt>bStatus</tt> \|\| 1 \|\|
	\| which firmware is running: <tt>01</tt> is the stock firmware, <tt>02</tt> is the bootloader		\| which firmware is running: <tt>01</tt> is the stock firmware, <tt>02</tt> is the bootloader
	\|-		\|-
	\| 4 \|\| <tt>bFwVersionMinor</tt> \|\| 1 \|\| ??		\| 2 \|\| ''unknown'' \|\| 2 \|\| \|\|
			\|-
			\| 4 \|\| <tt>bFwVersionMinor</tt> \|\| 1 \|\|
	\| firmware version minor part: 00.0.xx		\| firmware version minor part: 00.0.xx
	\|-		\|-
	\| 5 \|\| <tt>bFwVersionMajor</tt> \|\| 1 \|\| ??		\| 5 \|\| <tt>bFwVersionMajor</tt> \|\| 1 \|\|
	\| firmware version major part: 00.x.00		\| firmware version major part: 00.x.00
	\|-		\|-
Line 66:		Line 68:
	\| device model: <tt>05</tt> is the TL866II-Plus, <tt>06</tt> is the XGecu T500		\| device model: <tt>05</tt> is the TL866II-Plus, <tt>06</tt> is the XGecu T500
	\|-		\|-
	\| 8 \|\| <tt>sDeviceCode</tt> \|\| 8 \|\| ??		\| 7 \|\| ''unknown'' \|\| 1 \|\| \|\|
			\|-
			\| 8 \|\| <tt>sDeviceCode</tt> \|\| 8 \|\|
	\| ISO 8859-1 string (no zero terminator)		\| ISO 8859-1 string (no zero terminator)
	\|-		\|-
	\| 16 \|\| <tt>sSerialNumber</tt> \|\| 20 \|\| ??		\| 16 \|\| <tt>sSerialNumber</tt> \|\| 20 \|\|
	\| ISO 8859-1 string (no zero terminator)		\| ISO 8859-1 string (no zero terminator)
	\|-		\|-
	\| 40 \|\| <tt>bDeviceVersion</tt> \|\| 1 \|\| ??		\| 36 \|\| ''unknown'' \|\| 4 \|\| \|\|
			\|-
			\| 40 \|\| <tt>bDeviceVersion</tt> \|\| 1 \|\|
	\| firmware version device part: xx.0.00		\| firmware version device part: xx.0.00
	\|}		\|}