Hello Everyone,
I have an i-mate Jamin, G3 I believe with no sign of life. The battery is 100% charged, and I cannot enter bootloader mode.
So I'm trying JTAG to write bootloader back to the phone.
My steps
1. I installed GIVEIO driver and started the service in Windows.
2. I made the JTAG pins using the resistance and connected the device.
3. In Jflash_MM I started start.bat and the phone was detected.
But next, I dunno what to do.
Sometimes I get error messages. Once I was even able to program. But I dunno what file to write to the device, and what is the address for this phone.
If anyone has restored the bootloader, please advice. Also is it possible on this phone or not.
Thnx
Output
C:\>start.bat
C:\>jflashmm pxa27x32 ebo_a.nb0 N 0 PAR
JFLASH Version 5.01.007
COPYRIGHT (C) 2000 - 2003 Intel Corporation
PLATFORM SELECTION:
Processor= PXA27x
Development System= Mainstone
Data Version= 1.00.001
PXA27x revision ??
Upper and Lower flash memory ID does not match.
You may have a damaged flash memory.
Upper half reads: FFC2
Lower half reads: 0
Failed to read the Flash ID. Retrying 4 more times...
Failed to read the Flash ID. Retrying 3 more times...
Failed to read the Flash ID. Retrying 2 more times...
Failed to read the Flash ID. Retrying 1 more times...
Failed to read the Flash ID. Retrying 0 more times...
Cannot open input file: Flash_ffff_2_32.dat
This program supports flash devices defined by DAT files
contained in the same directory as the executable program.
If the file cannot be opened, there are four possibilities:
1 - The flash device installed is not supported.
2 - The flash device is a licensed product.
3 - The device ID could not be read, resulting in a poorly
constructed filename. The first numeric value in the
filename is the device ID. Verify this value with the
component specification.
4 - The memory bus is not functional. Check all CPLD and FPGA
devices. Make sure that you are using the correct
platform data file.
C:\>jflashmm pxa27x32 ebo_a.nb0 N 3F40000 PAR
JFLASH Version 5.01.007
COPYRIGHT (C) 2000 - 2003 Intel Corporation
PLATFORM SELECTION:
Processor= PXA27x
Development System= Mainstone
Data Version= 1.00.001
PXA27x revision ??
Failed to read the Flash ID. Retrying 4 more times...
Upper and Lower flash memory ID does not match.
You may have a damaged flash memory.
Upper half reads: 9800
Lower half reads: 0
Failed to read the Flash ID. Retrying 3 more times...
Failed to read the Flash ID. Retrying 2 more times...
Failed to read the Flash ID. Retrying 1 more times...
Failed to read the Flash ID. Retrying 0 more times...
Cannot open input file: Flash_0_2_32.dat
This program supports flash devices defined by DAT files
contained in the same directory as the executable program.
If the file cannot be opened, there are four possibilities:
1 - The flash device installed is not supported.
2 - The flash device is a licensed product.
3 - The device ID could not be read, resulting in a poorly
constructed filename. The first numeric value in the
filename is the device ID. Verify this value with the
component specification.
4 - The memory bus is not functional. Check all CPLD and FPGA
devices. Make sure that you are using the correct
platform data file.
What is this Flash_0_2_32.dat all about?
Allright, I got the device flashed too, but still no bootloader....
JFLASH Version 5.01.007
COPYRIGHT (C) 2000 - 2003 Intel Corporation
PLATFORM SELECTION:
Processor= PXA27x
Development System= Mainstone
Data Version= 1.00.001
PXA27x revision ??
Found flash type: 28F256L18B
The last 43 percent of image file is all zeros
Would you like to save time by not programming that area? [y/n]: y
Unlocking block at address 0
Erasing block at address 0
Unlocking block at address 10000
Erasing block at address 10000
Unlocking block at address 20000
Erasing block at address 20000
Unlocking block at address 30000
Erasing block at address 30000
Unlocking block at address 40000
Erasing block at address 40000
Starting programming
Using BUFFER programming mode...
Writing flash at hex address 48cc0, 99.38% done
Programming done
C:\>jflashmm pxa27x32 ebo_a.nb0 N 3F40000 PAR
JFLASH Version 5.01.007
COPYRIGHT (C) 2000 - 2003 Intel Corporation
PLATFORM SELECTION:
Processor= PXA27x
Development System= Mainstone
Data Version= 1.00.001
PXA27x revision ??
Found flash type: 28F256L18B
The last 43 percent of image file is all zeros
Would you like to save time by not programming that area? [y/n]: y
Unlocking block at address 3f40000
Erasing block at address 3f40000
Unlocking block at address 3f80000
Erasing block at address 3f80000
Starting programming
Using BUFFER programming mode...
Writing flash at hex address 3f88c40, 99.34% done
Programming done
So, currently the backflip is released in 3 markets:
USA under AT&T as the Backflip MB300
Brazil under Vivo as the Backflip MB300
and
China from motorola as the MB600
MOTOSTORE (chinese)
Currently there is know firmware released for the USA and BRAZIL versions, but it appears I was able to find the firmware for the ME600!!
The file found is ME600GC-N-00.00.34R.zip and contains MotusGC_N_00.00.34R-supermonster-customer.sbf
The original post (chinese) is available at ME600GC-N-00.00.34R - ME600/MB300/Backflip - Android
The direct download for the ZIP containg SBF is http://me600.net/files/ME600GC-N-00.00.34R.zip
I have not had time to do anything with the files, and anybody who uses this file is doing so at their own risk... no complaining to me about ruining your phone.
If you want track my progress at http://twitter.com/moosefist
So i decided to risk (NO brick created) it and tried flashing the file and RSDlite failed with this error:
Code:
23:50:41, March 23, 2010
Line: 563
ERROR: Phone[0000]: Error sending JUMP command Device API Error: 0xE0030040 Address: 0xB00000 Command: JUMP
File: X:test_dev_usbflashcodeflashdllRDLOp.cpp
Device ID: 0
23:50:41, March 23, 2010
Line: 318
ERROR: Phone[0000]: Error jumping to RAM Downloader
File: X:test_dev_usbflashcodeflashdllRDLOp.cpp
Device ID: 0
23:50:41, March 23, 2010
Line: 1182
ERROR: Phone[0000]: Flash failed.
File: X:test_dev_usbflashcodeflashdllPST_FP_FlashThread.cpp
Device ID: 0
23:50:41, March 23, 2010
Line: 587
ERROR: Flash failure: Phone[0000]: Error sending JUMP command Device API Error: 0xE0030040 Address: 0xB00000 Command: JUMP (Error Code: e0030040),
Detailed Error Details: Direction of the Error=2000, Command Value=500000, Code Group Number=No Codegroup
File: X:test_dev_usbflashcodeflashdllFlashHdlr.cpp
Device ID: 0
you may need to put it in recovery mode as described here
androidin.net/bbs/thread-71604-1-1 .html
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
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.
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
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.
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
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
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.
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.
fun_ said:
EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
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.
Could you post the compiler warnings/errors here? I might be able to help out.
ivop said:
Could you post the compiler warnings/errors here? I might be able to help out.
Click to expand...
Click to collapse
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.
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 ---
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.
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) ...
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
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.
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.
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 [email protected] /system
mount cramfs [email protected] /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
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.
Click to expand...
Click to collapse
So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :
Code:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](system),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](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 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
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:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](system),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](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
Click to expand...
Click to collapse
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.
fun_ said:
I pushed latest my rkutils to https://github.com/naobsd/rkutils
Click to expand...
Click to collapse
Nice! I was thinking about creating an rkpack(tool ) myself, but I see it's not necessary anymore.
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:[email protected][/B][/COLOR] 506 bytes
00022800-0002e7ff [COLOR="Red"][B]misc:Image/misc.img:[email protected][/B][/COLOR] 49152 bytes
0002e800-0066bfff [COLOR="Red"][B]kernel:Image/kernel.img:[email protected][/B][/COLOR] 6541946 bytes
0066c000-006947ff [COLOR="Red"][B]boot:Image/boot.img:[email protected][/B][/COLOR] 163844 bytes
00694800-008e8fff [COLOR="Red"][B]recovery:Image/recovery.img:[email protected][/B][/COLOR] 2441220 bytes
008e9000-085fc7ff [COLOR="Red"][B]system:Image/system.img:[email protected][/B][/COLOR] 131149828 bytes
----------------- [COLOR="Red"][B]backup:SELF:[email protected][/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:[email protected][/B][/COLOR] \
[COLOR="Red"][B]misc:Image/misc.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B][B]kernel:Image/kernel.img:[email protected][/B][/B][/COLOR] \
[COLOR="Red"][B]boot:Image/boot.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]recovery:Image/recovery.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]system:Image/system.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]backup:SELF:[email protected][/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:[email protected] 610 bytes
00024000-0002ffff misc:Image/misc.img:[email protected] 49152 bytes
00030000-006a3fff boot:Image/boot.img:[email protected] 6766592 bytes
006a4000-01167fff recovery:Image/recovery.img:[email protected] 11288576 bytes
01168000-0c31efff system:Image/system.img:[email protected] 186346496 bytes
----------------- backup:SELF:[email protected] (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