Skip to main content

From zero to hero

Comments

Source

Tags:

A couple of years ago a friend of mine asked me to take a look at a pico projector that he had bricked during an update. He hadn't tried anything fancy or dangerous, he had simply used the internal functionality of the device. At that point in time the device was stuck in a bootloop with the Samsung logo as the only output from the projector.

I obviously accepted to take a look and in this way started a journey that lasted like five years where I learned a lot about hardware and software.

Information gathering

The device in question is the Samsung Pico Projector SP-H03, this is the product page; this item has been discontinued and from the few reviews I have seen it didn't do very well commercially.

The user manual doesn't talk about upgrading and it seems there isn't any post in the internet talking about some particular flashing mode for this device; I'm on my own to discover.

Opening the device is possible to unveil the internals: on top there is a PCB with SMD components on both the sides

but no signs of a connector for the UART: indeed my idea throughout the investigation will be to discover the serial port and find out why the system doesn't work.

From the front image I found that the main chip for this box is the TCC9101, a pratically unknown SoC used in a couple of other devices and cited in the Wikipedia page about ARM SoCs as an ARM1176JZ(F)-S, i.e. an ARMv6 architecture. Take in mind that not even the company producing the chip, Telechips, has a page specific about this chip, only cited in a page.

Firmware

Another thing available to look at is the firmware update that you can download from the official site: P-OBRNPWWC-1008.1.rom.

With my incredible skills I discovered that is a simple tar archive

$ file Pico\ SP-H03/P-OBRNPWWC-1008.1.rom 
Pico SP-H03/P-OBRNPWWC-1008.1.rom: POSIX tar archive (GNU)

containing some files

$ tar -tf Pico\ SP-H03/P-OBRNPWWC-1008.1.rom
./
./wplayer
./opt/
./opt/qt/
./opt/qt/lib/
./opt/qt/lib/libQtNetwork.so.4
./opt/qt/lib/libQtGui.so.4
./opt/qt/lib/fonts/
./opt/qt/lib/fonts/unifont_160_50.qpf
./opt/qt/lib/fonts/Oberon_chn_kor_20091217.ttf
./opt/qt/lib/fonts/langpack_cjk.dat
./opt/qt/lib/libQtCore.so.4
./pico_player
./ui/
  more stuffs
./TCCKernel7.3.rom
./setup/
./setup/reg_set.obn
./md5sum
./TCCBoot4.2.rom
./run.sh
./pico

The most promising for further investigation are TCCKernel7.3.rom and TCCBoot4.2.rom

$binwalk Pico\ SP-H03/P-OBRNPWWC-1008.1/TCCBoot4.2.rom 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

$ binwalk Pico\ SP-H03/P-OBRNPWWC-1008.1/TCCKernel7.3.rom 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
55177         0xD789          Certificate in DER format (x509 v3), header length: 4, sequence length: 1416
59013         0xE685          Certificate in DER format (x509 v3), header length: 4, sequence length: 13588
78208         0x13180         gzip compressed data, maximum compression, from Unix, last modified: 2010-07-27 01:42:34
4720605       0x4807DD        Certificate in DER format (x509 v3), header length: 4, sequence length: 5376
5024709       0x4CABC5        Certificate in DER format (x509 v3), header length: 4, sequence length: 1328
5419085       0x52B04D        Certificate in DER format (x509 v3), header length: 4, sequence length: 4866
5531093       0x5465D5        Certificate in DER format (x509 v3), header length: 4, sequence length: 1292
5702529       0x570381        Certificate in DER format (x509 v3), header length: 4, sequence length: 13588
6446763       0x625EAB        Linux kernel version 2.6.28
6477872       0x62D830        CRC32 polynomial table, little endian
6821729       0x681761        Unix path: /dev/vc/0
6834593       0x6849A1        IMG0 (VxWorks) header, size: 1111564346

looking at the strings inside you can have some clues

