LinuxLibre:ISDB USB ZINWELL

It is a Digital TV receiver (USB dongle) manufactured by Zinwell Inc. and sold in Brazil by IBAYO as "IB-200" and by ZIROK as "DTV-1". Also labeled as "WiiTV". It is compliant with the ISDB-T 1Seg DTV standard (japanese standard adopted in Brazil).

device ID: 5a57:4210 Zinwell

It is very similar to this reference design from Somagic: http://www.somagic.cn/english/product_info.asp?id=57

photos of the device board

• http://www.lucasvr.gobolinux.org/etc/zinwell-up.jpg
• http://www.lucasvr.gobolinux.org/etc/zinwell-down.jpg

ICs used in the device board

Somagic SMI-2020CBE

http://www.somagic.com.cn/english/product_info.asp?id=57

• Unknown microcontroller
• 48-pin package
• pins 40 and 41 are connected directly to the USB connector.
• SPI and I2C interfaces (100 kHz) for controling an external tuner and modulator
• USB interface (used to communicate with the PC)
• we still don't have datasheets for this IC.
• Remote control interface (not used in this device)

Maxim MAX2163A

• Tuner (1-seg and 3-seg ISDB-T)
• Controlled through configuration/status registers accessible at I2C address 0xc0 (write) and 0xc1 (read) through pins 24 (SCL) and 25 (SDA) of the chip. We are currently trying to sniff these pins with our BusPiratev3 i2c sniffer but these pins are hard to reach with our probes.
• Datasheet available here (but this datasheet is for the 28 pin version. The receiver uses a 40-pin variant.)

MegaChips MA50159

• demodulator
• 64-pin package
• we still don't have the datasheet for this IC.
• Resistors R23 and R24 seem to be pull-up resistors for an i2c bus. These resistors are directly connected to pins 1 and 63 of the chip, which seem to be SCL and SDA, respectively. We have connected an i2c sniffer to these resistors and identified a device with addresses c0 and c1 in this i2c bus. Maybe this is a bus shared with the tuner.

Who is working on a free driver implementation?

• Felipe Sanches
• Lucas Villa Real

We have some experimental userspace code writen using libusb calls available here. It already tunes to a given frequency and receives the transport stream.

And we have some ongoing port to kernelspace here.

And there's an old blogpost here explaining the origins of this reverse engineering effort.

Who is working on a free firmware implementation?

• currently we load a block of 56 bytes to the device. We do not know whether this is actual executable firmware-code or simply initialization values.

	unsigned char firmware[56] = {
		0x01, 0x01, 0x04, 0x08, 0x05, 0x01, 0x06, 0x00, 
		0x15, 0xf8, 0x19, 0xcc, 0x4d, 0x08, 0x70, 0x02, 
		0x08, 0x28, 0x09, 0x10, 0x40, 0x0d, 0x43, 0xf8, 
		0x47, 0xc0, 0x48, 0x7f, 0xa1, 0x40, 0xa5, 0x4c, 
		0xb9, 0xd9, 0xac, 0x01, 0xad, 0x80, 0xae, 0x43, 
		0xaf, 0x01, 0xb0, 0x22, 0xbd, 0xe9, 0xc0, 0x1c, 
		0xc4, 0x20, 0xc5, 0x04, 0xca, 0x33, 0x01, 0x02
	};

But the few webpages we've seen covering the features of the device hint at an embedded (unspecified) MCU, so in theory it might be at least possible to execute firmware-code in the device.