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>