$ strings Pico\ SP-H03/P-OBRNPWWC-1008.1/TCCBoot4.2.rom | grep -i tele
TELECHIPS01
TELECHIPS02
TELECHIPS03
TELECHIPS04
$ strings Pico\ SP-H03/P-OBRNPWWC-1008.1/TCCBoot4.2.rom | grep -i boot
    tcboot ver %s for %s Linux
tcboot.rom
Updating tcboot.rom -> 
$ strings Pico\ SP-H03/P-OBRNPWWC-1008.1/TCCKernel7.3.rom | grep -i samsung
Samsung Oberon Board
Samsung Info. Systems America, Inc.
Samsung
SAMSUNG
$ strings Pico\ SP-H03/P-OBRNPWWC-1008.1/TCCBoot4.2.rom | grep -i usb
SIGBYAHONG_USB_MANAGER_LINUX_TCC89XX_V2.000
SIGBYAHONG_USBPHY_LINUX_TCC89XX_V2.000
SIGBYAHONG_USB_DEVICE_LINUX_TCC89XX_V2.000
MAX8903A: USB Input.

So we can deduce that the board has as codename Oberon and that is based on the TCC89XX SoC.

This SoC has a little more information (by the way, a similar named SoC, the TCC8920, is a complete different ARM revision so I don't know what to think anymore about the naming convention used by Telechips) and indeed is possible to find a torrent containing a lot of leaked materials about this family of chips (f21b0242eac7f91090eaa949c699d2bc9252ca85 is the hash of such torrent); the datasheet is comprised in the leak.

Reversing

With the datasheet in my hands I started to reversing the supposed bootloader contained in the firmware update, at first using radare2 but when ghidra has been officialy released I switched to it making easier the process.

The reversing was not strictly necessary for the process I'm describing but helped me to exercise with the assembly and to know better the peripherals available on the device. In particular after have done it I was sure that TCCBoot4.2.rom was really the bootloader.

The first problem to overcome was to understand the header and the address where the bootloader is loaded: the first thing was pretty simple since I discovered a repository containing the source code of such bootloader (it would not have been such hard to deduce the fields looking at them or via the code in the bootloader).

Looking at a few addresses called from the firmware was apparent that it loads at 0x40000000.

Knowing that, and the address mapping from the datasheet, I set the following in ghidra

that are not perfect but good enough to allow a decent reversing; part of the mapping reported in the datasheet is the following

Address space Device name
0x00000000 - 0x0fffffff remapped region
0x10000000 - 0x10003fff 16kB on-chip RAM
0x40000000 - 0x4fffffff off-chip SDRAM
0xf0000000 - 0xffffffff on-chip peripherals

moreover the peripherals memory space is partitioned like the following

Base address Peripherals
0xf0000000 Graphic bus
0xf0100000 Memory bus
0xf0200000 DDI bus
0xf0300000 Memory bus
0xf0400000 System control
0xf0500000 IO bus
0xf0600000 MMU table
0xf0700000 Video bus

It's amazing how with ghidra is possible to describe the registers that control for example the UART subsystem with a struct

and obtain a perfectly readable decompiled code

FWDN

From the reading of several documents the presence of a USB update process seems pretty solid: in the datasheet itself is cited a so called USB boot mode that works in the following way

  1. The TCC8900 makes internal SRAM area starts from zero, and copies USB interrupt service routine to internal SRAM area.
  2. It waits until USB connection is established.
  3. Once it is connected, host transfers first the parameter for USB loader routine including start address, destination address and the amount of data to be transferred (with a unit of packet).
  4. The TCC8900 starts communicating between a host PC with fixed amount of data which is called as packet. The packet size of TCC8900 is 512 bytes.
  5. At every successful reception of packet, it copies them where the destination address pointed, and after all amount of data has been copied, it starts program where the start address pointed

It's similar of what is described in the datasheet of TCC760 or that other people have found; it loads via the tcctool some code in SDRAM and executes it.

I discovered via the service manual (in chinese) that to enter in this mode you have to press a button (that is not soldered in my case) when you start the device (since the device has a touch surface with the power button on a side is a little tricky to press both at the same time)

Another approach is to short the CE pin of the NAND. What you see is a new USB device

turing kernel: usb 2-2: new high-speed USB device number 3 using xhci_hcd
turing kernel: usb 2-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
turing kernel: usb 2-2: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
turing kernel: usb 2-2: New USB device found, idVendor=140e, idProduct=b077
turing kernel: usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
turing kernel: usb 2-2: USB disconnect, device number 3

Modifing the code of tcctool, adding the correct VID:PID values and other minor modifications, I was able to execute code in the board and I started to write a piece of assembler code to toggle all the GPIO pins in order to find out where the serial was located on the board. There are 6 banks of GPIO with up to 32 pins each and to discover which GPIO corresponds to a given pin I driven it with a PWM signal having \(\hbox{bank} << 5\, |\, \hbox{id} \) cycles.

This below is the code

; https://stackoverflow.com/questions/6139952/what-is-the-booting-process-for-arm
    .text
    .align  2
    .syntax unified
    .arm
    .fpu softvfp
    .type   __entry, %function
    .type   enable_watchdog, %function
    .type   gpio_identification, %function
    .type   gpio_signal, %function
    .type   watchdog_clear, %function
    .type   _delay, %function
/*
 * Since we have not stack available for now (no hard constraint, we are only lazy)
 * we call routines and use r10, r11 and r12 as temporary registers to save lr.
 *
 * KEEP IN MIND THE LEVEL OF NESTING A FUNCTION IS CALLED!
 */
__entry:
    bl enable_watchdog
gpio:
    bl gpio_identification @ uses r10
    bl watchdog_clear
    b gpio

.set  EN, (1<<0)
.set IEN, (1<<3)
.set TCKSEL, (1<<4)
.set WATCHDOG_EN, (1<<31)
.set WATCHDOG_CLR, (1<<30)

enable_watchdog:
    mov r10, lr
    ldr r3, .TWDCFG
    ldrb    r4, [r3]
    orr r4, r4, #(EN | IEN)
    strb    r4, [r3]
    ldrb    r4, [r3]
    bic r4, r4, 0x30 @ clear the TCKSEL
    orr r4, r4, 0x40 @ set the TCKSEL to 0x04
    strb    r4, [r3]
    ldr r3, .TWDCLR_ADDR
    mov r4, #0x00000000
    str r4, [r3]
    ldr r3, .WATCHDOG_ADDR
    ldr r4, [r3]
    orr r4, r4, #WATCHDOG_EN
    str r4, [r3]
    mov lr, r10
    mov pc, lr

watchdog_clear:
    mov r12, lr
    ldr r0, .WATCHDOG_ADDR
    ldr r1, [r0]
    orr r1, r1, #WATCHDOG_CLR
    str r1, [r0]
    mov lr, r12
    mov pc, lr

.CONTROL_ADDR:
    .word   0xf0404000
.TWDCFG:
    .word   0xf0403070
.TWDCLR_ADDR:
    .word   0xf0403074
.WATCHDOG_ADDR:
    .word   0xf040400c

.set CONTROL_POFF, (1<<1)

power_off:
    ldr r3, .CONTROL_ADDR
    ldr r4, [r3]
    orr r4, r4, #CONTROL_POFF
    str r4, [r3]
/*
 * This function outputs via the GPIO, passed as the couple (group, idx)
 * its encoded identifier as a 32 bit number.
 *
 *  r8: group in [0, 5]
 *  r9: idx in [0, 31]
 *
 * so we need a number of bits to encode 6*32 = 192 values, i.e. 8bit are enough,
 * but we can use all 32-bit so that we have a start/stop pattern clearly
 * identifiable.
 *
 */
.set GPIO_GROUP_OFFSET,  0x40
.set GPIO_GPxDAT_OFFSET, 0x00
.set GPIO_GPxEN_OFFSET,  0x04
.set GPIO_GPxCLR_OFFSET, 0x0c
.set GPIO_GPxXOR_OFFSET, 0x10
.set GPIO_GPxPD0_OFFSET, 0x1c
.set GPIO_GPxPD1_OFFSET, 0x20
.set GPIO_GPxFN0_OFFSET, 0x24
.set GPIO_GPxFN1_OFFSET, 0x28
.set GPIO_GPxFN2_OFFSET, 0x2c
.set GPIO_GPxFN3_OFFSET, 0x30
gpio_signal:
    mov r11, lr                     @ save the return pointer
    /* initialize the GPIO requested in OUTPUT mode */
    ldr r3, .GPIO_REGISTER_MAP_ADDR
    mov r7, #GPIO_GROUP_OFFSET
    mul r4, r8, r7
    add r5, r3, r4                 @ r5 points at the start of the right GPIO group address
    add r6, r5, #GPIO_GPxEN_OFFSET @ r6 points to the direction control
    mov r7, #1
    lsl r7, r9                     @ r7 contains the pattern for the right GPIO to be activated
    str r7, [r6]                   @ set OUTPUT MODE
    /* set pull-down */
    add r6, r5, #GPIO_GPxPD0_OFFSET
    ldr r3, .GPIO_PULL_DOWN
    str r3, [r6]
    add r6, r5, #GPIO_GPxPD1_OFFSET
    ldr r3, .GPIO_PULL_DOWN
    str r3, [r6]
    /* and set function mode to 0 */
    add r6, r5, #GPIO_GPxFN0_OFFSET
    mov r3, #0
    str r3, [r6]
    add r6, r5, #GPIO_GPxFN1_OFFSET
    mov r3, #0
    str r3, [r6]
    add r6, r5, #GPIO_GPxFN2_OFFSET
    mov r3, #0
    str r3, [r6]
    add r6, r5, #GPIO_GPxFN3_OFFSET
    mov r3, #0
    str r3, [r6]

    /* from now on, we need to loop over the encoding */
    orr r4, r9, r8, LSL #5         @ r4 contains the number of cycles to toggle the GPIO
    mov r3, #0                     @ this will be our counter
    add r6, r5, #GPIO_GPxXOR_OFFSET @ r6 points at the GPxXOR register
_loop_over_encoding:
    str r7, [r6]                   @ we toggle the corresponding register
    ldr r0, .DELAY_VALUE
    bl _delay
    str r7, [r6]                   @ twice so to have a square wave
    bl _delay
    cmp r3, r4
    add r3, r3, #1
    bne _loop_over_encoding

    /* now set to zero the GPIO */
    add r6, r5, #GPIO_GPxCLR_OFFSET
    str r7, [r6]

    /* return at home */
    mov lr, r11
    mov pc, lr
.DELAY_VALUE:
    .word   0xf
.GPIO_REGISTER_MAP_ADDR:
    .word   0xf0102000
.GPIO_PULL_DOWN:
    .word   0xaaaaaaaa
.set GPIO_GROUPS_N, 0x06
.set GPIO_IDX_N,    0x20

gpio_identification:
    mov r10, lr

    mov r8, #0
_loop_group:
    mov r9, #0
_loop_idx:
    bl  gpio_signal
    add r9, r9, #1
    cmp r9, #GPIO_IDX_N
    bne _loop_idx
    add r8, r8, #1
    cmp r8, #GPIO_GROUPS_N
    bne _loop_group

    mov lr, r10
    mov pc, lr

/* takes r0 as number of loop to wait
 * internally uses r1 and r2
 */
_delay:
    mov r2, lr
    mov r1, #0x00
_loop_delay:
    cmp r1, r0
    add r1, r1, #1
    bne _loop_delay
    mov lr, r2
    mov pc, lr

I also wrote a program to help me debug the code I was using (I would call it emulator but it simply allocates the memory where to execute the firmware at the same address of the real device and then jumps into it, this is inspired from the work of Travis Goodspeed with the MD380). Obviously you need qemu to emulate the correct ARM architecture in a desktop.

This is the code:

/*
 * Loads and executes code wannabe running on a TCC8900 chips allocating
 * memory to emulate peripherals' memory.
 *
 * You can use this with Qemu.
 *
 *  $ export QEMU_LD_PREFIX=/usr/arm-linux-gnueabi
 *  $ qemu-arm -cpu arm1176 -g 4444 tcc-emu tccvirus.bin
 *
 * and from another terminal
 *
 *  $ gdb-multiarch tccvirus
 *
 * Magically all the symbols will be visible from GDB!
 */
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>


#define GPIO_MEMORY_ADDR 0xf0100000
#define GPIO_SIZE 0x400000

#define FIRMWARE_MEMORY_ADDR 0x00001000


void usage(const char progname[]) {
    fprintf(stderr, "usage: %s <firmware.bin>\n", progname);
    exit(1);
}


int main(int argc, char* argv[]) {

    if (argc < 2) {
        usage(argv[0]);
    }

    char* filepath = argv[1];

    struct stat file_info;
    int retVal = stat(filepath, &file_info);

    if (retVal == -1) {
        perror("I could not stat file");
        goto fatal;
    }

    void * gpio = mmap((void*)GPIO_MEMORY_ADDR, GPIO_SIZE, PROT_READ | PROT_WRITE , MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

    if (gpio == MAP_FAILED) {
        perror("allocate gpio failed");
        goto fatal;
    }

    int fw_fd = open(filepath, O_RDONLY);
    if (fw_fd == -1) {
        perror("I could not open file");
        goto fatal;
    }

    void* (*firmware)();

    firmware = mmap((void*)FIRMWARE_MEMORY_ADDR, file_info.st_size, PROT_READ | PROT_EXEC , MAP_FIXED | MAP_PRIVATE, fw_fd, 0);

    if (gpio == MAP_FAILED) {
        perror("allocate firmware failed");
        goto fatal;
    }

    fprintf(stderr, "-- Executing firmware at address 0x%08x--\n", FIRMWARE_MEMORY_ADDR);
    firmware();
fatal:

    return 0;
}

After a couple of bug fixed I was able to look for the GPIOs: I used my oscilloscope to touch each pin exposed on the PCB and finally I find out the pinout of the UART interface: it's located in the connector CN1101 with pin 6, 7, 8 as indicated in picture

Connecting to it with a baud of 115200 I was greeted with the following bootlog

LED Driver init.
TSADC init.
MAX8903A: DC Input.
MAX8903:DC = 1
␛[1;34m DC Input Mode! ␛[0m 
NAND: V7018
[NAND        ] [PORT CONFIG - CS[0, 1] [NAND Data Port: GPIO_B Hw4 ~ Hw11]
[NAND        ] [BClk 156MHZ][1Tick 65][RE-S:0,P:7,H:4][WR-S:0,P:5,H:4][COM-S:2,P:15,H:15]
[NAND        ] [NB Area:4MB][DT Area:931MB][HD Area0:9MB][HD Area1:9MB]

=============================================
    tcboot ver 0.5 for TCC8900 Linux
    Board ver TCC8900_WINCE_LINUX_DEMO
    DATE:Jul 12 2010, TIME:13:11:27
=============================================
CHIP ID: 0x0000000E0DD3C3B0
CLOCK: PLL0:540, PLL1:560, PLL2:468, PLL3:528, CPU:506, BUS:280  
       DDI:264, GRP:0, IOB:156, VBUS:0, VPU:0, SMU:117
LCD: Post Parallel Device Initialize..
DLP260X_Done Wait count = 1 msec 
emu_done reset = 0x1, ret = 0x1 
MAX8903A DC input =1 
DPP260X Initialize Success!
DLP : 854X480 RGB888 Mode
DPP260X Current Red=0x32A,Green=0x32A,Blue=0x32A
FWDN: checking...
Loading...
length = 0x67C000, CRC = 0xFC025306
Load Ok! Jump to 0x40300000 (0xEA000016)

Linux version 2.6.28 (phking@linux-hth0) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #3 Mon Jul 12 13:28:17 KST 2010
CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Samsung Oberon Board
Warning: bad configuration page, trying to continue
Memory policy: ECC disabled, Data cache writeback
create_mapping:0x40200000->0xc0000000(0x5000000)
create_mapping:0x402a9000->0xffff0000(0x1000)
create_mapping:0xf0000>0xf0000000(0x100000)
create_mapping:0xf0100000->0xf0100000(0x100000)
create_mapping:0xf0200000->0xf0200000(0x100000)
create_mapping:0xf0300000->0xf0300000(0x100000)
create_mapping:0xf0400000->0xf0400000(0x100000)
create_mapping:0xf0500000->0xf050000000000)
create_mapping:0xf0600000->0xf0600000(0x100000)
create_mapping:0xf0700000->0xf0700000(0x100000)
create_mapping:0x10000000->0xeff00000(0x100000)
Serial Number: 0000000e0dd3c3b0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages20
Kernel command line: console=ttySAC0 lpj=2523136 initcall_debug=0   mem=80M
tcc8900_irq_init
PID hash table entries: 512 (order: 9, 2048 bytes)
 ### CORE CLOCK (506250000 Hz), BUS CLOCK (280000000 Hz) ###
Console: colour dummy device 80x30
console [ttySAC0] enabled
Dentry cache hash table entries: 16384 (ord4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
_etext:0xc0762000, _text:0xc04f5000, _end:0xc07a5db8, __data_start:0xc0762000, __init_end:0xc04f5000, __init_begin:0xc0100000
Memory: 80MB = 80MB total
Memory: 74240KB available (2484K code, 271K data, 4052K init)
Calibrating delay loop (skipped) preset value.. 504.62 BogoMIPS (lpj=2523136)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 288 bytes
NET: Registered protocol family 16
attached TCC adc driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
Telechips Dynamic Power Management.
NetWinder Floating Point Emulator V0.97 (double precision)
fuse init (API version 7.10)
msgmni has been set to 145
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler cfq registered (default)
i2c /dev entries driver
tcc-i2c tcc-i2c: i2c-0: I2C adapter
cs42l52_i2c_probe: 
fb[0]::map_video_memory: dma=45200000 cpu=c6000000 size=00800000
fb0: tccfb frame buffer device
fb[1]::map_video_memory: dma=45a00000 cpu=c7000000 size=00400000
fb1: tccfb frame buffer device
fb[2]::map_video_memory: dma=45e00000 cpu=c7800000 size=00400000
fb2: tccfb frame buffer device
tcc proc filesystem initialised
OBERON_PWR Driver
oberon_p5v_control: onoff = 1 
Obenron MAX8903A Driver
Battery Voltage = 0.4 
MAX8903A: DC Connected!
Obenron TW8816 Driver
tcc_intr: init (ver 2.1)
tcc_pwm: init (ver 0.1)
Obenron DPP260x Driver
DPP260X Check ID Success!.. 
Obenron TCC_WDT Driver
OBERON_MEM Driver
Obenron OBERON_LEDS Driver
TimerX init(TX-Timer0).
tcc8900-uart.0: tcc-uart0 at MMIO 0xf0532000 (irq = tcc8900-uart.1: tcc-uart1 at MMIO 0xf0532100 (irq = loop: module loaded
TRACE: DPM is now installed
Driver 'sd' needs updating - please use bus_type methods
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
dwc_otg: version 2.60a 22-NOV-2006
DWC_otg: Internal DMA Mode...
DWC_otg: Dedicated Tx FIFOs mode
DWC_otg: Using DMA mode
dwc_otg dwc_otg.0: DWC OTG Controller
dwc_otg dwc_otg.0: new USB bus registered, assigned bus number 1
dwc_otg dwc_otg.0: irq 48, io mem 0x00000000
DWC_otg: Init: Port Power? op_state=1
DWC_otg: Init: Power Port (0)
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
mice: PS/2 mouse device common for all mice
Oberon GPIO Keypad Driver...
input: Oberon keypad as /class/input/input0
TCC RTC, (c) 2009, Telechips 
tcc-rtc tcc-rtc: rtc core: registered tcc-rtc as rtc0
tcc-sdhc1: init
Set ID to device mode
Advanced Linux Sound Architecture Driver Version 1.0.18rc3.
ASoC version 0.13.2
TCC89XX  cs42l52 ALSA SoC driver ver1.1 10/2008
asoc: CS42L52 <-> tcc-i2s mapping ok
CS42L52: Cirrus CS42L52 codec , revision 3
soc_cs42l52_write: Can't set Limiter 
ID change ISR : Device
DWC_otg: Internal DMA Mode...
soc_cs42l52_setup: <Mono Speaker out>.
DWC_otg: USB RESET
CS42L52: Cirrus Logic ALSA SoC codec cs42l52 driver verison 1.1 10/2008
ALSA device list:
  #0: TCC89XX (CS42L52)
TCP cubic registered
NET: Registered protocol family 17
VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
tcc-rtc tcc-rtc: hctosys: invalid date/time
DWC_otg: Internal DMA Mode...
hp_detect_work:  SPK Sound 
oberon_volume = 0, highlow=1 
init started:  BusyBox v1.4.2 (2010-05-20 22:17:07 KST) multi-call binary
Starting pid 352, console /dev/console: '/etc/init.d/rcS'
run /etc/init.d/rcS 
mdev init: ...
TCC8900_nand: module license 'Proprietary. (C) 2008 Telechips Inc.' taints kernel.
Dumy-Ready Interrupt-!!!!!!!!!!!!!!!!
[NAND        ] [PORT CONFIG - CS[0, 1] [NAND Data Port: GPIO_B Hw4 ~ Hw11]
[NAND        ] [BClk 156MHZ][1Tick 65][RE-S:0,P:7,H:4][WR-S:0,P:6,H:4][COM-S:2,P:15,H:15]
[NAND        ] [NB Area:4MB][DT Area:931MB][HD Area0:9MB][HD Area1:9MB]
 ndda: ndda1 ndda2 ndda3
[tcc_nand] init ndd(TCC8900, V7018)
[tcc-gadget]fsg_init start
[tcc-gadget]fsg_bind start
fsg_bind: gadget->name = dwc_otg_pcd 
usb_gadget_controller_number: gadget->name = dwc_otg_pcd 
g_file_storage gadget: File-backed Storage Gadget, version: 7 August 2007
g_file_storage gadget: Number of LUNs=1
[tcc-gadget]fsg init end
pwd = /
OBERON Update Script(pre)....
[Update File Check] Update Files Not Exist...
dosfsck_check pwd=/
[/usr/sbin/dosfsck] /dev/ndda1 .. ok
dosfsck_check pwd=/
[/usr/sbin/dosfsck] /dev/ndda2 .. ok
dosfsck_check pwd=/
[/usr/sbin/dosfsck] /dev/ndda3 .. ok
Starting pid 427, console /dev/ttySAC0: '/bin/sh'
/ #

and finally the shell. To my surprise the problem was that the user partition was empty, so simply untarring the update file into the root of the filesystem fixed the problem my friend had. Fortunately it is possible to insert a SD card with the update in it into the device and see it mounted in /media otherwise I would had to upload it using the serial with a my script (but it is very slow).

This wraps up this post: at end I'm very happy of what I obtained and there is space for further work on this device:

  • dump of the boot ROM
  • complete the mapping of the pins creating a plugin for sigrok that can decode what GPIO is
  • write an application to update the firmware directly using the FWDN protocol (here some notes about that).

If you interested I have a repository with this and a couple of other devices that I analyzed during the years.

Comments

Comments powered by Disqus