[TOOL] rkflashtool for Linux and rk2808, rk2818 and rk2918 based tablets

ivop · Oct 2, 2011

Hi,

Because I don't run Windows nor NetBSD, I rewrote rkflash from scratch with the use of libusb-1.0, so you can now read and write your rk2818-based tablet's flash memory under Linux (also w/o the need to root your tablet). Credit for reverse-engineering the protocol goes to the original author of rkflash (see source).

Small guide

- unzip the file
- compile

Linux (Debian, Ubuntu, ...)

Code:

sudo apt-get install libusb-1.0-0-dev
gcc -o rkflashtool rkflashtool.c -lusb-1.0 -O2 -W -Wall -s

Mac OS X (thanks to surfer63, binary here)

Code:

sudo port install libusb
gcc -I/opt/local/include -I/opt/local/include/libusb-1.0 \
-L/opt/local/lib -o rkflashtool rkflashtool.c -lusb-1.0 -O2 -W -Wall

Preparation
- powerdown your tablet
- disconnect all cables

To get into flash mode differs for many tablets. Google around or use trial and error

- insert the USB cable in computer
- hold vol+ (or put on/off/locked-switch in the locked position)
- insert the other end of your cable in the tablet
- wait a few seconds
- release vol+

Now if you run lsusb, the following line should appear:

Bus 001 Device 044: ID 2207:281a (290a for rk2918 based tablets)

Bus and device number may be different. The screen of your tablet stays black.

The USB device must be readable and writable for the user running rkflashtool. If that's not the case, you'll see an error like this:

Code:

$ ./rkflashtool b
libusb couldn't open USB device /dev/bus/usb/001/048: Permission denied.
libusb requires write access to USB device nodes.
rkflashtool: fatal: cannot open device

This can be fixed in several ways (chmod, run as root, udev rules) but that's beyond the scope of this posting. For now, chmod 666 the device mentioned in the error message.

Usage of rkflashtool

Code:

$ ./rkflashtool
rkflashtool: fatal: usage:
	rkflashtool b                   	reboot device
	rkflashtool r offset size >file 	read flash
	rkflashtool w offset size <file 	write flash

	offset and size are in units of 512 bytes

On my tablet, the boot partition starts at offset 0x8000 (in blocks of 512 bytes)
Its size is 0x2000 blocks
To backup the partition, issue:

Code:

$ ./rkflashtool r 0x8000 0x2000 >boot.img.backup
rkflashtool: info: interface claimed
rkflashtool: info: reading flash memory at offset 0x00008000
rkflashtool: info: reading flash memory at offset 0x00008020
.......
rkflashtool: info: reading flash memory at offset 0x00009fe0

To write a new boot.img or an old backup back to the device:

Code:

$ ./rkflashtool w 0x8000 0x2000 <boot.img.backup
rkflashtool: info: interface claimed
rkflashtool: info: writing flash memory at offset 0x00008000
rkflashtool: info: writing flash memory at offset 0x00008020
.......
rkflashtool: info: writing flash memory at offset 0x00009fe0

You can find a list of all partitions of your tablet in the HWDEF file, which is inside the update.img for your tablet. If no such file is available, you can also look at /proc/cmdline on a running device (either through adb or a terminal app running on the device itself). Depending on the tablet, you might need root access to view /proc/cmdline. Another option is dumping the first 0x2000 blocks of nand flash by issuing rkflashtool r 0x0000 0x2000 >parm. View the file with hexedit, xxd, or a similar program. The kernel parameters contain a description of several mtd partitions (sizes and offsets).

After reading and writing at will, you can reboot your tablet by issuing
./rkflashtool b

Note that if your tablet has an on/off/locked-switch and it is still in the locked position, rebooting won't work.

If the file you are writing is smaller than the specified size, the rest is padded with zeroes. If it's bigger, it will be truncated. This is different from rkflash, which will overwrite blocks beyond the partition size.
rkflashtool does not support flashing a new bootloader directly.
If you have a different tablet, please try rkflashtool b and r first before flashing (w) something new.
Standard DISCLAIMER with regard to bricking your tablet applies.

Enjoy!

