Note: Some of this may be a little technical, but I've tried to lay it out as simply as I can so you can all read about my adventures in Kobo.
So, I've been working on a lot of various things related to the Vox, but my main interest is the following:
Modifying the existing Android build to be as vanilla as possible; add Google Framework Support.
or
To deploy a build of the custom firmware CyanogenMod for the Kobo Vox; add Google Framework Support.
Hacker storytime below:
To that end, I started looking for the recovery image/partition. This will help me by telling me how the Vox performs it's updates/recovery as well as giving me a copy of the recovery, in case I muck things up (and I invariably will, at some point).
So, using my GNU/Linux knowledge (and a tip from FriendlyFire at the CyanogenMod forums) I checked /proc/partitions, which contains partition block allocation information.
Bam!
Code:
major minor #blocks name
179 0 7761920 mmcblk0
179 1 262144 mmcblk0p1
179 2 524288 mmcblk0p2
179 3 1 mmcblk0p3
179 4 5618686 mmcblk0p4
179 5 1048576 mmcblk0p5
179 6 262082 mmcblk0p6
And I used the mount command to see all the mounted partitions.
Pow!
Code:
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/shm tmpfs rw,relatime,size=1024k,mode=775,uid=1000,gid=1003 0 0
/dev/block/mmcblk0p1 /system ext4 ro,relatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p5 /data ext4 rw,nosuid,nodev,relatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p6 /cache ext4 rw,nosuid,nodev,relatime,barrier=1,data=ordered 0 0
/dev/block/vold/179:4 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:4 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
Clearly (okay, clearly to me) there were a few partitions that weren't regularly mounted at boot.
The first one that I investigated was mmcblk0p2 because of that familiar number next to it. 524288 might seem like a pretty random number to you, but I work with computers a lot and I knew that if you divide that by 1024 you get 512 (going from kB to MB).
My spidey senses were going crazy.
I quickly mounted the partition and listed the contents...
Code:
$ ls
recovery_backup_signed.zip
$ _
Wow, that was too easy.
I copied the archive over to my computer and open it up. It contained several image files, but not the type of image files you might be used to. These were disk images, entire filesystems thrown together as a single file. They were named:
recovery-uramdisk.img
uramdisk.img
system.img
It's late right now (or rather, it's early) so I've decided I won't check those out right now, since I know they'll be pretty meaty. Instead I checked out a neat little file that I recognized as the build properties manifest.
Code:
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=GRI40
ro.build.display.id=imx51_bbg-eng 2.3.3 GRI40 eng.victor.20110922.230811 test-keys
ro.build.version.incremental=eng.victor.20110922.230811
ro.build.version.sdk=10
ro.build.version.codename=REL
ro.build.version.release=2.3.3
ro.build.date=Thu Sep 22 23:59:35 PDT 2011
ro.build.date.utc=1316761175
ro.build.type=eng
ro.build.user=victor
ro.build.host=vgonzalez-ubuntu
ro.build.tags=test-keys
ro.product.model=K080
ro.product.brand=freescale
ro.product.name=imx51_bbg
ro.product.device=imx51_bbg
ro.product.board=BBG
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=unknown
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=imx5x
# ro.build.product is obsolete; use ro.product.device
ro.build.product=imx51_bbg
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=imx51_bbg-eng 2.3.3 GRI40 eng.victor.20110922.230811 test-keys
ro.build.fingerprint=freescale/imx51_bbg/imx51_bbg:2.3.3/GRI40/eng.victor.20110922.230811:eng/test-keys
# end build properties
#
# ADDITIONAL_BUILD_PROPERTIES
#
dalvik.vm.heapsize=64m
dalvik.vm.checkjni=false
ro.kernel.android.checkjni=1
ro.setupwizard.mode=OPTIONAL
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt
Some neat little things in there. Not all of it technical. Notice the user and host values. I wonder if there's anyone working at Kobo named Victor Gonzalez?
Actually wait...no, I don't wonder.
The other neat file I found was the updater script. Which tells me a little about how the Vox deals with all these image files.
Code:
# Mount system for check figurepoint etc.
# mount("ext4", "EMMC","/dev/block/mmcblk0p2", "/system");
# Make sure Check system image figurepoint first.
# uncomment below lines to check
# assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "freescale/imx53_evk/imx53_evk/imx53_evk:2.2/FRF85B/eng.b33651.20100914.145340:eng/test-keys");
# assert(getprop("ro.build.platform) == "imx5x");
# unmount("/system");
# reset the boot count
ui_print("reset the boot count... ");
show_progress(0.00, 0);
run_program("/system/bin/toolbox", "dd", "if=/dev/zero", "of=/dev/block/mmcblk0", "bs=1", "seek=30408704", "count=1");
# update kernel, 5%
ui_print("updating kernel... ");
ifelse( package_file_exists("uImage"),
show_progress(0.05, 0);
package_extract_file("uImage", "/cache/uImage");
run_program("/system/bin/toolbox", "dd", "if=/cache/uImage", "of=/dev/block/mmcblk0", "bs=1048576", "seek=1");
delete("/cache/uImage");
, # else
show_progress(0.05, 0);
ui_print(" > skip kernel image update...\n");
);
# update ramdisk, 5%
ui_print("updating uramdisk... ");
ifelse( package_file_exists("uramdisk.img"),
show_progress(0.05, 0);
package_extract_file("uramdisk.img", "/cache/uramdisk.img");
run_program("/system/bin/toolbox", "dd", "if=/cache/uramdisk.img", "of=/dev/block/mmcblk0", "bs=1048576", "seek=11");
delete("/cache/uramdisk.img");
, # else
show_progress(0.05, 0);
ui_print(" > skip uramdisk image update...\n");
);
# update recovery ramdisk, 10%
ui_print("updating recovery uramdisk... ");
ifelse( package_file_exists("recovery-uramdisk.img"),
show_progress(0.1, 1);
package_extract_file("recovery-uramdisk.img", "/cache/recovery-uramdisk.img");
run_program("/system/bin/toolbox", "dd", "if=/cache/recovery-uramdisk.img", "of=/dev/block/mmcblk0", "bs=1048576", "seek=12");
delete("/cache/recovery-uramdisk.img");
, # else
show_progress(0.1, 0);
ui_print(" > skip uramdisk image update...\n");
);
# copy the system.img, 40%
ui_print("updating system... ");
ifelse( package_file_exists("system.img"),
show_progress(0.2, 30);
ui_print("formatting... ");
format("ext4","EMMC","/dev/block/mmcblk0p1");
show_progress(0.2, 30);
ui_print("copying... ");
package_extract_file("system.img", "/dev/block/mmcblk0p1");
, # else
show_progress(0.40, 0);
ui_print(" > skip system image update...\n");
);
# format the data partition if fallback, 40%
ifelse( package_file_exists("update"),
show_progress(0.4, 0);
ui_print("Not formating data partition... ");
, #else
ui_print("Formating data partition... ");
show_progress(0.4, 30);
format("ext4","EMMC","/dev/block/mmcblk0p5");
);
ui_print("DONE\n");
So, all in all: pretty productive prodding.