Rk3066无法进入系统及升级保留程序刷机方法，momo8实测
默认的rk3066升级工具是量产工具，不能保留已经安装的程序，momo8默认设置甚至会删除内置存储数据（可以编辑升级config避免），修改系统文件一不小心不能进入系统又忘记备份的话，量产工具意味着一切重来。momo8现在的系统还不是很稳定，由于tf卡不够用一直使用的内置存储，在刷机过程中受够了数据备份的苦头，上午由于修改系统文件又忘了备份新安装程序，到处找解决方法，在经历重大损失后终于找到了方法。
需要的软件：
1.刷机精灵： 下载http://www.shuame.com/
2.RK3066擦除工具
下载 http://www.yuandaocn.com/download.aspx?cid=7 或者http://kuai.xunlei.com/d/CRDPEIDHHSSW
3.官方rom包，MOMO8(IPS)-4.1.1固件20120920http://www.ployer.cn/prshow.asp?id=131&p=zc
4.老熊RK29固件修改工具 rk3066通用 http://pan.baidu.com/share/link?shareid=63747&uk=3373127877 或者http://bbs.imp3.net/thread-10480891-1-1.html
开工：
1.解压缩老熊RK29固件修改工具，把官方rom包加压出来的update.img复制到老熊RK29固件修改\rk29打包解包工具ultra2.1目录里，运行 rk29打包解包工具ultra2.1目录下”固件解包.bat”，解包出来的文件存放在该目录下面”temp\image”下面。
2.注意rk29打包解包工具ultra2.1\temp目录里面的parameter,这个文件存放的是各个映像包的偏移地址，
用记事本等打开，
mtdparts=rk29xxnand:后面则是各分区值
格式为: 分区大小@偏移大小（分区镜像）
比如其中：0x00004000@0x00004000(kernel)
这里kerenl的偏移值则是 0x00004000
又如：0x00008000@0x00010000(recovery)
这里recovery的偏移值则是 0x00010000
再如：0x00100000@0x0031A000(system)
这里system的偏移值则是0x0031A000
注意！该偏移值为刷入固件的偏移值，偏移值填写错误可能将导致系统其他分区被覆盖而引起死机。
这个是momo8 rom中system分区的偏移地址是0x0031A000 ，上面下载的RK3066擦除工具默认system偏移地址是 0x0021A000 ，这个地址每个机型可能不一样，需要根据parameter 的内容修改，其它kernel.img、recovery.img等的偏移地址也可以从parameter 找到备用。
3.安装并运行刷机精灵，如果机子已经开启usb调试的话，刷机精灵可以连接平板；没开usb调试的话，直接用RK3066擦除工具的切换功能就行了。已一般情况来说已经开启usb调试 ，刷机精灵-使用工具-点击”进入fastboot模式”，平板自动重启并进入刷机模式，不用拆机或恢复出厂设置再手动进入刷机（当初没经验，系统文件修改错误无法进入系统，恢复出厂还是不行就忘了这个方法了，白拆机了）。
4.解压缩RK3066擦除工具，运行目录RKDevelopTool_v1.35里面的RKAndroidTool
特别注意这里的地址栏里面的各个img偏移地址是否与解压出来parameter里面是否一致，以momo8为例，kerenl、recovery、misc与默认地址一致，但是system不一致，对不一致的双击该地址栏，修改为上面解压出来 parameter里面的地址，比如momo8的第7栏system地址修改为0x0031A000，点击路径之后的空白栏，选择实际解压出来的各个分区img，选择好后，勾选要刷入的img，特别注意的是，如果选择刷入misc的话，所有用户数据以及内置sd卡都会被格式化，血的教训啊,本来想保存用户数据，结果连内置sd卡也被格式化了。一般只需要刷入system就行了，否则直接用量产工具不是更方便？
选择好后，点击执行，刷入很快，完毕后会自动重启，之前安装的程序包括root都会保留，每次刷机、升级不用钛备份备份恢复了。
来自 <http://bbs.imp3.net/thread-10790799-1-1.html>
RKAndroidTool工具的各项image详解(RK2918版本)
/********************************************************************************************
* author：conowen@大钟
* E-mail：conowen@hotmail.com
* http://blog.csdn.net/conowen
* 注：本文为原创，仅作为学习交流使用，转载请标明作者及出处。
********************************************************************************************/
..\rockdev\表示RKAndroidTool所在目录的上一层目录下的rockdev文件夹。
工具预设目录为..\rockdev\，若扫描有Paremeter ，则载入，读出分区表信息，关于Paremeter ，参看第2点。
工具的”偏移”（offset）表示分区的起始地址，也参看第2点。
1、Loader.bin (100K左右)
系统启动必须的引导文件
RK29xxLoader(L)_V2.08.bin
2、Paremeter 分区信息表（50K左右）
打开rockdev目录下的Paremeter 文件，内容如下
[java]
- FIRMWARE_VER:0.2.3
- MACHINE_MODEL:rk29sdk
- MACHINE_ID:007
- MANUFACTURER:RK29SDK
- MAGIC: 0x5041524B
- ATAG: 0x60000800
- MACHINE: 2929
- CHECK_MASK: 0x80
- KERNEL_IMG: 0x60408000
- #COMBINATION_KEY: 0,6,A,1,0
- CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x800000
- mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00008000@0x00008000(boot),
- 0x00008000@0x00010000(recovery),0x00078000@0x00018000(backup),0x0003a000@0x00090000(cache),
-
0x00100000@0x000ca000(userdata),0x00002000@0x001ca000(kpanic),0x00080000@0x001cc000(system),-@0x0024c000(user)
misc
kernel——内核镜像
boot——系统引导
recovery
backup
cache——缓存区
userdata——用户rom区
kpanic
system——系统程序
user———用户储存区
前面是关于机器固件版本，机器型号，机器制造厂商的信息，当然也可以改成自己所喜欢的。
下面的
[java]
-
mtdparts=rk29xxnand
则表示机器nand flash的分区信息。
[java]
-
0x00002000@0x00002000(misc)
右边的0x00002000表示起始地址，左边的0x00002000表示misc分区的容量大小。至于为什么要从0x00002000开始，因为分区表Paremeter 也要占有flash的容量，Paremeter 是从0x00000000开始的。左右两边数值相加，就等于下一个分区的起始地址，如此类推。如到了recovery分区。
[java]
-
0x00008000@0x00010000(recovery)
起始地址为0x00010000，recovery分区大小为0x00008000，所以下一个backu分区的起始地址为0x00018000。
另外，关于用户区userdata，也就是rom区。常说的扩容就是扩展此分区。
[java]
-
0x00100000@0x000ca000(userdata),
先来算算此分区的大小。
0x00100000为十六进制，折算成十进制为1048576，因为瑞芯微rockchip采用的是0.5K为单位。折算结果为
1048576*0.5K=524288K
524288K/1024=512M
也就是说rom区容量为512M。
假若要扩展此分区，则往后的各个偏移量都要相加推移。
到了最后一个user分区，
[java]
-
–@0x0024c000(user)
左边的”-“表示user分区占有剩余的nand flash所有容量。也就是常常存放一些用户的数据如电影、音乐之类的。不同于rom区的存放安装软件。
3、Misc.img（1K左右）
cpu加电之后，启动bootloader，（即是RK29xxLoader(L)_V2.08.bin），就会读取MISC分区第一块的内容，
决定进入recovery模式还是升级基带Baseband Processor（BP）或做其它事情。而更改Misc内容的操作为按下某个按键或者用户设置系统。
4、kernel.img（6M左右）
内核镜像，经过编译得出zImage，即为Kernel.img。或者SDK包直接附带。
5、boot.img（8M左右）
系统bootload启动之后，进入正常启动模式，就会读取boot.img进去系统正常模式。
boot.img包括了kernel.img镜像和一个根文件系统（rootfs）
6、recovery.img（12M左右）
系统bootload启动之后，通过读取Misc分区的内容，确认如果是进入Recovery模式的话，进去读取Recovery.img。
recovery.img包括了一个kernel.img与一个根文件系统（rootfs），kernel镜像与boot,img的完全一样。
7、system.img（100+M左右）
包括了系统必要的app，详细参考
http://blog.csdn.net/conowen/article/details/7251057
8、擦除IDB
表示清空分区表，就是低级格式化nand flash。这样的话，要重新刷入parameter分区。
附：Recovery 根文件系统目录结构
$ tree
.
├── advanced_meta_init.rc
├── data
├── default.prop
├── dev
├── etc
├── init
├── init.factory.rc
├── init.goldfish.rc
├── init.quacomm.rc
├── init.rc
├── meta_init.rc
├── proc
├── res
│ ├── images
│ │ ├── icon_error.png
│ │ ├── icon_installing.png
│ │ ├── indeterminate1.png
│ │ ├── indeterminate2.png
│ │ ├── indeterminate3.png
│ │ ├── indeterminate4.png
│ │ ├── indeterminate5.png
│ │ ├── indeterminate6.png
│ │ ├── progress_empty.png
│ │ └── progress_fill.png
│ └── keys
├── sbin
│ ├── adbd
│ ├── advanced_meta_init
│ ├── meta_init
│ ├── meta_tst
│ └── recovery
├── sys
├── system
└── tmp
来自 <http://blog.csdn.net/conowen/article/details/7251886>
第一步：系统引导bootloader，即RK29xxLoaderXXX.bin文件
加电后，CPU将先执行 bootloader程序，然后bootloader首先会读寄存器地址base + APP_DATA1的内容，
根据这个地址的值决定是否进入recovery模式或者其它模式。bootloader还会读取MISC分区第一块的内容，
决定进入recovery模式还是升级基带Baseband Processor（BP）或做其它事情
而上述寄存器与分区的值是有按键触发或者软件触发的。
a) 开机按reset+返回键，系统进入recovery模式，加载recovery.img，recovery.img包含内核，基本的文件系统，用于工程模式的烧写
b) 开机按Power，正常启动系统，加载boot.img，boot.img包含内核，基本文件系统，用于正常启动机器（以下只分析正常启动的情况）
第二步：
启动内核kernel
1) 源码：kernel/*
2) 说明：kernel由bootloader加载
第三步： 文件系统(rootfs)及应用初始化（init）
1) 源码：system/core/init/*
2) 配置文件：system/rootdir/init.rc，
3) 说明：init是一个由内核启动的用户级进程，它按照init.rc中的设置执行：启动服务（这里的服务指linux底层服务，如adbd提供adb支持，vold提供SD卡挂载等），执行命令和按其中的配置语句执行相应功能
第四步： 重要的后台程序zygote
1) 源码：frameworks/base/cmds/app_main.cpp等
2) 说明：zygote是一个在init.rc中被指定启动的服务，该服务对应的命令是/system/bin/app_process
a) 建立Java Runtime，建立虚拟机
b) 建立Socket接收ActivityManangerService的请求，用于Fork应用程序
c) 启动SystemServer
第五步：
系统服务system server
1) 源码：frameworks/base/services/java/com/android/server/SystemServer.java
2) 说明：被zygote启动，通过System Manager管理android的服务（这里的服务指frameworks/base/services下的服务，如卫星定位服务，剪切板服务等）
第六步：桌面launcher
1) 源码：ActivityManagerService.java为入口，packages/apps/launcher*实现
2) 说
明：系统启动成功后SystemServer使用xxx.systemReady()通知各个服务，系统已经就绪，桌面程序Home就是在 ActivityManagerService.systemReady()通知的过程中建立的，最终调用 ()启launcher
第七步： 解锁
1) 源码：
frameworks/policies/base/phone/com/android/internal/policy/impl/*lock*
2) 说
明：系统启动成功后SystemServer调用wm.systemReady()通知WindowManagerService，进而调用 PhoneWindowManager，最终通过LockPatternKeyguardView显示解锁界面，跟踪代码可以看到解锁界面并不是一个 Activity，这是只是向特定层上绘图，其代码了存放在特殊的位置
第八步： 开机自启动的第三方应用程序
1) 源码：
frameworks/base/services/java/com/android/server/am/ActivityManagerService.java
2) 说
明：系统启动成功后SystemServer调用ActivityManagerNative.getDefault().systemReady()通知ActivityManager启动成功，ActivityManager会通过置变量mBooting，通知它的另一线程，该线程会发送广播android.intent.action.BOOT_COMPLETED以告知已注册的第三方程序在开机时自动启动。
第九步：
总结
综上所述，系统层次关于启动最核心的部分是zygote(即app_process)和system server，zygote它负责最基本的虚拟机的建立，以支持各个应用程序的启动，而systemserver用于管理android后台服务，启动步骤及顺序。
10. 参考
http://blog.csdn.net/basonjiang_sz/category/648399.aspx
来自 <http://blog.csdn.net/conowen/article/details/7252490>
Recovery简介
Android利用Recovery模式，进行恢复出厂设置，OTA升级，patch升级及firmware升级。
升级一般通过运行升级包中的META-INF/com/google/android/update-script脚本来执行自定义升级，脚本中是一组recovery系统能识别的UI控制，文件系统操作命令，例如write_raw_image（写FLASH分区），copy_dir（复制目录）。该包一般被下载至SDCARD和CACHE分区下。如果对该包内容感兴趣，可以从http://forum.xda-developers.com/showthread.php?t=442480下载JF升级包来看看。
升级中还涉及到包的数字签名，签名方式和普通JAR文件签名差不错。公钥会被硬编译入recovery，编译时生成在：out/target/product/XX/obj/PACKAGING/ota_keys_inc_intermediates/keys.inc
G1中的三种启动模式
MAGIC KEY:
- camera + power：bootloader模式，ADP里则可以使用fastboot模式
- home + power：recovery模式
-
正常启动
Bootloader正常启动，又有三种方式，按照BCB（Bootloader Control Block, 下节介绍）中的command分类：
- command == \’boot-recovery\’ →
启动recovery.img。recovery模式
- command == \’update-radio/hboot\’ →
更新firmware（bootloader)
-
其他
→
启动boot.img
Recovery涉及到的其他系统及文件
-
CACHE分区文件
Recovery 工具通过NAND cache分区上的三个文件和主系统打交道。主系统（包括恢复出厂设置和OTA升级）可以写入recovery所需的命令，读出recovery过程中的LOG和intent。
- /cache/recovery/command： recovery命令，由主系统写入。所有命令如下：
- –send_intent=anystring – write the text out to recovery.intent
- –update_package=root:path – verify install an OTA package file
- –wipe_data – erase user data (and cache), then reboot
- –wipe_cache – wipe cache (but not user data), then reboot
- /cache/recovery/log：recovery过程日志，由主系统读出
- /cache/recovery/intent：recovery输出的intent
- MISC分区内容
Bootloader Control Block (BCB) 存放recovery bootloader message。结构如下：
struct bootloader_message {
char command[32];
char recovery[1024];
};
- command可以有以下两个值
“boot-recovery”：标示recovery正在进行，或指示bootloader应该进入recovery mode
“update-hboot/radio”：指示bootloader更新firmware
-
recovery内容
“recovery\n
<recovery command>\n
<recovery command>”
其中recovery command为CACHE:/recovery/command命令
两种Recovery Case
- FACTORY RESET（恢复出厂设置）
- 用户选择”恢复出厂设置”
- 设置系统将“–wipe_data”命令写入/cache/recovery/command
- 系统重启，并进入recover模式（/sbin/recovery）
- get_args() 将 “boot-recovery”和“–wipe_data”写入BCB
- erase_root() 格式化（擦除）DATA分区
- erase_root() 格式化（擦除）CACHE分区
- finish_recovery() 擦除BCB
- 重启系统
- OTA INSTALL（OTA升级）
- 升级系统下载 OTA包到/cache/some-filename.zip
- 升级系统写入recovery命令“–update_package=CACHE:some-filename.zip”
- 重启，并进入recovery模式
- get_args() 将“boot-recovery” 和 “–update_package=…” 写入BCB
- install_package() 作升级
- finish_recovery() 擦除 BCB
- ** 如果安装包失败 ** prompt_and_wait() 等待用户操作，选择ALT+S或ALT+W 升级或恢复出厂设置
- main() 调用 maybe_install_firmware_update()
- 如果包里有hboot/radio的firmware则继续，否则返回
- 将 “boot-recovery” 和 “–wipe_cache” 写入BCB
- 将 firmware image写入cache分区
- 将 “update-radio/hboot” 和 “–wipe_cache” 写入BCB
- 重启系统
- bootloader自身更新firmware
- bootloader 将 “boot-recovery” 写入BCB
- erase_root() 擦除CACHE分区
- 清除 BCB
-
main() 调用 reboot() 重启系统
Recovery模式流程
/init → init.rc → /sbin/recovery →
main():recovery.c
- ui_init():ui.c ［UI initialize］
- gr_init():minui/graphics.c ［set tty0 to graphic mode, open fb0]
- ev_init():minui/events.c [open /dev/input/event*]
- res_create_surface:minui/resource.c [create surfaces for all bitmaps used later, include icons, bmps]
- create 2 threads: progress/input_thread [create progress show and input event handler thread]
- get_args():recovery.c
- get_bootloader_message():bootloader.c [read mtdblock0(misc partition) 2nd page for commandline]
- check if nand misc partition has boot message. If yes, fill argc/argv.
- If no, get arguments from /cache/recovery/command, and fill argc/argv.
- set_bootloader_message():bootloader.c [set bootloader message back to mtdblock0]
- Parser argv[] filled above
- register_update_commands():commands.c [ register all commands with name and hook function ]
- registerCommand():commands.c
- Register command with name, hook, type, cookie.
- Commands, e.g: assert, delete, copy_dir, symlink, write_raw_image.
- registerFunction():commands.c
- Register function with name, hook, cookie.
- Function, e.g: get_mark, matches, getprop, file_contains
- install_package():
- translate_root_path():roots.c [ “SYSTEM:lib” and turns it into a string like “/system/lib”, translate the updater.zip path ]
- mzOpenZipArchive():zip.c [ open updater.zip file (uncompass) ]
- handle_update_package():install.c
- verify_jar_signature():verifier.c [ verify signature with keys.inc key; verify manifest and zip package archive ]
- verifySignature() [ verify the signature file: CERT.sf/rsa. ]
- digestEntry():verifier.c [ get SHA-1 digest of CERT.sf file ]
- RSA_verify(public key:keys.inc, signature:CERT.rsa, CERT.sf\’s digest):libc/rsa.c [ Verify a 2048 bit RSA PKCS1.5 signature against an expected SHA-1 hash. Use public key to decrypt the CERT.rsa to get original SHA digest, then compare to digest of CERT.sf ]
- verifyManifest() [ Get manifest SHA1-Digest from CERT.sf. Then do digest to MANIFEST.MF. Compare them ]
- verifyArchive() [ verify all the files in update.zip with digest listed in MANIFEST.MF ]
- find_update_script():install.c [ find META-INF/com/google/android/update-script updater script ]
- handle_update_script():install.c [ read cmds from script file, and do parser, exec ]
- parseAmendScript():amend.c [ call yyparse() to parse to command ]
- exeCommandList():install.c
- exeCommand():execute.c [ call command hook function ]
- erase DATA/CACHE partition
- prompt_and_wait():recovery.c [ wait for user input: 1) reboot 2) update.zip 3) wipe data ]
- ui_key_xxx get ALT+x keys
- 1) do nothing
- 2) install_package(\’SDCARD:update.zip\’)
- 3) erase_root() → format_root_device() DATA/CACHE
- may_install_firmware_update():firmware.c [ remember_firmware_update() is called by write_hboot/radio_image command, it stores the bootloader image to CACHE partition, and write update-hboot/radio command to MISC partition for bootloader message to let bootloader update itself after reboot ]
- set_bootloader_message()
- write_update_for_bootloader():bootloader.c [ write firmware image into CACHE partition with update_header, busyimage and failimage ]
- finish_recovery():recovery.c [ clear the recovery command and prepare to boot a (hopefully working) system, copy our log file to cache as well (for the system to read), and record any intent we were asked to communicate back to the system. ]
-
reboot()
Recovery模式流程图
以下流程图绘制了系统从启动加载bootloader后的行为流程。
来自 <http://blog.csdn.net/conowen/article/details/7253503>