EDIT: better build instructions, clean up text
EDIT2: works on rk2918 tablets too (tested on Arnova 7 G2) if you change the USB product id from 0x281a to 0x290a before compilation
EDIT3: released version 2 of rkflashtool. now supports rk2918 tablets out of the box. if it doesn't find one, it falls back to rk2808/rk2818. also, updated the wording a bit.
EDIT4: new mac osx binary
EDIT5: more ways to find offsets and sizes of partitions on your tablet

EDIT6: small emphasis changes above and...

version 1 is here ONLY for archival purposes or if version 2 does not work on your rk28xx tablet. In all other cases, you need to download rkflashtool-v2.zip

surfer63 · Oct 4, 2011

Thanks a lot for this flash tool. I'm on MacOSX and Ubuntu and don't have Windows either. I tried the original rkflash as well but couldn't get it to work. On my Ubuntu boxes your rkflashtool compiles and works fine.
My Archos 7 HT V2 presents itself also as:

Code:

Bus 002 Device 004: ID 2207:281a

Reading partitions works fine and so does writing.
I did a quick modification of a system.img (left some files out) of my custom froyo rom and wrote it to my tablet.
That works fine. As /data is a separate partition I even have all my downloaded apps, data, settings, etc. This makes modifying a new rom much faster then building a complete update.img, flashing it, restore some data and then start testing.

Nice work.

fun_ · Oct 5, 2011

great! finally I can remove one line from my todo list

thank you!

