默认的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版本)

 
 

/********************************************************************************************

 * authorconowen@大钟                                                                                                                          

 * E-mailconowen@hotmail.com                                                                                                             

 * http://blog.csdn.net/conowen                                                                                                              

 * 注:本文为原创,仅作为学习交流使用,转载请标明作者及出处。      

 ********************************************************************************************/


..\rockdev\表示RKAndroidTool所在目录的上一层目录下的rockdev文件夹。

工具预设目录为..\rockdev\,若扫描有Paremeter ,则载入,读出分区表信息,关于Paremeter ,参看第2点。

工具的”偏移”(offset)表示分区的起始地址,也参看第2点。

 
 

 
 

1Loader.bin (100K左右)

系统启动必须的引导文件

RK29xxLoader(L)_V2.08.bin

2Paremeter 分区信息表(50K左右)

打开rockdev目录下的Paremeter 文件,内容如下

 
 

 
 

[java] 

view plain

copy

  • 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] 

    view plain

    copy

  • mtdparts=rk29xxnand  

    则表示机器nand flash的分区信息。

    [java] 

    view plain

    copy

  • 0x00002000@0x00002000(misc)  

    右边的0x00002000表示起始地址,左边的0x00002000表示misc分区的容量大小。至于为什么要从0x00002000开始,因为分区表Paremeter 也要占有flash的容量,Paremeter 是从0x00000000开始的。左右两边数值相加,就等于下一个分区的起始地址,如此类推。如到了recovery分区。

    [java] 

    view plain

    copy

  • 0x00008000@0x00010000(recovery)  

    起始地址为0x00010000recovery分区大小为0x00008000,所以下一个backu分区的起始地址为0x00018000

     
     

    另外,关于用户区userdata,也就是rom区。常说的扩容就是扩展此分区。

    [java] 

    view plain

    copy

  • 0x00100000@0x000ca000(userdata),  

    先来算算此分区的大小。

    0x00100000为十六进制,折算成十进制为1048576,因为瑞芯微rockchip采用的是0.5K为单位。折算结果为

    1048576*0.5K=524288K

    524288K/1024=512M

    也就是说rom区容量为512M

    假若要扩展此分区,则往后的各个偏移量都要相加推移。

    到了最后一个user分区,

    [java] 

    view plain

    copy

  • @0x0024c000(user)  

    左边的”-“表示user分区占有剩余的nand flash所有容量。也就是常常存放一些用户的数据如电影、音乐之类的。不同于rom区的存放安装软件。

     
     

    3Misc.img1K左右)

    cpu加电之后,启动bootloader,(即是RK29xxLoader(L)_V2.08.bin),就会读取MISC分区第一块的内容,
    决定进入recovery模式还是升级基带Baseband ProcessorBP)或做其它事情。而更改Misc内容的操作为按下某个按键或者用户设置系统。

    4kernel.img6M左右

    内核镜像,经过编译得出zImage,即为Kernel.img。或者SDK包直接附带。

    5boot.img8M左右

    系统bootload启动之后,进入正常启动模式,就会读取boot.img进去系统正常模式。

    boot.img包括了kernel.img镜像和一个根文件系统(rootfs

    6recovery.img12M左右

    系统bootload启动之后,通过读取Misc分区的内容,确认如果是进入Recovery模式的话,进去读取Recovery.img

    recovery.img包括了一个kernel.img与一个根文件系统(rootfs),kernel镜像与boot,img的完全一样。

     
     

    7system.img100+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 ProcessorBP)或做其它事情

    而上述寄存器与分区的值是有按键触发或者软件触发的。

    a)       开机按reset+返回键,系统进入recovery模式,加载recovery.imgrecovery.img包含内核,基本的文件系统,用于工程模式的烧写

    b)       开机按Power,正常启动系统,加载boot.imgboot.img包含内核,基本文件系统,用于正常启动机器(以下只分析正常启动的情况)

     
     

    第二步:
    启动内核kernel

    1)       源码:kernel/*

    2)       说明:kernelbootloader加载

    第三步:    文件系统(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 serverzygote它负责最基本的虚拟机的建立,以支持各个应用程序的启动,而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(复制目录)。该包一般被下载至SDCARDCACHE分区下。如果对该包内容感兴趣,可以从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 + powerbootloader模式,ADP里则可以使用fastboot模式
  • home + powerrecovery模式
  • 正常启动

    Bootloader正常启动,又有三种方式,按照BCBBootloader Control Block, 下节介绍)中的command分类:

  • command == \’boot-recovery\’
    启动recovery.imgrecovery模式
  • command == \’update-radio/hboot\’
    更新firmwarebootloader)
  • 其他

    启动boot.img

    Recovery涉及到的其他系统及文件

  • CACHE分区文件

    Recovery 工具通过NAND cache分区上的三个文件和主系统打交道。主系统(包括恢复出厂设置和OTA升级)可以写入recovery所需的命令,读出recovery过程中的LOGintent

  • /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/logrecovery过程日志,由主系统读出
  • /cache/recovery/intentrecovery输出的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 commandCACHE:/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 INSTALLOTA升级)
  • 升级系统下载 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+SALT+W 升级或恢复出厂设置
  • main() 调用 maybe_install_firmware_update()
  • 如果包里有hboot/radiofirmware则继续,否则返回
  • “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>

     
     

     
     

     
     

     
     

     
     

     
     

     
     

版权声明:本文为any35原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/any35/archive/2013/02/05/2893297.html