2011-05-30 21:10:43 +00:00
|
|
|
This is the collection of small utilities needed to hack Rockchip rk27xx
|
|
|
|
series based DAPs. This tools were tested on linux only.
|
|
|
|
|
|
|
|
|
|
|
|
rk27load
|
|
|
|
This directory contains tool which can send arbitrary image(s) to the device
|
|
|
|
in rockchip recovery mode (VID:PID 0x071B:0x3201).
|
|
|
|
|
|
|
|
The first image can not exceed 510 bytes (+2 bytes checksum) and entry
|
|
|
|
point is 0x18020e00. Usually this code is used to configure SDRAM controller.
|
|
|
|
One can use first stage image extracted from Rock27Boot.bin file (a bit
|
|
|
|
more sofisticated) or the one provided in rk27load/stage1 directory.
|
|
|
|
|
|
|
|
The second image is loaded at the begining of the dram (0x60000000)
|
|
|
|
and executed. For some reason (which is still unclear) the size of
|
|
|
|
2nd stage image is limited to about 3-4 kB.
|
|
|
|
|
|
|
|
You can find example of custom 2nd stage image in rk27load/stage2 directory.
|
|
|
|
The purpose of this image is to configure bulk transfer and allow to
|
|
|
|
load usercode without size restriction mentioned above (the max size
|
|
|
|
is 8MB actually). The entry point of usercode is 0x60000000.
|
|
|
|
|
|
|
|
You need libusb 1.0 + header files in order to compile this utility.
|
|
|
|
You need working arm-eabi crosscompiler in order to compile stage1/stage2
|
|
|
|
bootloader binaries (but You should have one already if You tinker whith this)
|
|
|
|
|
|
|
|
|
|
|
|
rkboottool
|
|
|
|
This directory contains tool which allows to extract (and decrypt) images
|
|
|
|
stored in Rock27Boot.bin recovery file.
|
|
|
|
|
|
|
|
|
|
|
|
rkusbtool
|
|
|
|
This directory contains tool which sends custom scsi commands to the
|
|
|
|
rockchip player.
|
|
|
|
|
|
|
|
You need libusb-1.0 + header files in order to compile this utility.
|
2013-09-02 10:35:47 +00:00
|
|
|
|
|
|
|
nandextract
|
|
|
|
This directory contains quick and dirty tool which allows to extract
|
|
|
|
nand bootloader from raw dump of the first nand block. The main reason
|
|
|
|
I post this tool is to somewhat document error correction scheme used by
|
|
|
|
rk27xx chip. The tool implements BCH error correction processing with
|
|
|
|
help of bch library taken from linux kernel (and slightly modified to
|
|
|
|
compile standalone). Error correction is SUPER important as the nands used
|
|
|
|
in cheap rk27 players have quite high error rates.
|
|
|
|
|
|
|
|
Nand controler in rk27xx chip implements hw BCH error correction engine.
|
|
|
|
The documentation is lacking so this info was obtained from RE and
|
|
|
|
various other sources.
|
|
|
|
The data on the nand is stored in 528 bytes long chunks - 512 bytes
|
|
|
|
of actual data followed by 3 bytes of metadata (used by FTL layer to mark
|
|
|
|
special sectors) followed by 13 bytes of BCH ECC. BCH algorithm
|
|
|
|
uses m=13, t=8 and primitive polynomial 0x25af. Special masking
|
|
|
|
is used such as empty sector (with all 0xff) gives all 0xff ECC bytes.
|
|
|
|
Quoting e-mail from Ivan Djelic (the author of bch lib in linux):
|
|
|
|
To summarize, the steps needed to compute the rk27xx ecc are the following:
|
|
|
|
1. Reverse bits in each input byte
|
|
|
|
2. Call encode_bch()
|
|
|
|
3. Reverse output bits in each computed ecc byte
|
|
|
|
4. Add a polynomial in order to get only 0xff ecc bytes for a blank page
|
|
|
|
For more details you need to read the code.
|
|
|
|
|
|
|
|
Another quirk is that rom loader assumes that there are 4 sectors in each
|
|
|
|
nand page. This is actually not true for newer nand chips with page size
|
|
|
|
bigger then 2k. That means that on newer 4k page chips only first half of
|
|
|
|
every page is used in nand bootloader area. This is for compatibility reasons
|
|
|
|
most probably.
|
|
|
|
|
|
|
|
Finally, every 512 bytes block of data is encoded with rc4 algorithm.
|
|
|
|
The key and routine were recovered from rk27xx rom dump by AleMaxx.
|