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.
Nice one, it's a first step toward a custom recovery mode (clockwork).
I am also doing a similar research, not very seriously yet. Right now I'm dumping the images of the mounted partitions, using commands like this:
dd if=/dev/block/mmcblk0p5 of=/extsd/data.img
In principle one can recover the partitions, by interchanging if and of. Of course, this will only work if the system is more-or less working (either WIFi + sshd, as I'm doing now, or adb over USB). I'll also dump the non-mounted partitions.
There must be a way (a special key combination?) which would initiate the system recovery, from mmcblk0p2 on a hardware level (even with a bricked unit). Does anyone know how to do that? I heard Kobo's customer support can be very helpful in this matters - may be I should send them an email. I tried many different combinations (simultaneously pressing two or more of power, volume up/down, back, menu, home buttons) - either from a powered on, or powered off positions, to no avail.
Quote pulsar
I am also doing a similar research, not very seriously yet. Right now I'm dumping the images of the mounted partitions, using commands like this:
dd if=/dev/block/mmcblk0p5 of=/extsd/data.img
In principle one can recover the partitions, by interchanging if and of. Of course, this will only work if the system is more-or less working (either WIFi + sshd, as I'm doing now, or adb over USB). I'll also dump the non-mounted partitions.
There must be a way (a special key combination?) which would initiate the system recovery, from mmcblk0p2 on a hardware level (even with a bricked unit). Does anyone know how to do that? I heard Kobo's customer support can be very helpful in this matters - may be I should send them an email. I tried many different combinations (simultaneously pressing two or more of power, volume up/down, back, menu, home buttons) - either from a powered on, or powered off positions, to no avail.
I've just recently sent an email asking about some development details, but you should definitely ask for anything you need. The email address I used to use was
coderequest@kobo.com but I'm not sure if the Vox team is using the same one.
You might want to try PMing the Kobo members of the forum. I've had good experiences with that.
As for hardware reset, nothing I've tried works. So I'm not sure what it could be.
Thanks for the email - I'll give it a try.
These two are just for /sdcard and /extsd: /dev/block/mmcblk0p4 , /dev/block/mmcblk1p1 .
It looks like Kobo has all system images on one device - internal SD card. If so, one can always disassemble Kobo, take out the card, make a full card image backup, and if anything goes wrong - copy the image back to the card.
Quote pulsar
Thanks for the email - I'll give it a try.
These two are just for /sdcard and /extsd: /dev/block/mmcblk0p4 , /dev/block/mmcblk1p1 .
It looks like Kobo has all system images on one device - internal SD card. If so, one can always disassemble Kobo, take out the card, make a full card image backup, and if anything goes wrong - copy the image back to the card.
I've been working up the nerve to do just that, but I'm worried about reassembly as I've heard the back is glued on, rather than held by snaps.
I mastered snaps at the age of 12. Glue is still my nemesis.
I know there's a unit at work with a peeling back that has to get returned anyway. Depending on how badly that one is peeling maybe I can grab the card and image it all.
If you decide to do it and make an image I've got a ton of hosting space, just PM me and I'll let you upload it to my web server.
I think I'll try emailing first
I've just sent a request to
coderequest@kobo.com regarding full system reset. Let's see when and if I'll get an answer.
Otherwise, just send an email to one of the Kobo team members that posts on this forum.
Anyway, at least we know
where the factory reset is.
I've also found a workaround for doing a hardware factory reset; do a hard reset of the device as it's booting (I can't figure out at exactly what point, but somewhere after the boot-up sound) and you'll get a screen saying you MUST do a factory reset. At this point, there's no turning back. So you better have already used Titanium to do a backup.
Quote jefftheworld
I've been working up the nerve to do just that, but I'm worried about reassembly as I've heard the back is glued on, rather than held by snaps.
The back on mine is held on by snaps . I was surprised at how easily it came off. Just popped a fingernail under the corner *click click click* and it was off. I haven't even owned it for an hour.
I cant see the micro SD slot inside yet but there does seem to be a reset button and the battery visible with just the back cover off. Looks like some screws will have to come off to uncover the main board.
