I didn't realize you were trying through ext3...
Why if heck are all those partitions in there to begin with? I've never seen that many...
To sum up so far:
At your command prompt on your computer:
adb push Superuser.apk /sdcard/Superuser.apk
adb push su /sdcard/su
adb push busybox /sdcard/busybox
adb push rageagainstthecage-arm5.bin /data/local/tmp/rageagainstthecage-arm5.bin
Open terminal program
$ cd data/local/tmp
$ chmod 0755 rageagainstthecage-arm5.bin
Let the process run until "Forked..." message
See unable to fork message
Hit Menu button and Reset Terminal
Re-open terminal program
You should have a # prompt instead of $
(I've created a script that does the following)
# /data/local/tmp/busybox killall rageagainstthecage-arm5.bin
# mount -o rw,remount -t ext3 /dev/block/mmcblk0p25 /system
# /data/local/tmp/busybox cp /sdcard/Superuser.apk /system/app/Superuser.apk
# /data/local/tmp/busybox cp /sdcard/su /system/bin/su
# /data/local/tmp/busybox cp /sdcard/busybox /system/bin/busybox
# chmod 4755 /system/bin/su
# chmod 4755 /system/bin/busybox
# mount -o ro,remount -t ext3 /dev/block/mmcblk0p25 /system
After this, I can run su in the adb shell and get root via adb.
This explains some of the trouble with other methods...
So what needs to be done to get a custom recovery made/adapted?
Perhaps this will be useful? I'm learning as I go...
dev: size erasesize name
mmcblk0p17: 00040000 00000200 "misc"
mmcblk0p21: 0087f400 00000200 "recovery"
mmcblk0p22: 00400000 00000200 "boot"
mmcblk0p25: 19fbfa00 00000200 "system"
mmcblk0p27: 0cccce00 00000200 "cache"
mmcblk0p26: 53200200 00000200 "userdata"
mmcblk0p28: 01400000 00000200 "devlog"
If the NAND is being presented as mmc type device, perhaps the baseband ("radio") processor is performing mmc to nand conversion, and also acting as a gatekeeper? Don't the baseband processors often perform other interfacing functions in other devices?
This might also be relevant to the ~2.1GB mmc size weirdness - there are of course not going to be non-power-of-two NAND devices so all these ~2.1GB devices must have 4GB of space but may show up with an odd number of sectors due to gatekeeping by the baseband processor.
The baseband processor might simply discard any writes to certain sectors not being performed in an approved fashion (perhaps using special IPC calls or by first authenticating with it to enable write through). Perhaps it caches writes in the "rest" of the NAND space, until the next reboot?
Perhaps there is some kind of dual partition set up like a Tivo for the system partitions, so you write your OS update to the other partition set (through whatever nonstandard methods are used), write config someplace indicating to use the other partition set, reboot, bootloader tries booting and if things don't check out, revert to previous partition set.
|Thread Tools||Search this Thread|