11-20-2011, 08:31 PM | #76 |
Junior Member
Posts: 2
Karma: 10
Join Date: Nov 2011
Device: Kobo Vox
|
Just use adb over wifi (adbwireless.apk). As a bonus you can then have the vox charging while you play with it.
Adb is part of android. If your unit is truly bricked then it isn't going to do anything. |
11-20-2011, 08:44 PM | #77 |
Connoisseur
Posts: 54
Karma: 52416
Join Date: Nov 2011
Device: kindle 3, kobo vox
|
I gave an example when I had no WIFI (so obviously no adb over WiFi), but fixed the unit using adb over USB. Another advantage is that you should be able to clone the internal SD without any modifications (no apk's to install).
I am actually stuck right now, trying to clone my "pristine" internal SD using "adb shell" and "dd if=/dev/block/mmcblk0 of=/dev/block/mmcblk1". For some reason, I get /dev/block/mmcblk0: read error: I/O error 9527352+0 records in 9527352+0 records out 4878004224 bytes transferred in 3119.049 secs (1563939 bytes/sec) There may be a few explanations. May be my internal SD does have some problem, and that's why the unit went into a full factory reset. Or may be the fact that I am doing it a) adb over USB, or b) it's not rooted, or c) I'm not using busybox. Before, I successfully cloned the card, but I did it over ssh (WiFi), to a rooted device with busybox. Too bad - it looks like I won't get a pristine image. I think adb over USB is one of the very first processes launched, but in a truly bricked unit it won't be available. UPDATE: Hah, I've just successfully did "dd if=/dev/block/mmcblk0 of=/dev/null bs=4096". I also stopped most of the running processes - may be they somehow prevented the copy before? In any case, it appears there are no issues with the internal card. I'll try to repeat it now to the external SD card. BTW, doing adb over USB apparently keeps the battery charged (?!). I've been running it for a few hours, and the battery sign is still "full charge". UPDATE2. I did succeed with creating a clone of my "pristine" internal SD, running dd with bs=4096. Perhaps that was the key? I remember I used the same bs value when I made my first clone SD, over SSH. I'll probably post my mini-guide "adb for Kobo Vox" tomorrow. Last edited by pulsar; 11-20-2011 at 09:32 PM. |
Advert | |
|
11-20-2011, 10:22 PM | #78 |
Groupie
Posts: 186
Karma: 45172
Join Date: Nov 2011
Device: Kobo Vox
|
Awesome! Could you upload it somewhere? If you tar.gz it, t should become 200-300 MB...
Next step is to find that darned bootloader :-) In the freescale tools, they also included tftp - does anybody know if that could be any good? Last edited by hieronymos; 11-20-2011 at 10:27 PM. |
11-20-2011, 10:27 PM | #79 |
Connoisseur
Posts: 88
Karma: 4132
Join Date: Oct 2011
Device: Kobo Vox
|
Well, could be your motherboard. Some motherboard now give 3 the amp output (1.5 A). That might be enough to charge what is used by the device (or near it so it only discharge really slowly).
|
11-21-2011, 07:08 AM | #80 |
Connoisseur
Posts: 54
Karma: 52416
Join Date: Nov 2011
Device: kindle 3, kobo vox
|
|
Advert | |
|
11-21-2011, 07:14 AM | #81 | |
Connoisseur
Posts: 54
Karma: 52416
Join Date: Nov 2011
Device: kindle 3, kobo vox
|
Quote:
You think the compression level will be that high? BTW, I discovered that the "full factory reboot" didn't touch files on the FAT32 partition (user data), and I had some stuff there (not much - a few MBs). |
|
11-21-2011, 10:03 AM | #82 |
Groupie
Posts: 186
Karma: 45172
Join Date: Nov 2011
Device: Kobo Vox
|
Ah, you had turned it on :-) And actually the only thing that will get really compressed is the empty space in all partitions. /system itself has maybe 150 MB of data and the other images are peanuts, basically.
An empty 8Gb usually becomes < 200kb. And if you have the screen off while plugged basically anything will charge the tablet. When you turn the screen off, also the processor scales down and with it everything on the board. I'm quite curious to see battery life when scaling is implemented while awake (when the GPU works). Add: Well, at least I now know where the repos for the recovery are. http://forum.cyanogenmod.com/topic/3...y-on-kobo-vox/ Will have a look at it when I receive the SD and can dissect the system image properly. Last edited by hieronymos; 11-22-2011 at 04:46 PM. |
11-23-2011, 07:52 AM | #83 | |
Groupie
Posts: 186
Karma: 45172
Join Date: Nov 2011
Device: Kobo Vox
|
Quote:
However, on my 512MB Motorola, I created a partition at the end of the SD that I afterwards mounted into the system storage, and then moved apps and linked them with http://forum.xda-developers.com/showthread.php?t=919326 I guess Link2SD could at least make it easy for you to create the mount scripts. And if you really just want to throw apps at your Kobo, it will do everything you want. Otherwise, you could have a look at what Link2SD actually does and just mount the second partition inside the first partition. Which also mean you have to mount the second SD /after/ the first, contrary to Link2SD. The second partition should still show up in Windows when you plug the cable - at least, on my Moto it shows in Linux. Maybe try not to expand the last partition in the original image, but to append another one. If it still boots, that solution should work :-) Last edited by hieronymos; 11-23-2011 at 07:58 AM. |
|
11-23-2011, 11:01 AM | #84 | |
Connoisseur
Posts: 54
Karma: 52416
Join Date: Nov 2011
Device: kindle 3, kobo vox
|
I finally figured it out how to unpack the raw images present in the recovery*.zip file inside unmounted partition /dev/block/mmcblk0p2 - at least for uramdisk and recovery-uramdisk . I did the following, for both images:
Code:
dd if=uramdisk.img bs=64 skip=1 of=uramdisk.gz gunzip -v uramdisk.gz mkdir uramdisk cd uramdisk cat ../uramdisk | cpio -iv http://www.physics.mcmaster.ca/~syam/uramdisk.tgz http://www.physics.mcmaster.ca/~syam...y-uramdisk.tgz The recovery image is the most interesting - presumably that is what is executed when you use the unit for the first time, or if you trigger a full factory reset. Have a look at its init.rc file (below). It is small, it does the most basic stuff - including starting adbd, and running sbin/recovery. The latter is a native ARM binary, statically linked, so I can't tell what it's doing. Can it include the initial Kobo signup stage? The uramdisk image doesn't have this recovery binary, and also have a different (much longer) init.rc. Okay, I can see something by running "strings sbin/recovery". E.g., the following strings are present there: Quote:
I think the only way to test if these raw images are signed (locked) is to disassemble the unit, take out the internal SD card, make a copy of the non-live file system using dd, unpack it (say, the uramdisk), make a tiny modification (create a tiny file in the root directory?), repack it, copy it back to the SD card (or to another card - safer), put the modified card in Kobo, and power it up. If it refuses to power up - the raw images are locked, if everything is normal - at least that image (uramdisk) is not locked, which would let us customize it (init.rc etc). Does it all make sense? Code:
on early-init start ueventd on init export PATH /sbin:/system/bin export ANDROID_ROOT /system export ANDROID_DATA /data export EXTERNAL_STORAGE /sdcard symlink /system/etc /etc symlink /system/bin/toolbox /system/bin/ls symlink /system/bin/toolbox /system/bin/sync symlink /system/bin/toolbox /system/bin/mount symlink /system/bin/toolbox /system/bin/umount symlink /system/bin/toolbox /system/bin/ps symlink /system/bin/toolbox /system/bin/kill symlink /system/bin/toolbox /system/bin/cat symlink /system/bin/toolbox /system/bin/echo symlink /system/bin/toolbox /system/bin/date symlink /system/bin/toolbox /system/bin/dd symlink /system/bin/toolbox /system/bin/rm symlink /system/bin/toolbox /system/bin/mv symlink /system/bin/toolbox /system/bin/ln symlink /system/bin/toolbox /system/bin/insmod symlink /system/bin/toolbox /system/bin/rmmod symlink /system/bin/toolbox /system/bin/lsmod symlink /system/bin/toolbox /system/bin/reboot symlink /system/bin/toolbox /system/bin/wipe symlink /system/bin/toolbox /system/bin/cmp symlink /system/bin/toolbox /system/bin/dmesg symlink /system/bin/toolbox /system/bin/df symlink /system/bin/toolbox /system/bin/log symlink /system/bin/toolbox /system/bin/sleep symlink /system/bin/toolbox /system/bin/chmod symlink /system/bin/toolbox /system/bin/chown symlink /system/bin/toolbox /system/bin/uptime symlink /system/bin/toolbox /system/bin/vmstat mkdir /sdcard mkdir /system mkdir /data mkdir /cache mount /tmp /tmp tmpfs mount vfat /dev/block/mmcblk0p4 /sdcard mkdir /extsd mount vfat /dev/block/mmcblk1p1 /extsd mkdir /recovery mount ext4 /dev/block/mmcblk0p2 /recovery ro on boot ifup lo hostname localhost domainname localdomain class_start default service ueventd /sbin/ueventd critical service recovery /sbin/recovery service adbd /sbin/adbd recovery disabled on property:persist.service.adb.enable=1 start adbd on property:persist.service.adb.enable=0 stop adbd # Reset boot count #start = 1024 * 1024 * 29 = 30408704 service boot_count /system/bin/toolbox dd if=/dev/zero of=/dev/block/mmcblk0 bs=1 seek=30408704 count=1 oneshot service boot_count /system/bin/toolsbox sync oneshot One more thing: the recovery_uramdisk contains a text file res/keys, which is filled with comma-separated numbers (keys for signing the images?). sbin/recovery has a reference to this file. Last edited by pulsar; 11-23-2011 at 11:15 AM. |
|
11-23-2011, 01:27 PM | #85 |
Groupie
Posts: 186
Karma: 45172
Join Date: Nov 2011
Device: Kobo Vox
|
Great! Skipping the bootloader was a great idea :-)
The recovery is usually either being called from the button combination or from within the OS. So the initial signup stage, if I understand right what you mean, happens within Android - you sign up there, then it downloads the update.zip and reboots into the recovery (I'm quietly wondering what happens if we place a update.zip on the sdcard and reboot recovery - I like simple solutions). You can browse what the recovery is usually supposed to do here: https://github.com/android/platform_recovery The keys you have there might well simply be signed by victor@vgonzalez-ubuntu or K01.01.20110801 or something else that is automated in the freescale build process, which does it by default. But of course we need to find out if their use is actually enforced. What we (or at least me) want inside the recovery is fastboot (it doesn't seem like it's in there), so we can flash without opening up. Unfortunately, I just checked the freescale recovery and it isn't there either - I'm still trying to find the relevant piece of information on this one. I wonder if Victor is coming around from time to time, smiling down on us as we are sitting in front of these riddles. :-) P.S.: *fingers crossed that a distributer has asked for a way one-click solution to recover bricked units...* :-) P.S.2: Well, they didn't. Back to reading, I guess. Last edited by hieronymos; 11-24-2011 at 08:09 PM. |
11-25-2011, 10:26 PM | #86 |
Junior Member
Posts: 5
Karma: 10
Join Date: Nov 2011
Device: Kobo Vox
|
I don't know if you guys have heard, but apparently there's now a build of ICS for the iMX53. Who knows, maybe it could be adapted to the iMX51
|
11-26-2011, 12:56 PM | #87 |
Groupie
Posts: 186
Karma: 45172
Join Date: Nov 2011
Device: Kobo Vox
|
Debian and Linaro are working on the imx51 since it came out. It's use as a tablet is rather new. They have prepared images for imx. You can also download an Ubuntu image directly from freescale.
The problem is not getting any port running, but to get it on the device in an easy way. Still waiting for the SD :-/ Last edited by hieronymos; 11-26-2011 at 01:00 PM. |
11-26-2011, 02:29 PM | #88 |
Groupie
Posts: 186
Karma: 45172
Join Date: Nov 2011
Device: Kobo Vox
|
I just found something.
a) Device is turned off. b) Hit power shortly, just to turn it on. c) Hit power again and stay on it for a few seconds. Result: green light keeps blinking, screen stays black. I have nothing popping up in dmesg - no fastboot. No Elvis in Windows either. But there is definitely something. Maybe this is where tftp could come in handy. Last edited by hieronymos; 11-26-2011 at 02:32 PM. |
11-26-2011, 03:32 PM | #89 |
Groupie
Posts: 190
Karma: 157090
Join Date: Nov 2011
Device: Kobo, Kobo Vox
|
If you want a quick an easy way of using Linux you can always do a chroot install.
I've got a chroot Debian install on my Vox. It runs on top of Android so it's still fully functional as an Android device, but with the added power of linux. If you want a full GUI you can even install a linux desktop environment and a VNC server, then use a VNC viewer app on the Android side to interact. Edit: Made a tutorial of it a while back. It's a little slow, but it'll walk you through everything you need to know about doing the install. If you want full control of your Android install via the linux install you'll want to enable the "Bind /" option. Last edited by jefftheworld; 11-26-2011 at 03:36 PM. |
11-26-2011, 04:13 PM | #90 |
Groupie
Posts: 186
Karma: 45172
Join Date: Nov 2011
Device: Kobo Vox
|
512MB RAM, of which are 370MB available - 170MB sytem apps = 200 MB for a chroot (starts swapping earlier) = not fun working on LibreOffice. :-)
Also, a native Linux would make it easier to check what we can do with the USB plug. However, I'm getting a little frustrated, so I'll take a break until Kobo provides the GPL sources that they have to provide. What they did with uboot should be documented. |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Touch Hacking into the Kobo Touch | stef70 | Kobo Developer's Corner | 60 | 03-04-2017 11:32 AM |
Kobo Vox, Kobo preorder | shannont | Kobo Tablets | 5 | 12-17-2012 09:52 PM |
What Can the Kobo Vox Do? | pokee | Kobo Tablets | 36 | 11-18-2011 03:00 AM |
Where do you use your kobo vox? | ron1959 | Kobo Tablets | 8 | 11-04-2011 09:57 PM |
Kobo won't read books already in progress | La Coccinelle | Kobo Reader | 3 | 11-29-2010 03:29 PM |