EDIT:
random notes (I don't see your code yet so it may be fixed, then sorry)
* I always specify b(reboot) for rk2818 tablets with my rkflash because it hanged easily if I try to write multiple times without b
* parameter file need to be converted with rkcrc -p. official RKAndroid tools flashed it 5 times with offsets. (read & check 1st 0x0-0x2000 block)
* I logged how to update bootloader, but it's complicated and I could not understand

probably bootloader can be updated via misc partition. see update-script in update.img. (but not recommended/no reason to do it)

EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.

on Windows, there is RKAndroidTool.exe (not batchupgrade). but "read" function in rkflash/rkflashtool may be useful on some case on Windows

ivop · Oct 9, 2011

Good to hear it works for others, too! I have not had a hanging tablet after several writes in one session, but this might depend on the tablet.

Thanks for mentioning that it should also work on other platforms supported by libusb. I'd forgotten to do that.

About using update.img to flash a new bootloader, this can be done, but if you brick the tablet by flashing a wrong/faulty bootloader, you can only unbrick it with the Windows tools

Which leads me to the question: could you send me the snooped log of updating the bootloader? Two people see more than one and perhaps we can eventually manage to do this through libusb too.

fun_ · Oct 10, 2011

ivop said:
About using update.img to flash a new bootloader, this can be done, but if you brick the tablet by flashing a wrong/faulty bootloader, you can only unbrick it with the Windows tools

probably you also need a needle to short pins of NAND chip

so I don't recommend to flash bootloader

ivop said:
Which leads me to the question: could you send me the snooped log of updating the bootloader? Two people see more than one and perhaps we can eventually manage to do this through libusb too.

I made that log several months ago with another windows machine which is not used lately. I'm not sure log is still exist... if I find it, I'll send it to you (but please don't expect)

probably you may also get log on Windows on VM on Linux. it seems VMware has log function (refer http://vusb-analyzer.sourceforge.net/tutorial.html) or there is "usbmon" function in Linux.

actually I didn't try this way myself so it may be wrong, sorry.

tomaszwiniarski · Oct 11, 2011

I've tryed a couple of firmwares, cooking my own.
Every time after flashing, tablet shows boot animation and after few seconds display becomes dark.
My investigation led me to following:

Log shows:

Code:

ERROR/Lights(865): write_int failed to open /sys/class/backlight/rk28_button_light/brightness

in /sys/class/backlight I found symlink (rk28_bl):
rk28_bl -> ../../devices/platform/rk28_backlight/backlight/rk28_bl

Shouldn't be there another symlink named r28_button_light ?

I'm using MANTA MID001 from Poland.

surfer63 · Oct 14, 2011

fun_ said:
EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.

ivop said:
Good to hear it works for others, too! I have not had a hanging tablet after several writes in one session, but this might depend on the tablet.

I did a couple of successive writes as well from ubuntu.

ivop said:
Thanks for mentioning that it should also work on other platforms supported by libusb. I'd forgotten to do that.

My main platform is OSX and I immediately added libusb. So far I have not been able to compile rkflashtool despite declaring all kind of CFLAGS, CXXFLAGS and/or LDFLAGS.
Trying a little bit more.

ivop · Oct 15, 2011

Could you post the compiler warnings/errors here? I might be able to help out.

surfer63 · Oct 16, 2011

ivop said:
Could you post the compiler warnings/errors here? I might be able to help out.

I managed to compile it. It took a lot of hurdles. I used the build environment I also use for Hugin for which I'm the OSX maintainer.
I now built a single combined 32/64bit (i386/x86_64) rkflashtool that will run on 10.4.x/10.5.x/10.6.x/10.7.x (building multi-architecture, multi-version binaries/libraries in one binary/library is possible on OSX. I'm not going to explain that here but it's a feature of OSX).

The compiled version is attached. You can also attach it to your first post if you like.
It works fine. I did some reading/writing of images without issues.

surfer63 · Oct 16, 2011

If you are on OSX and have macports installed, you can do the following to build rkflashtool.
Install libusb from Macports:

Code:

sudo port install libusb

cd into the folder where your rkflashtool.c is is and run the following command:

Code:

gcc -I/opt/local/include -I/opt/local/include/libusb-1.0 \
-L/opt/local/lib -o rkflashtool rkflashtool.c -lusb-1.0 -W -Wall

This will build rkflashtool for your native environment (OSX version, hardware and config).

--- removed the rest of the post as well as the attachments. He/She who is interested in building a complete universal distributable rkflashtool can ask via this thread ---

ivop · Nov 14, 2011

UPDATE: Works on rk2918 tablet too

Yesterday I have tested the tool on an Arnova 7 G2 tablet, which has an rk2918 CPU. If you change the ProductID before compilation, like this:

... libusb_open_device_with_vid_pid(c, 0x2207, 0x281a) ...

to

... libusb_open_device_with_vid_pid(c, 0x2207, 0x290a) ...

it'll work, except for rebooting the device if the tablet is still locked. To boot the tablet in bootloader mode, turn off the tablet completely, put the on/off-switch in the locked position and connect it to your computer. It should be visible now with lsusb. For further instructions, see first post. I advise dumping the first 0x2000 blocks at offset 0x0000 first as this contains the parameter block in which you can see where each partition starts and how big it is.

surfer63 · Nov 16, 2011

ivop said:
UPDATE: Works on rk2918 tablet too

Yesterday I have tested the tool on an Arnova 7 G2 tablet, which has an rk2918 CPU. If you change the ProductID before compilation, like this:

... libusb_open_device_with_vid_pid(c, 0x2207, 0x281a) ...

to

... libusb_open_device_with_vid_pid(c, 0x2207, 0x290a) ...

Feature request

:
I's nice but could you also make it a startup option, like the b,r,w options, with an if-else option in the source code? Something like (RK)2818 and (RK)2918 and maybe even for the older ones: (RK)2808.
In that case you only need one binary. Users who are going to use the tool will definitely know what CPU they have.

ivop · Nov 17, 2011

surfer63 said:
Feature request :
I's nice but could you also make it a startup option, like the b,r,w options, with an if-else option in the source code? Something like (RK)2818 and (RK)2918 and maybe even for the older ones: (RK)2808.
In that case you only need one binary. Users who are going to use the tool will definitely know what CPU they have.

I released a new version and updated the first post. It now tries to connect to an rk2918 tablet and if it doesn't find one, it falls back to rk2818.

surfer63 · Nov 18, 2011

The V2 version works fine too on MacOSX. The compilation is still the same for a "my machine only" version.

I compiled a universal Intel 32bit/64bit 10.4/10.5/10.6/10.7 V2 version as well.

See attached.

Note: I don't have a RK2918 so I can only test for a RK2818 tablet.

relsyou · Nov 23, 2011

Hi,

Thanks for your thread it's very intersting.

I succeed flashing my boot partition with your tool but I don't success in remount,rw my system partition. It's cramFS and in init.rk28board.rc you can see those line :

Code:

    # Mount /system rw first to give the filesystem a chance to save a checkpoint
    mount cramfs mtd@system /system
    mount cramfs mtd@system /system ro remount

I tried everything like replacing ro by rw, deleting the second line but my system stills in ReadOnly, don't understand why. I also tried deleting those lines to test if my flash process works properly and it's worked... So I'm lost. Any idea ?

----

Other thing, if I want to do same as flashing boot partition but with system partition is it possible with the same process ? Unfortunately I don't know the beginning offset of the partition. I don't know where to find HWDEF file. The size of partition is 00038000 (hex) bytes => 229376 (dec) bytes

Here is my /proc/mtd :

Code:

dev:    size   erasesize  name
mtd0: 00002000 00000010 "misc"
mtd1: 00004000 00000010 "kernel"
mtd2: 00002000 00000010 "boot"
mtd3: 00004000 00000010 "recovery"
mtd4: 00038000 00000010 "system"
mtd5: 0003a000 00000010 "backup"
mtd6: 0003a000 00000010 "cache"
mtd7: 00080000 00000010 "userdata"
mtd8: 00534000 00000010 "user"
mtd9: 00020000 00000010 "pagecache"
mtd10: 00020000 00000010 "swap"

Thank you for your great job

relsyou · Nov 23, 2011

My problem is solved. I was searching for a while but ivop gave the answer in a previous post

I advise dumping the first 0x2000 blocks at offset 0x0000 first as this contains the parameter block in which you can see where each partition starts and how big it is.

So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :

Code:

0x00002000@0x00002000(misc),
0x00004000@0x00004000(kernel),
0x00002000@0x00008000(boot),
0x00004000@0x0000A000(recovery),
0x00038000@0x0000E000(system),
0x0003A000@0x00046000(backup),
0x0003A000@0x00080000(cache),
0x00080000@0x000BA000(userdata),
-@0x0013A000(user)

So system partition starts at E000 and has a length of 38000 (hex) bytes.

Thanks for your help this thread is now in my bookmarks

And really nice job with this flashtool

fun_ · Nov 25, 2011

I pushed latest my rkutils to https://github.com/naobsd/rkutils

rkunpack can unpack RKFW image used in RK2918 ROM, RKAF image (update.img), KRNL/PARM image used in some single partition image. unpack will be done recursively.

rkcrc can make KRNL/PARM images with -k/-p.

rkafpack can make RKAF image. (I need to write docs/howtos...)

little off-topic,
latest RK2918 ROMs which is based on "SDK2.0", new format for boot.img/recovery.img is introduced. it's almost same as common boot.img format for android. unpackbootimg/mkbootimg can be used to unpack/repack it with one exception...
there is SHA1 hash value in header of boot.img (offset 0x240 bytes). Rockchip changes it by some unknown way. normal mkbootimg can't generate same hash value as Rockchip, so we can't make custom boot.img with new format

fortunately, we can split new boot.img, and we can make separate kernel.img and boot.img(ramdisk) like as pre-SDK2.0 RK2918 ROMs, which is loadable with new bootloader in SDK2.0 ROMs.

--
btw I just found interesting one: https://github.com/jhonxie/rk2918_tools

ivop · Nov 25, 2011

relsyou said:
My problem is solved. I was searching for a while but ivop gave the answer in a previous post

So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :

Code:

0x00002000@0x00002000(misc), 0x00004000@0x00004000(kernel), 0x00002000@0x00008000(boot), 0x00004000@0x0000A000(recovery), 0x00038000@0x0000E000(system), 0x0003A000@0x00046000(backup), 0x0003A000@0x00080000(cache), 0x00080000@0x000BA000(userdata), -@0x0013A000(user)

So system partition starts at E000 and has a length of 38000 (hex) bytes.

Thanks for your help this thread is now in my bookmarks

And really nice job with this flashtool

I'll add that to my first post. Also, you can view /proc/cmdline to see a list of partitions. It's part of the kernel command line.

Note that the lengths are not in bytes but in blocks of 512 bytes. This happens to be the same as the requirements of the rkflashtool btw (length in blocks).

As for having a writable system partition, currently the system partition is cramfs which cannot be written to. Ever. If you want a writable system partition, you need to change it to ext3 for example. That means unpacking fun_'s system.img and recreating it as an ext3 partition.

In short:

Unpack cramfs img with cramfsck -x (as root, so you preserve permissions and uid/gid)
Create an empty file the size of your system partition (dd if=/dev/null of=fubar.img bs=512 count=...... et cetera, do the math)
mkfs.ext3 fubar.img
mount -o loop fubar.img /someplacemountable
copy contents of old image to /someplacemountable (use cp -a to preserve ownership etc)
umount
flash fubar.img to system partition
change init.rk28board.rc to reflect the changes
reflash boot.img
reboot device

This is untested, but should work in theory.

Another option is to keep the system partition read-only and use unionfs to overlay a writable partition. I'm not sure if this can be a file on your userdata partition mounted with -o loop, but I suppose it can. This depends on your kernel having unionfs and loopback support though.

ivop · Nov 25, 2011

fun_ said:
I pushed latest my rkutils to https://github.com/naobsd/rkutils

Nice! I was thinking about creating an rkpack(tool

) myself, but I see it's not necessary anymore.

fun_ · Nov 25, 2011

here is an example for rkafpack

Code:

$ rkunpack N3NET-2.3-20110722.img 
[COLOR="Red"][B]FIRMWARE_VER:1.0.0[/B][/COLOR]
[COLOR="Red"][B]MACHINE_MODEL:rk2818sdk[/B][/COLOR]
MACHINE_ID:
[COLOR="Red"][B]MANUFACTURER:rock-chips[/B][/COLOR]

unpacking 12 files
-------------------------------------------------------------------------------
00000800-00000fff [COLOR="Red"][B]HWDEF:HWDEF[/B][/COLOR] 797 bytes
00001000-000017ff [COLOR="Red"][B]package-file:package-file[/B][/COLOR] 532 bytes
00001800-00021fff [COLOR="Red"][B]bootloader:RK28xxLoader(L).bin[/B][/COLOR] 131700 bytes
00022000-000227ff [COLOR="Red"][B]parameter:parameter:0x0@0x0[/B][/COLOR] 506 bytes
00022800-0002e7ff [COLOR="Red"][B]misc:Image/misc.img:0x0@0x2000[/B][/COLOR] 49152 bytes
0002e800-0066bfff [COLOR="Red"][B]kernel:Image/kernel.img:0x0@0x4000[/B][/COLOR] 6541946 bytes
0066c000-006947ff [COLOR="Red"][B]boot:Image/boot.img:0x0@0x8000[/B][/COLOR] 163844 bytes
00694800-008e8fff [COLOR="Red"][B]recovery:Image/recovery.img:0x0@0xa000[/B][/COLOR] 2441220 bytes
008e9000-085fc7ff [COLOR="Red"][B]system:Image/system.img:0x0@0xe000[/B][/COLOR] 131149828 bytes
----------------- [COLOR="Red"][B]backup:SELF:0x0@0x52000[/B][/COLOR] (N3NET-2.3-20110722.img) 140498948 bytes
085fc800-085fcfff [COLOR="Red"][COLOR="Red"][B]update-script:update-script[/B][/COLOR][/COLOR] 1294 bytes
085fd000-085fd7ff [COLOR="Red"][B]recover-script:recover-script[/B][/COLOR] 266 bytes
-------------------------------------------------------------------------------
unpacked
$ rkafpack \
[COLOR="Red"][B]FIRMWARE_VER:1.0.0[/B][/COLOR] \
[COLOR="Red"][B]MACHINE_MODEL:rk2818sdk[/B][/COLOR] \
[COLOR="Red"][B]MANUFACTURER:rock-chips[/B][/COLOR] \
[COLOR="Red"][B]HWDEF:HWDEF[/B][/COLOR] \
[COLOR="Red"][B]package-file:package-file[/B][/COLOR] \
'[COLOR="Red"][B]bootloader:RK28xxLoader(L).bin[/B][/COLOR]' \
[COLOR="Red"][B]parameter:parameter:0x0@0x0[/B][/COLOR] \
[COLOR="Red"][B]misc:Image/misc.img:0x0@0x2000[/B][/COLOR] \
[COLOR="Red"][B][B]kernel:Image/kernel.img:0x0@0x4000[/B][/B][/COLOR] \
[COLOR="Red"][B]boot:Image/boot.img:0x0@0x8000[/B][/COLOR] \
[COLOR="Red"][B]recovery:Image/recovery.img:0x0@0xa000[/B][/COLOR] \
[COLOR="Red"][B]system:Image/system.img:0x0@0xe000[/B][/COLOR] \
[COLOR="Red"][B]backup:SELF:0x0@0x52000[/B][/COLOR] \
[COLOR="Red"][B]update-script:update-script[/B][/COLOR] \
[COLOR="Red"][B]recover-script:recover-script[/B][/COLOR] \
> new.img
$ sha1sum N3NET-2.3-20110722.img new.img 
e758a6c47dca7f09f0b8a82ad89b0cd7c7c8e826  N3NET-2.3-20110722.img
e758a6c47dca7f09f0b8a82ad89b0cd7c7c8e826  new.img

some values are empty in RK2818 ROM.

--
here is how to make RKFW image

Code:

$ rkunpack N50-2.3-20111103-ZZ-SDK2.0.img 
VERSION:2.0.3

unpacking
00000000-00000065 N50-2.3-20111103-ZZ-SDK2.0.img-HEAD 102 bytes
00000066-00022623 N50-2.3-20111103-ZZ-SDK2.0.img-BOOT 140734 bytes
00022624-0c342627 update.img 204603396 bytes

unpacking update.img
================================================================================
FIRMWARE_VER:0.2.3
MACHINE_MODEL:rk29sdk
MACHINE_ID:007
MANUFACTURER:RK29SDK

unpacking 10 files
-------------------------------------------------------------------------------
00000800-00000fff package-file:package-file 540 bytes
00001000-000237ff bootloader:RK29xxLoader(L)_V2.08.bin 140734 bytes
00023800-00023fff parameter:parameter:0x2000@0x0 610 bytes
00024000-0002ffff misc:Image/misc.img:0x2000@0x2000 49152 bytes
00030000-006a3fff boot:Image/boot.img:0x8000@0x8000 6766592 bytes
006a4000-01167fff recovery:Image/recovery.img:0x8000@0x10000 11288576 bytes
01168000-0c31efff system:Image/system.img:0x80000@0x1cc000 186346496 bytes
----------------- backup:SELF:0x78000@0x18000 (update.img) 204603396 bytes
0c31f000-0c31f7ff update-script:update-script 933 bytes
0c31f800-0c31ffff recover-script:recover-script 266 bytes
-------------------------------------------------------------------------------
================================================================================

00022624-0c342627 N50-2.3-20111103-ZZ-SDK2.0.img-MD5 32 bytes
unpacked
$ cat N50-2.3-20111103-ZZ-SDK2.0.img-HEAD N50-2.3-20111103-ZZ-SDK2.0.img-BOOT update.img > new.img
$ md5sum new.img
[COLOR="Red"][B]5191abc65649eacf8d2476e37d84a046[/B][/COLOR]  new.img
$ cat N50-2.3-20111103-ZZ-SDK2.0.img-MD5
5191abc65649eacf8d2476e37d84a046
$ echo -n [COLOR="Red"][B]5191abc65649eacf8d2476e37d84a046[/B][/COLOR] >> new.img
$ sha1sum N50-2.3-20111103-ZZ-SDK2.0.img new.img 
3120b13df8886e0ddfae0e35379443c27c925572  N50-2.3-20111103-ZZ-SDK2.0.img
3120b13df8886e0ddfae0e35379443c27c925572  new.img

[TOOL] rkflashtool for Linux and rk2808, rk2818 and rk2918 based tablets

Member

Attachments

Senior Member

Senior Member

Member

Senior Member

Member

Senior Member

Member

Senior Member

Attachments

Senior Member

Member

Senior Member

Member

Senior Member

Attachments

Member

Member

Senior Member

Member

Member

Senior Member

Similar threads

Top Liked Posts