• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

ADB on the Venture

No luck. They all look like this:
Code: 
# dd if=mtdblock4 of=/mnt/sdcard/mtdblock4
dd if=mtdblock4 of=/mnt/sdcard/mtdblock4
mtdblock4: read error: I/O error
0+0 records in
0+0 records out
0 bytes transferred in 0.001 secs (0 bytes/sec)
 
mtd block is boot and mtd block 7 is recovery. Just do a cat /process/mtd and it will list the structure of the mtd blocks. You should be able to pull the boot.img from block one, and split it to get the zImage to use with building a recovery!
 
ok so mtdblock7 it is then, such an odd numbering scheme... so if dd wont work maybe dump_image?

dump_image boot /data/local/boot.img
dump_image recovery /data/local/recovery.img

some people claim cat works too so you could in theory

cat /dev/block/mtdblock7 >/data/local/cat-recovery.img


adb pull /data/local/boot.img
adb pull /data/local/recovery.img
 
Code: 
# ls -l mtd*
ls -l mtd*
brw------- root     root      31,   0 2012-09-12 07:08 mtdblock0
brw------- root     root      31,   1 2012-09-12 07:08 mtdblock1
brw------- root     root      31,   2 2012-09-12 07:08 mtdblock2
brw------- root     root      31,   3 2012-09-12 07:08 mtdblock3
brw------- root     root      31,   4 2012-09-12 07:08 mtdblock4
brw------- root     root      31,   5 2012-09-12 07:08 mtdblock5
brw------- root     root      31,   6 2012-09-12 07:08 mtdblock6
brw------- root     root      31,   7 2012-09-12 07:08 mtdblock7
# cat /dev/block/mtdblock7 >/mnt/sdcard/mtdblock7
cat /dev/block/mtdblock7 >/mnt/sdcard/mtdblock7
/dev/block/mtdblock7: invalid length
#
# dump_image boot /mnt/sdcard/boot.img
dump_image boot /mnt/sdcard/boot.img
dump_image: not found

Where does dump_image come from? It apparently isn't in busybox.
 
Sure. Also, I dug a little deeper.
Code: 
# ls -l /dev/block/platform
ls -l /dev/block/platform
drwxr-xr-x root     root              2012-09-12 07:08 msm_sdcc.1
#
# cd /dev/block/platform/msm_sdcc.1
cd /dev/block/platform/msm_sdcc.1
# ls -l
ls -l
lrwxrwxrwx root     root              2012-09-12 07:08 mmcblk0p1 -> /dev/block/mmcblk0p1
drwxr-xr-x root     root              2012-09-12 07:08 by-num
lrwxrwxrwx root     root              2012-09-12 07:08 mmcblk0 -> /dev/block/mmcblk0
#
# ls -l by-num
ls -l by-num
lrwxrwxrwx root     root              2012-09-12 07:08 p1 -> /dev/block/mmcblk0p1
#
# ls -l /dev/block/mmcblk0p1
ls -l /dev/block/mmcblk0p1
brw------- root     root     179,   1 2012-09-12 07:08 mmcblk0p1# du mmcblk0p1
#
# du /dev/block/mmcblk0p1
0       /dev/block/mmcblk0p1
#
 
RQ3eD.jpg


wassup? ;P
 
Shabbypenguin said:
that will require kernel hacking
Click to expand...

or making a rudimentary script that will run scripts out of /system/etc/init.d and placing it as /system/etc/install-recovery.sh because this script will get ran at boot.

And as far as I can tell, this kernel already has support for ext2,3,and4 filesystems. You can check under /proc/filesystems to see what filesystems are supported. all the ext filesystems are in there!
 
Yup, ext2, ext3, and ext4:
Code: 
# cat /proc/filesystems
cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   cgroup
nodev   tmpfs
nodev   debugfs
nodev   sockfs
nodev   pipefs
nodev   anon_inodefs
nodev   rpc_pipefs
nodev   devpts
        ext3
        ext2
        ext4
nodev   ramfs
        vfat
nodev   nfs
        yaffs
        yaffs2
nodev   mtd_inodefs
#
 
When I get some time at my computer I will post a flashable zip to enable init.d scripts on the stock kernel then post the scripts for moving /data/app, /data/data, data/dalvik-cache to the sdcard partition mounted at /sd-ext.
 
As far as not having the kernel source goes, I wouldn't be surprised if one of the kernels from the alcatel One Touch series worked as a drop-in replacement. The kernels from the One Touch 910 and yours are both based off the qualcomm/code aurora kernel tree. You may be able to find one to start with by using "zcat /proc/config.gz" on your phone and then trying to find a One Touch kernel that matches closely. You can also try matching the exported symbol names in /proc/kallsyms to make sure there isn't any JukeB-specific code that was added. I doubt there would be, though. It sould like PCD just got a pile of devices from Alcatel, slapped a PCD sticker on them, and handed them off to the next person in line.
 
giantpune said:
As far as not having the kernel source goes, I wouldn't be surprised if one of the kernels from the alcatel One Touch series worked as a drop-in replacement. The kernels from the One Touch 910 and yours are both based off the qualcomm/code aurora kernel tree. You may be able to find one to start with by using "zcat /proc/config.gz" on your phone and then trying to find a One Touch kernel that matches closely. You can also try matching the exported symbol names in /proc/kallsyms to make sure there isn't any JukeB-specific code that was added. I doubt there would be, though. It sould like PCD just got a pile of devices from Alcatel, slapped a PCD sticker on them, and handed them off to the next person in line.
Click to expand...

I'm pretty sure it's the One Touch 909... Looks nearly identical with identical specs anyways...

http://www.alcatelonetouch.com/usa/products/smartphones/ot-909b.html
 
You must log in or register to reply here.
Back
Top Bottom