Wiki > Main > Rockchip27xx (compare)
Difference: Rockchip27xx (r21 vs. r20)
-- MarcinBukat - 2010-05-01
Fuzhou Rockchip Electronic produce a few families of SoC for portable devices. There are some technical documents floating around for RK27xx family which makes it possible platform for rockbox.
RK27xx SoC components:
There are variety of generic devices build around this SoC. They share many similarities like around 3" touch display, microSD slot, 2,4,8,16,32 GB of internal flash (usually referred as Samsung flash). Below You will find a few pictures:
This features a RK2708 SoC, 2x 4 GB flash, 2.8" 320x240 TFT, micro SD card slot, built-in speaker, TV-Out, 1.3MP camera and FM Radio. The firmware extracting methods described below don't work. The device can be put into DFU mode (at least the vid:pid changes to 0x71b:0x3201), but rk27load (as of r30207) fails on stage1 upload.
Firmware files are stored on separate, not exposed by default, system partition. In order to make this system partition visible one can put empty file with "magic" name in the root dir of the DAP. The most generic one seems to be RKLDSET.FLW (other possibilities are rkusb.tag, frk.tag, telecast.tag, telecast.sys). After placing such file in the root dir of the player, safely disconnect the device and unplug it from PC. Plugging it again should give you two drives - the main one (few GB in size) and system one (60-90MB in size). PLEASE BE EXTREMELY CAREFUL and do not delete files form system partition unless you know what you are doing. Removing "magic" file restore default behavior and system partition is not visible. There seem to be custom scsi commands which yield the same effect.
The device start execution from 8kB bootrom (base 0x0). The bootrom searches for valid bootloader on nand flash starting from page 0. Data on the flash are stored in 512 bytes chunks followed by 16 bytes of metadata which will be referred as sectors later on. Bootrom checks the presence of magic string 0x55 0xAA 0xF0 0x0F and additionally checks if 3rd byte in metadata equals 0x69 at the beginning of every 64th page (it moves up to 50 times). If checks are passed, rom assumes the following data structure has been found:
ID block 0
ID block 1
ID block 0 is encrypted with RC4 encoding, ID block 1 is plain binary. ID block 2 and 3 seem to be unused (reserved for future extensions???). Values are stored in little-endian format.
First sector indicated by the 1st stage offset should contain dram initialization binary and is marked with magic 0x52 0x4B 0x32 0x37 ('RK27') at offset 0x1F8 (sector relative). The bootrom copies this initialization image to the buffer at 0x18200E00, executes dram init routine and returns. The rest of the bootloader image is loaded at 0x60000000 (begining of the DRAM) up to the indicated size in the header. Finally bootrom passes control to the loaded bootloader or in case something went wrong with reading bootloader from flash, bootrom falls back to usb DFU mode described in following section. Both dram init image and nand bootloader itself are stored in RC4 encoded form.
The flash bootloader relocates itself at 0x60700000 and loads BASE.RKW file from the system partition and passes control to the actual firmware. An entrypoint for image stored in BASE.RKW is at 0x60000000. The bootloader supports also USB in MSC mode for both user and system partiton as well as supports custom scsi commands.
There seem to be a few copies of the bootloader in consecutive flash blocks at the beginning of the nand (5 on the device I own).
rk27xx has some sort of DFU mode. The handler for this mode sits in 8kB SoC bootrom at address 0xAF0. The device in DFU mode has VID:PID = 0x71b:0x3201. Rockchip provides dedicated drivers for this mode as well as repair tool (RK27DM?.exe). This tool loads some binary blobs to the device from Rock27Boot?.bin file by means of usb control transfer. You can inspect the content of this binary blobs with help of rkboottool I have written. First image is sdram init and is running from iram. Second image is usb transfer handler for bulk transfers and is running from sdram (load base 0x60000000). The second stage is quite interesting - It has simple encrypt/decrypt based on XOR routine to decode blobs as well as some crc checking. Further transfers are handled by this routines and are of bulk type.
Datasheet floating around is misleading in section concerning clocks setup. SCU_DIVCON1 register bit2 selects the way ARMclk and HCLK are derived. If this bit is cleared ARMclk equals PLL out and HCLK equals PLL out/2. If this bit is set both ARMclk and HCLK are equal PLL out/2. Measurements show that SDRAM performance is related to HCLK (but not quite directly). Synchronous ARM:HCLK gives worst ram throughput than async setting with the same AHB bus frequency. LCD framerate is also related to HCLK.
Nand controller uses BCH codes for error correction. It uses m=13, t=8, gen_poly=0x25af. Bits order is reversed in each input byte. 13 output bytes are reversed again and then xor'ed with masking polynomial 0x4e, 0x8c, 0x9d, 0x52, 0x2d, 0x6c, 0x7c, 0xcb, 0xc3, 0x12, 0x14, 0x19, 0x37 so empty nand page gives all 0xff.
r28 - 11 Oct 2013 - 06:19:11 - MarcinBukatRevision r21 - 02 Apr 2012 - 16:00 - MarcinBukat
Revision r20 - 14 Mar 2012 - 08:13 - MarcinBukat
Copyright © by the contributing authors.