Chitech CT-PC89E

Current status: GPL Violation by Chitech. Communication has ceased by Chitech. Chitech have not responded to or acknowledged communications since 20th March 2010.

Current kernel reverse-engineering status: partial (useable). Screen, USB, Keyboard, Mouse, Ethernet are all working (proviso: with the DS2431 EEPROM storing the MAC code and no driver for reading it yet, a random MAC is currently created on each boot)

Current Debian-Installer status: success! completed!

Current u-boot reverse-engineering status: not started yet. hardware "switch" discovered which makes booting from external SDcard possible. u-boot reverse-engineering can now begin (without risk of bricking)

The CT-PC89E is a low-cost netbook with an 8.9in 1024x600 screen, weighing only 720 grammes (0.72kg). In size it's approximately 23.5 x 16.5 x 2.5 cm (9.25 x 6.5 x 1 in). Its 667mhz Samsung S3C6410 embedded ARM CPU is on a factory-upgradeable SO-DIMM which also has, in the standard low-cost option, 256mb of RAM and 2gb of NAND Flash. The rest of the features are pretty much "standard" fare for a low-cost netbook: 2x USB2, stereo speakers, microphone, SD-Card slot, headphone and microphone sockets, and 802.11 WIFI. A low-cost (0.3mp) built-in Webcam is available as an option ($USD 2 for a 20,000 units order). To further save on cost, there is a micro VGA output, but by default the IC to enable it is again optional (again, $USD 2 for a 20,000 order). Also, the design has two internal USB2-capable (only) PCI-express slots, which can take 50x30mm PCI-e cards. One is occupied with the RALink RT2070 WIFI, whilst the other is designed to take a 3G or an EDGE modem: there is even a slot for a SIM card (next to the SD card slot).

As this machine is very new, only a few brave Debian-ARM souls have bought it so far, direct from the factory in China, in order to evaluate it and help re-engineer it. We're aware that one other U.S. customer has ordered a batch of them, thus guaranteeing its production over the next few months (as of Feb 2010). The nice surprise is that far from being truly dreadful, the embedded OS on the device, from http://mid-fun.com is actually pretty good: it's called MOS and the web site is here: http://mid-linux.org. As of yet, we've been unable to reach Mid-Fun to get them to provide the root password and the GPL source code of the OS, but that's okay because we've discovered three security flaws in two days, each of which gives full root access to the machine. (24feb2010: by running "john" on the DES64/64 root passwd entry, we've established that the root password is mos2010)

Also worth noting: we're currently asking the factory for a price on engineering an SO-DIMM with 512mb of DDR2 RAM and an 833mhz Samsung ARM Cortex A8: the S5PC100, which is the same CPU as used in the iPhone 3G. This would ironically not only reduce the price of the system, because DDR1 RAM is actually more expensive than DDR2, but also give it a huge performance jump, without increasing power consumption (the S5PC100 is a 45nm part and the S3C6410 is 65nm).

From this it's been possible to establish that the kernel version is similar to the SmartQ5 MID device, version 2.6.24.7. current status as of 12mar2010 is that boot has been achieved, using the above information, with DM9000 and USB host still not yet correctly initialised.

Kernel Hacking Progress

We're presently negotiating with Chitech, who have officially declined to release kernel source code, and all other source code, on the usual basis that they want their money back from the investment so far, in blatant disregard of the GPL and LGPL licenses. Thus it is necessary to reconsider Chitech until such time as they comply, and thus it is necessary to reverse-engineer the linux kernel and the boot process.

kernel

fjp and lkcl have been working to adapt the mer-smartq 2.6.24.7 kernel, which is an amalgam of 2.6.24, samsung's patch and various modifications hard-coded to support the smartq 4in and 7in LCD screens. lkcl has a legally-licensed copy of IDApro and has been using that to reverse-engineer the kernel functions, taking the addresses from /proc/kallsyms on a running machine and matching them to an uncompressed kernel.

So far we have been able to get the 1024x600 LCD panel up and running, and have hacked kernel/printk.c to modify the console line to "tty1" in order to bypass the inability to use ttySAC0 serial console, for debug purposes.

The key hardware that is missing which would make a useful kernel is the GL850G USB hubs. It has not yet been possible to establish how those are fired up. Close examination of the PCB shows that there is nothing connected to Pin 13 (RESET); the next best guess is that there are some GPIOs which are required to be pulled HIGH or LOW, in order to power the GL850Gs.

The Ethernet DM9000 appears to be identical to the standard samsung developer kit: the default parameters worked immediately. However, the MAC address is stored in a DM2431. We have found a patch to the w1 driver which adds support for DM2431, however have not yet used it. Further investigation shows that the SO-DIMM, designed by Seatron, has the DM2431 connected to GPIO Bank N pins, and thus the driver performs bit-level reads and writes using GPIO pullups followed by sleep commands of specific length. There are signs of some extremely weird functions in the disassembly listing, with SHA-1 being used and functions with the word "Secret" in them are not a particularly good sign. It looks like the DM2431 is being used to store keys which are believed to somehow magically be secure.

__apm_get_power_status

this function has been hacked to read from the S3C ADC. GPIO bank N pin 2 is set to cfgpin of 0 and pullup of 0, following which a function GetAdcValue is called. it is therefore quite likely that the ADC input is multiplexed for multiple purposes. there appears to be no sign of mutex locking or configuration around the GPIO bank N pin setting, thus making it entirely likely that corrupted values will be read due to race conditions.

s3cfb_set_brightness

the s3cfb_set_brightness function uses a PWM timer, s3c6410_timer_setup channel 0, which uses GPIO Bank F, Pin 14, as a PWM. this timer is botch-reset in the arch_reset() function, which has been hacked about and _should_ be using the watchdog timer, but is not.

arch_reset

arch_reset, in include/asm-arm/arch-s3c2410/system.h, should be used to do a watchdog reset. instead, it has been hacked about to reset GPIO Bank H Pin 8 and GPIO Bank F Pin 14 (the PWM for the backlight).

initrd

So far we have been able to establish that the standard bootpImage boot process works absolutely fine. This has been established by

unpacking the zImage_dt_update with dd if=zImage_dt_update of=vmlinuz_zimage_update bs=1 skip=13428 followed by zcat

extracting the initrd by searching for a 2nd zcat signature, which is at offset 78848