Related
Well, since i'm not aware of anyone else doing it, and it will be necessary for any real development to occur, I have decided to try porting Clockworkmod Recovery to the Ouya. I am downloading ubuntu right now and I'll start trying to build it from source against our current recovery tonight or tomorrow night depending on how long the setup and prerequisites take.
The reason I'm posting this now, is to solicit help. I've never built CWM before, but XDA has a really great tutorial I'm going to follow, but if anyone here has had experience in the past I'd love some help/tips, and other than that I would like a few brave souls to volunteer and try flashing it on their Ouya when/if I have a build that works on my own.
I'll update this thread with my progress, if I make any, and please let me know if any of you are willing to help in any way.
Update 1:
I have compiled a version of CWM recovery that theoretically should work, but I'm unable to flash it. I have installed flash_image onto the ouya and it works fine, but i normally would have used "flash_image recovery recovery.img" however there is no "recovery" partition on the ouya. This is what I get:
./flash_image recovery recovery.img
error scanning partitions: No such file or directory
Mount reveals the following info:
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,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
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 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
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xatt
r,acl,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 rw,nosuid,nodev,noatim
e,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=wri
teback 0 0
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,nosuid,nodev,noatime
,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writ
eback 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1
023,default_permissions,allow_other 0 0
This is the script from the OTA update:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
but I can't make any sense of it. If anyone can help out i'd much appreciate it...
sonofskywalker3 said:
but I can't make any sense of it. If anyone can help out i'd much appreciate it...
Click to expand...
Click to collapse
This seems to be the magic lines in the update script:
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
Click to expand...
Click to collapse
I don't know much about the applypatch program. It might just be another script. Since it isn't being called with a "./", I'd imagine it is installed somewhere that the path mentions. Try looking for "applypatch" to see if it is a program or script. In a terminal running on the Ouya, try running "echo $PATH". Hopefully you get a list of directories containing program locations (e.g. /usr/bin/ ...etc). Applypatch might be in one of those directories.
UPDATE 1:
applypatch is a binary, not a script. It is located in /system/bin/
I tried running it without arguments on my Nexus 7 (to see if we would luck out with a nice "usage" message), but for some annoying reason I can't give it execute permissions, even as root. I'll look deeper into the scripts
UPDATE 2:
I need to verify this on my Ouya, but from the updater-script in the latest OTA, the kernel partition is /dev/block/platform/sdhci-tegra.3/by-name/LNX (I'm going out on a limb here boys, but I think LNX stands for Linux, aka, our kernel, lol).
UPDATE 3:
Seems like the recovery partition is /dev/block/platform/sdhci-tegra.3/by-name/SOS
I don't know much about the details of "applypatch", but the recovery script you posted above seems to first check to see if the recovery partition hashes to f80238c4f4a53888b547e4463fb4751343f23412 (the hash of the latest and greatest recovery). If it doesn't, then we flash the latest recovery, which from the looks of it consists of the kernel (in LNX) with a patch applied to it from recovery-from-boot.p (another mess of binary). In other words, it looks like they build a recovery from the existing kernel, as the name "recovery-from-boot" implies (the kernel is packaged in a file called boot.img).
Long story short, it looks like you can write to the block device /dev/block/platform/sdhci-tegra.3/by-name/SOS to write a new recovery. Aka, in a hacked version of the OTA script, include the line
package_extract_file("recovery.img", "/dev/block/platform/sdhci-tegra.3/by-name/SOS");
where recovery.img is the name of your new recovery. They did something very similar to the kernel (LNX). I'm pretty sure that the correct way to do something like this is to use "dd" after verifying the image is correct (by running a hash against the image). I'm not sure why the Ouya team is using package_extract_file() instead of dd. I'm not in front of my Ouya though, LNX and SOS could be folders rather than block devices (although /dev/block seems to imply otherwise).
You can remove most of the other lines in the script that install the actual OTA update files. If you need help, let me know. I can make a custom update-script for you.
WARNING!!!!!!!! The above is just my take on things from looking at the scripts for 20 minutes. This could total brick your device if your recovery isn't of the right format or is not correctly built. Don't say I didn't warn ya.
You might want to read off the contents of the SOS to compare in a hex editor to your recovery. We might find out some things that would prevent a brick.
Sent from my Nexus 7 using xda premium
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...
sonofskywalker3 said:
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...
Click to expand...
Click to collapse
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
sonofskywalker3 said:
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
Click to expand...
Click to collapse
It probably doesn't work because the update.zip we're using is signed.
Just a thought, but an easier way to go, albeit dangerous, is to do the following. You need root access over adb to do this. Using dd is VERY dangerous. THIS MIGHT NOT WORK. We need to make sure that what we are writing to (/dev/block/platform/sdhci-tegra.3/by-name/SOS) is truly the block device containing the recovery partition or else this might brick the Ouya. In the past, I've seen recovery written to /dev/block/mmcblk0pX, where X is the recovery partition for the particular device. I'm not much of a tegra guy. I know more about Samsung's stuff.
1) place the recovery.img on your ouya (let's say in /sdcard/recovery.img)
2) open a terminal running on your Ouya (over adb would probably be best, e.g. "adb shell")
3) enter a root shell, type "su"
4) make a backup of your existing recovery partition with "dd if=/dev/block/mmcblk0p1 of=/sdcard/origRecovery.img"
5) write the new recovery to the recovery partition with "dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p1"
6) perform the following from user mbm in the Ouya forums to get into recovery (thread http://forums.ouya.tv/discussion/1380/recovery-mode)
This is a hack, an unintended sequence of events that results in recovery mode; what you need to do is crash the startup using sysrq.
For this you'll need a usb keyboard with the sysrq key, this is usually the printscreen button if your keyboard isn't labeled. As the OUYA starts to boot, hold down the alt-sysrq keys and press i, wait a few seconds and then repeat. This key combination is kill-all-tasks; thanks to whoever left this enabled in the kernel. Each time you kill the tasks the init process will restart them, after about 5 or 6 times init will print a warning on the console that one of the processes marked critical has been restarted too many times -- this then triggers an automatic reboot into recovery mode.
Unfortunately it's not always obvious when the ouya is in recovery mode. You might get screen with the ouya logo and a large red exclamation mark, or the screen might be entirely black; usually I got a black screen. Press the home button on the keyboard to bring up the recovery menu; it's actually a toggle so feel free to press the home button repeatedly until you see the menu since the timing isn't otherwise obvious.
Click to expand...
Click to collapse
There are two big unknowns here:
1) We don't know for sure that the new recovery (CWM) will actually work
2) We don't know for sure that /dev/block/platform/sdhci-tegra.3/by-name/SOS is the correct place to be writing a recovery
I'll see what I can dig up regarding /dev/block/platform/sdhci-tegra.3/by-name/SOS
---------- Post added at 02:53 PM ---------- Previous post was at 02:30 PM ----------
/dev/block/platform/sdhci-tegra.3/by-name/SOS is a link to /dev/block/mmcblk0p1
So far, it appears that the layout is the following:
Kernel (boot.img) is mmcblk0p2
Recovery is mmcblk0p1
System is mmcblk0p3
Sent from my SCH-I535 using xda premium
---------- Post added at 02:56 PM ---------- Previous post was at 02:53 PM ----------
I would imagine that if the recovery partition really is SOS, then the above steps would work if you could run them as root.
Sent from my SCH-I535 using xda premium
Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
mybook4 said:
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
Click to expand...
Click to collapse
It's 8MB. If you dd to the block device (e.g. mmcblk0p1), you can't write out of bounds. The linux kernel knows the size and refuses it.
rayman said:
Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
Click to expand...
Click to collapse
I did the following with skywalker's recovery.
1) Attached a usb keyboard to the Ouya's full size usb port
2) Attached my computer to the Ouya's micr usb port
3) Ran "adb reboot bootloader" (the Ouya rebooted to a blank screen)
4) Waited 30 seconds and ran "fastboot boot recovery.img" (skywalker's recovery file)
The Ouya rebooted into CWM Recovery v6.0.3.2!
Error messages were encountered on the recovery screen (image attached)
5) Navigated around CWM with the arrow keys and the enter key
6) Rebooted with "reboot system now". Ouya booted right up.
When we flash the recovery to mmcblk0p1, we should rename /system/etc/install-recovery.sh (and maybe /system/recovery-from-boot.p) to prevent the recovery partition from being overwritten.
Looks like we need to adjust the recovery so it properly mounts the partitions. Hopefully after that we are good to go.
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.
sonofskywalker3 said:
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.
Click to expand...
Click to collapse
I think it should be a matter of placing the proper partitions in the fstab prior to creating the recovery image. From the error messages it looks like /cache and /data are the culprits.
If you get a chance to, please post the fstab you use so we can double check everything (want to avoid the potential for bricks).
Sent from my SCH-I535 using xda premium
I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?
sonofskywalker3 said:
I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?
Click to expand...
Click to collapse
I'm still new at making a recovery.fstab, but I noticed the following:
From running "ls -l /dev/block/platform/sdhci-tegra.3/by-name/"
lrwxrwxrwx root root 2013-05-25 02:23 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-05-25 02:23 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-05-25 02:23 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-05-25 02:23 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-05-25 02:23 MSC -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-05-25 02:23 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2013-05-25 02:23 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-05-25 02:23 UPP -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-05-25 02:23 USP -> /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Since the APP, CAC, LNX files are links to mmcblk0pX devices, maybe we should be using the mmcblk0pX names?
We should look at more examples to see what the recovery.fstab for other devices looks like. From what I've seen of other devices, mmcblk0pX devices are listed in recovery.fstab.
P.S. So far, I think we are fairly certain that
APP is the system partition
CAC is the cache partition
LNX is kernel boot.img
SOS is the recovery partition
I'm not sure what the rest are (data, etc). Is there a definitive list somewhere?
Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA length=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Update:
Well still no love, and no noticeable progress between recovery 2 and 7, but I feel like we're chipping away in the right direction. I'll seek some help from some more experienced recovery people tomorrow.
sonofskywalker3 said:
Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/systemext4/dev/block/platform/sdhci-tegra.3/by-name/APP
/cacheext4/dev/block/platform/sdhci-tegra.3/by-name/CAC
/dataext4/dev/block/platform/sdhci-tegra.3/by-name/UDAlength=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/bootemmc/dev/block/platform/sdhci-tegra.3/by-name/LNX
/recoveryemmc/dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Click to expand...
Click to collapse
Good stuff.
Not sure how we are going to get the field length= . I noticed the same field being used in the US Galaxy S III recovery https://raw.github.com/CyanogenMod/android_device_samsung_d2-common/cm-10.1/recovery.fstab
length= field is probably not needed, as the stock recovery doesn't list it.
Sent from my SCH-I535 using xda premium
Here's the recovery.fstab from my Ouya's recovery partition.
# mount point fstype device
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard vfat /dev/block/platform/sdhci-tegra.0/by-num/p1
Click to expand...
Click to collapse
I tried doing CWM build with this recovery.fstab. /system, /data, and /cache all mounted.
Couldn't mount /sdcard automatically (trying to choose zip from sdcard) or manually (in mounts and storage, mount /sdcard).
I tweaked the recovery.fstab to the following:
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard datamedia /dev/null
Click to expand...
Click to collapse
This one mounted /sdcard correctly. I can "choose a zip from sdcard". I didn't actually choose a zip yet. I didn't format any of the partitions. I suppose we could try making a quick cwm zip to write something to the sdcard to test it out.
I've attached the stock Ouya recovery.img (from SOS partition). THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of the stock recovery.img. The md5 hash of the unzipped recovery.img is a6c1a6962984e9080ed8821628c4cc3f.
I've attached the CWM recovery.img that worked for me. THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of a newly built CWM recovery.img. The md5 hash of the unzipped recovery.img is c6b37906f280b16cd200503c3cde6dfb.
well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Update!
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!
sonofskywalker3 said:
well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Click to expand...
Click to collapse
I edited the comment right above yours.
Recovery Builder wants the stock recovery.img, so I used adb to copy my Ouya's recovery partition to the sdcard, then I used adb pull to copy the recovery partition to my computer.
1) adb shell
2) su
3) cd /dev/block/platform/sdhci-tegra.3/by-name
4) dd if=SOS of=/sdcard/stockRecovery.img
5) exit
6) adb pull /sdcard/stockRecovery.img .
I used the recovery.fstab attached to this post. I obtained the stock Ouya recovery.fstab by doing the following:
I used split_bootimg.pl to split up the recovery.img into kernel and ramdisk (see Alternate Method in http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images). I used gzip to unzip the ramdisk and saw the stock recovery.fstab in /etc.
Here's what I did step by step:
1) split_bootimg.pl stockRecovery.img
2) mkdir ramdisk
3) cd ramdisk
4) gzip -dc ../stockRecovery.img-ramdisk.gz | cpio -i
in the ramdisk directory is etc/recovery.fstab
I then copied this file and edited the last line (/sdcard stuff). I used the new recovery.fstab with the Recovery Builder.
sonofskywalker3 said:
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!
Click to expand...
Click to collapse
Awesome! Let us know how the backup/restore and zip flashing goes.
Once we verify that this CWM works correctly, people should be able write the new recovery by doing the following (NOTE this wasn't tested yet. I need to test it out first):
1) adb reboot bootloader
2) wait 30 seconds (blank screen is normal)
3) fastboot flash recovery recovery.img
4) fastboot reboot recovery (need a usb keyboard to navigate CWM)
5) flash a CWM zip to prevent stock recovery overwrite (we need to make this. The zip file should mount /system, rename recovery-from-boot.p to recovery-from-boot.bak, and unmount /system)
6) profit
Most of this could potentially be automated into a root/install CWM script.
Backup worked fine, flash worked and I'm booting now to make sure it put the files where it was supposed to and see if they work. Then i'll reboot and restore and make sure those files go away.One thing to note is that when i choose reboot system now it asked me to disable recovery flash,so I took the plunge and said yes, we'll see if it goes back to stock or not...
Update:
The .zip I built said it flashed correctly (unless i'm reading wrong the parts i could see with the overscan problems i'm having) but the files did not go to /system/app. I have attached the .zip file to see if I did something wrong with it, I just grabbed a sample from online and changed the files, haven't checked updater-script yet. I am restoring now, will post update on if that works.
It rebooted to stock recovery, as I expected, so still haven't flashed it just yet.
Well my oversensitive keyboard just hit enter twice so I'm actually backing up again, but I have to leave and take my daughter to a muesuem now, so I won't be able to continue until later. Good luck, i'll be keeping up with this thread on my phone.
Edit: removed non working zip
I have device with IMEI NULL that I want to mount (or replace the efs into generic) in adb in similar with this script:
cd c:/androidsdk/tools
adb shell
su
mke2fs /dev/block/mmcblk0p3 ( skip to next step if fail)
mount -w -t ext4 /dev/block/mmcblk0p3
reboot
Click to expand...
Click to collapse
I tried the above script but unfortunately it brokes the partition because I think that code is not for i8190, but no worry about that because I already managed to fix it with pit file.
Anybody can share it with me?especially developers please.
Thanks in advance.
cz4r3n said:
I have device with IMEI NULL that I want to mount (or replace the efs into generic) in adb in similar with this script:
I tried the above script but unfortunately it brokes the partition because I think that code is not for i8190, but no worry about that because I already managed to fix it with pit file.
Anybody can share it with me?especially developers please.
Thanks in advance.
Click to expand...
Click to collapse
0p3 is PIT partition. mmcblk0p11 is EFS, but i'm not sure what you're trying to do here.
tys0n said:
0p3 is PIT partition. mmcblk0p11 is EFS, but i'm not sure what you're trying to do here.
Click to expand...
Click to collapse
I'm trying to mount the efs to create generic efs.tnx for the reply
EDIT: Is this the proper way of mounting or formatting efs?
Can I used this command in general?
adb shell
mke2fs -T ext4 /dev/block/mmcblk0p11
mkdir /efs
mount -w -t ext4 /dev/block/mmcblk0p11 /efs
Click to expand...
Click to collapse
cz4r3n said:
I'm trying to mount the efs to create generic efs.tnx for the reply
EDIT: Is this the proper way of mounting or formatting efs?
Can I used this command in general?
Click to expand...
Click to collapse
I think it could work. Otherwise try
Code:
mount -o rw,remount -t ext4 /dev/block/mmcblk0p11 /efs
tys0n said:
I think it could work. Otherwise try
Code:
mount -o rw,remount -t ext4 /dev/block/mmcblk0p11 /efs
Click to expand...
Click to collapse
I tried and here is the log:
D:\adbsdk\sdk\platform-tools>adb shell
~ # ←[6nmke2fs -T ext4 /dev/block/mmcblk0p11
mke2fs -T ext4 /dev/block/mmcblk0p11
mke2fs 1.41.11 (14-Mar-2010)
/dev/block/mmcblk0p11 is apparently in use by the
stem here!
~ # ←[6nmkdir /efs
mkdir /efs
mkdir: can't create directory '/efs': File exists
Click to expand...
Click to collapse
cz4r3n said:
I tried and here is the log:
Click to expand...
Click to collapse
Ok. Only thing I can think of is to do it from recovery and try to unmount it first.
tys0n said:
Ok. Only thing I can think of is to do it from recovery and try to unmount it first.
Click to expand...
Click to collapse
I'm doing it in recovery mode.Im using Team Win Recovery Project v2.6.0.0.
here is the log after unmounting efs from recovery:
D:\adbsdk\sdk\platform-tools>adb shell
~ # ←[6nmke2fs -T ext4 /dev/block/mmcblk0p11
mke2fs -T ext4 /dev/block/mmcblk0p11
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1024 inodes, 4096 blocks
204 blocks (4.98%) reserved for the super user
First data block=0
1 block group
32768 blocks per group, 32768 fragments per group
1024 inodes per group
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
~ # ←[6nmkdir /efs
mkdir /efs
mkdir: can't create directory '/efs': File exists
~ # ←[6nmount -w -t ext4 /dev/block/mmcblk0p11 /efs
mount -w -t ext4 /dev/block/mmcblk0p11 /efs
~ # ←[6n
Click to expand...
Click to collapse
cz4r3n said:
I'm doing it in recovery mode.Im using Team Win Recovery Project v2.6.0.0.
here is the log after unmounting efs from recovery:
Click to expand...
Click to collapse
Yeah, your /efs dir is still in root directory, but it looks like you got it formated and remounted.
double post (deleted)
ah ok, ya I think so, because it shows factory mode in the screen already.I am expecting that the imei will be converted to 004 but it still shows null.
Anyway, tnx for a big hand.Now then, I'll try to use special box to re-write the original imei.tnx tnx...really appreciate it
cz4r3n said:
ah ok, ya I think so, because it shows factory mode in the screen already.I am expecting that the imei will be converted to 004 but it still shows null.
Anyway, tnx for a big hand.Now then, I'll try to use special box to re-write the original imei.tnx tnx...really appreciate it
Click to expand...
Click to collapse
You got any files in your /efs now?
tys0n said:
You got any files in your /efs now?
Click to expand...
Click to collapse
I used Root Explorer to check the folder and my imei is empty.Unfortunately I have no efs backup.
Any recommendation sir?tnx
cz4r3n said:
I used Root Explorer to check the folder and my imei is empty.Unfortunately I have no efs backup.
Any recommendation sir?tnx
Click to expand...
Click to collapse
Any "FactoryApp" folder in /efs? If so, try
Code:
adb shell
su
echo -n ON > /efs/FactoryApp/factorymode
to get out of factory mode. Then reboot.
Use dialpad and enter *#*#0011#, use menu button and choose "back" , menubutton and "back" again. There you should have an option to rebuild/restore NV. Doubt it will bring back IMEI tho :/
tys0n said:
Any "FactoryApp" folder in /efs? If so, try
Code:
adb shell
su
echo -n ON > /efs/FactoryApp/factorymode
to get out of factory mode. Then reboot.
Use dialpad and enter *#*#0011#, use menu button and choose "back" , menubutton and "back" again. There you should have an option to rebuild/restore NV. Doubt it will bring back IMEI tho :/
Click to expand...
Click to collapse
It's not working, I dialed *#*#0011# and pressed menu or home button (am I right?) there is no option in choosing "back".
cz4r3n said:
It's not working, I dialed *#*#0011# and pressed menu or home button (am I right?) there is no option in choosing "back".
Click to expand...
Click to collapse
After *#*#0011# you should get to factoryapp settings. When you push menubutton you will get a menu where you can choose back.
Btw, are you on stock rom?
tys0n said:
After *#*#0011# you should get to factoryapp settings. When you push menubutton you will get a menu where you can choose back.
Btw, are you on stock rom?
Click to expand...
Click to collapse
Yes I'm on stock rom.Btw, I used this *#0011# and it prompt me in Service Menu and I used below method also but it's not working:
1. Dial *#0011#
2. press Menu then tap BACK
3. press the Menu again the tap KEY INPUT then enter 1, (wait a few seconds) it auto jumped into service menu.
4. press Menu then tap BACK
Your are now in the SERVICE MODE MAIN MENU
Click to expand...
Click to collapse
Service Menu still blank
cz4r3n said:
Yes I'm on stock rom.Btw, I used this *#0011# and it prompt me in Service Menu and I used below method also but it's not working:
Service Menu still blank
Click to expand...
Click to collapse
Not sure why that is :/ Try to reflash stock in odin.
tys0n said:
Not sure why that is :/ Try to reflash stock in odin.
Click to expand...
Click to collapse
I already did.before I'm on 4.1.2 but i downgraded to 4.1.1 to make sure.but still no luck...
I think because of the absence of nv_data.
cz4r3n said:
I already did.before I'm on 4.1.2 but i downgraded to 4.1.1 to make sure.but still no luck...
Click to expand...
Click to collapse
Ok. I'll send you a pm. Let's see if we can work this out.
This is the place for various bits and pieces of information/facts/wtf collected whilst digging around in our TF701.
Use at your own peril.
UPDATE: I know the staging partition is where to blob (bootloader) goes, but as I found out, that's only half of the story.
It seems like the bootloader takes the contents of staging at boot time and puts them where they belong.
Now if anybody has more details about this, that would be great.
Partitions
Code:
name device mountpoint fs description
/dev/block/platform/sdhci-tegra.3/ADF /dev/block/mmcblk0p7 /ADF ext4 ?
/dev/block/platform/sdhci-tegra.3/APD /dev/block/mmcblk0p6 /APD ext4 ASUS Product Demo
/dev/block/platform/sdhci-tegra.3/APP /dev/block/mmcblk0p4 /system ext4 Android OS
/dev/block/platform/sdhci-tegra.3/CAC /dev/block/mmcblk0p5 /cache ext4 recovery logs
/dev/block/platform/sdhci-tegra.3/CRA /dev/block/mmcblk0p11 ?
/dev/block/platform/sdhci-tegra.3/DTB /dev/block/mmcblk0p2 ?
/dev/block/platform/sdhci-tegra.3/EKS /dev/block/mmcblk0p13 NVEKSP
/dev/block/platform/sdhci-tegra.3/LNX /dev/block/mmcblk0p3 Linux kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/MDA /dev/block/mmcblk0p12 ?
/dev/block/platform/sdhci-tegra.3/MSC /dev/block/mmcblk0p8 empty (misc, bootloader etc.)
/dev/block/platform/sdhci-tegra.3/PER /dev/block/mmcblk0p10 /persist ext4 config/calibration data
/dev/block/platform/sdhci-tegra.3/SOS /dev/block/mmcblk0p1 Recovery kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/UDA /dev/block/mmcblk0p14 /data ext4 Android user data
/dev/block/platform/sdhci-tegra.3/USP /dev/block/mmcblk0p9 Staging (blob)
recovery.fstab
Code:
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/devices/platform/sdhci-tegra.2/mmc_host/mmc1 /storage/sdcard1 vfat default voldmanaged=sdcard:auto
/devices/platform/tegra-ehci.0 /mnt/usbdrive vfat default voldmanaged=usbdrive:auto
Blob
Code:
name size description status
[U]10.14.1.47:[/U] [ATTACH]2435244._xfImport[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (original) [ATTACH]2435246._xfImport[/ATTACH]
blob.BC1 8,192 Bytes ? (original) [ATTACH]2435245._xfImport[/ATTACH]
blob.EBT 1,396,736 Bytes Bootloader (original) [ATTACH]2435247._xfImport[/ATTACH]
blob.PT 2,202 Bytes Partition Table (original) [ATTACH]2435248._xfImport[/ATTACH]
[U]10.26.1.7:[/U] [ATTACH]2435238._xfImport[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (unchanged) [ATTACH]2435241._xfImport[/ATTACH]
blob.BC1 8,192 Bytes ? (changed) [ATTACH]2435240._xfImport[/ATTACH]
blob.EBT 1,421,312 Bytes Bootloader (changed) [ATTACH]2435242._xfImport[/ATTACH]
Unbrick
How to unbrick a TF701 that still has fastboot running (possibly partially redundant):
WARNING: Any damage caused by following these instructions...
Yeah, right... Nevermind that... If your fastboot works, this will save your tablet
Required tools: I assume you have them already
Required files:
UL-K00C-xx-10.14.1.47-user.zip (on micro SD card in TF701)
10.14.1.47 blob and boot.img (unpacked from UL-K00C-xx-10.14.1.47-user.zip)
drgravy's recovery.img
Code:
fastboot erase boot
fastboot erase staging
fastboot format system
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery.img
fastboot reboot-bootloader
check the version displayed. Is it 10.14.1.47? if not, hard reset to bootloader ([vol-] + [power])
boot recovery kernel (RCK)
install zip
choose zip from sdcard
UL-K00C-xx-10.14.1.47-user.zip
Yes
wait and pray to odin
+++ go back +++
reboot system now
Yes - Disable recovery flash (doesn't actually matter)
Yes - Root device (/system/xbin/su) (just kidding, this doesn't work)
Please consider clicking thanks
Sources:
Lots of own work
http://forum.xda-developers.com/showpost.php?p=47767352&postcount=71
https://github.com/AndroidRoot/BlobTools
im trying to find pretty much the same info
mmcblk0p? for boot and external_sd
This helped alot thanks!
nevermind find both
LNX = boot
/dev/block/mmcblk1p1 is external_sd
schmeggy929 said:
im trying to find pretty much the same info
mmcblk0p? for boot and external_sd
This helped alot thanks!
nevermind find both
LNX = boot
/dev/block/mmcblk1p1 is external_sd
Click to expand...
Click to collapse
things that will appear here tomorrow:
by name symlinks
recovery fstab info
unpacked blob contents
more detailed bootloader related stuff
anything fun I'll find on the way
for the next 12 hours that's it...
lpdunwell said:
This is the place for various bits and pieces of information/facts/wtf collected whilst digging around in our TF701.
Use at your own peril.
UPDATE: I know the staging partition is where to blob (bootloader) goes, but as I found out, that's only half of the story.
It seems like the bootloader takes the contents of staging at boot time and puts them where they belong.
Now if anybody has more details about this, that would be great.
Partitions
Code:
name device mountpoint fs description
/dev/block/platform/sdhci-tegra.3/ADF /dev/block/mmcblk0p7 /ADF ext4 ?
/dev/block/platform/sdhci-tegra.3/APD /dev/block/mmcblk0p6 /APD ext4 ASUS Product Demo
/dev/block/platform/sdhci-tegra.3/APP /dev/block/mmcblk0p4 /system ext4 Android OS
/dev/block/platform/sdhci-tegra.3/CAC /dev/block/mmcblk0p5 /cache ext4 recovery logs
/dev/block/platform/sdhci-tegra.3/CRA /dev/block/mmcblk0p11 ?
/dev/block/platform/sdhci-tegra.3/DTB /dev/block/mmcblk0p2 ?
/dev/block/platform/sdhci-tegra.3/EKS /dev/block/mmcblk0p13 NVEKSP
/dev/block/platform/sdhci-tegra.3/LNX /dev/block/mmcblk0p3 Linux kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/MDA /dev/block/mmcblk0p12 ?
/dev/block/platform/sdhci-tegra.3/MSC /dev/block/mmcblk0p8 empty (misc, bootloader etc.)
/dev/block/platform/sdhci-tegra.3/PER /dev/block/mmcblk0p10 /persist ext4 config/calibration data
/dev/block/platform/sdhci-tegra.3/SOS /dev/block/mmcblk0p1 Recovery kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/UDA /dev/block/mmcblk0p14 /data ext4 Android user data
/dev/block/platform/sdhci-tegra.3/USP /dev/block/mmcblk0p9 Staging (blob)
recovery.fstab
Code:
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/devices/platform/sdhci-tegra.2/mmc_host/mmc1 /storage/sdcard1 vfat default voldmanaged=sdcard:auto
/devices/platform/tegra-ehci.0 /mnt/usbdrive vfat default voldmanaged=usbdrive:auto
Blob
Code:
name size description status
[U]10.14.1.47:[/U] [ATTACH]2435244[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (original) [ATTACH]2435246[/ATTACH]
blob.BC1 8,192 Bytes ? (original) [ATTACH]2435245[/ATTACH]
blob.EBT 1,396,736 Bytes Bootloader (original) [ATTACH]2435247[/ATTACH]
blob.PT 2,202 Bytes Partition Table (original) [ATTACH]2435248[/ATTACH]
[U]10.26.1.7:[/U] [ATTACH]2435238[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (unchanged) [ATTACH]2435241[/ATTACH]
blob.BC1 8,192 Bytes ? (changed) [ATTACH]2435240[/ATTACH]
blob.EBT 1,421,312 Bytes Bootloader (changed) [ATTACH]2435242[/ATTACH]
Unbrick
How to unbrick a TF701 that still has fastboot running (possibly partially redundant):
WARNING: Any damage caused by following these instructions...
Yeah, right... Nevermind that... If your fastboot works, this will save your tablet
Required tools: I assume you have them already
Required files:
UL-K00C-xx-10.14.1.47-user.zip (on micro SD card in TF701)
10.14.1.47 blob and boot.img (unpacked from UL-K00C-xx-10.14.1.47-user.zip)
drgravy's recovery.img
Code:
fastboot erase boot
fastboot erase staging
fastboot format system
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery.img
fastboot reboot-bootloader
check the version displayed. Is it 10.14.1.47? if not, hard reset to bootloader ([vol-] + [power])
boot recovery kernel (RCK)
install zip
choose zip from sdcard
UL-K00C-xx-10.14.1.47-user.zip
Yes
wait and pray to odin
+++ go back +++
reboot system now
Yes - Disable recovery flash (doesn't actually matter)
Yes - Root device (/system/xbin/su) (just kidding, this doesn't work)
Please consider clicking thanks
Sources:
Lots of own work
http://forum.xda-developers.com/showpost.php?p=47767352&postcount=71
https://github.com/AndroidRoot/BlobTools
Click to expand...
Click to collapse
Sorry, how should I extract the recovery.img from the OTA zip file?
I can only find several files: install-recovery.sh recovery-from-boot.p recovery-resource. dat
Or if I can extract it anywhere else?
lpdunwell said:
Code:
[U]10.26.1.7:[/U] [ATTACH]2435238[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (unchanged) [ATTACH]2435241[/ATTACH]
blob.BC1 8,192 Bytes ? (changed) [ATTACH]2435240[/ATTACH]
blob.EBT 1,421,312 Bytes Bootloader (changed) [ATTACH]2435242[/ATTACH]
Click to expand...
Click to collapse
@lpdunwell
Any ideas what BC1 is for? Also there is no SOS file inside the BLOB. I have repacked the BLOB as I wanted to make a bootloader and recovery flash package but not sure how to flash a recovery.
On the TF700 you could just pack it back into the BLOB using the below and it would flash to staging fine. Any ideas?
Code:
blobpack -s blob EBT blob.EBT SOS blob.SOS
I wonder if the same can be done like this?
Code:
blobpack -s blob BCT blob.BCT BC1 blob.BC1 EBT blob.EBT SOS blob.SOS
sbdags said:
@lpdunwell
Any ideas what BC1 is for? Also there is no SOS file inside the BLOB. I have repacked the BLOB as I wanted to make a bootloader and recovery flash package but not sure how to flash a recovery.
On the TF700 you could just pack it back into the BLOB using the below and it would flash to staging fine. Any ideas?
Code:
blobpack -s blob EBT blob.EBT SOS blob.SOS
I wonder if the same can be done like this?
Code:
blobpack -s blob BCT blob.BCT BC1 blob.BC1 EBT blob.EBT SOS blob.SOS
Click to expand...
Click to collapse
TBCH, I'm not sure about the BC1.
The recovery is not part of the blob (anymore?). And the exact way an official update flashes it is probably not the best way to go when flashing manually. My advice for the moment probably is: Keep flashing the bootloader to a minimum, and flash recoveries via fastboot.
lpdunwell said:
TBCH, I'm not sure about the BC1.
The recovery is not part of the blob (anymore?). And the exact way an official update flashes it is probably not the best way to go when flashing manually. My advice for the moment probably is: Keep flashing the bootloader to a minimum, and flash recoveries via fastboot.
Click to expand...
Click to collapse
Yeah I tried a number of ways to get it to flash but it looks like the nvcopy tool that Asus use doesn't work outside the stock recovery.
Search the UL-K00C-WW-10.14.1.47-user.zip file
Hi,
And thank you. But Do you know where I can download the UL-K00C-WW-10.14.1.47-user.zip ?
On ASUS and can find only WW_epaduser_10_14_1_47_UpdateLauncher.zip.
Oups UL-K00C-WW-10.14.1.47-user.zip is in WW_epaduser_10_14_1_47_UpdateLauncher.zip.
Question
Hi
A question : Is it possible to use the same procedure with UL-K00C-WW-10.26.1.7-user.zip or UL-K00C-WW-10.26.1.18-user.zip ?
Best regards
Bumping this as it should be stickied
Xstof said:
Hi,
And thank you. But Do you know where I can download the UL-K00C-WW-10.14.1.47-user.zip ?
On ASUS and can find only WW_epaduser_10_14_1_47_UpdateLauncher.zip.
Oups UL-K00C-WW-10.14.1.47-user.zip is in WW_epaduser_10_14_1_47_UpdateLauncher.zip.
Click to expand...
Click to collapse
Did you ever find out where to get this file? I've been looking everywhere and I fear my device is hosed without it. HELP!
SgtMac02 said:
Did you ever find out where to get this file? I've been looking everywhere and I fear my device is hosed without it. HELP!
Click to expand...
Click to collapse
Google "Asus support downloads", click on the first link....
lpdunwell said:
Code:
fastboot erase boot
fastboot erase staging
fastboot format system
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery.img
fastboot reboot-bootloader
Click to expand...
Click to collapse
Ok, so I'm trying to get through this and having some trouble...
I've been having to go back and forth on a few things and I fear I've managed to hose thing up pretty good. But at this point, I have the files you state, and in following these instructions, was able to successfully erase the partitions mentioned, then when I tried to flash the first time, I actually screwed up and didn't have the blob file I needed, so now I go back, and obviously I can't re-erase the other files, but formatting system still works, so I know I'm getting good communication with the device. Then trying to flash the blob to staging, I get:
sending 'staging' (1379 KB)...
FAILED (command write failed (No such device or address))
Any thoughts or suggestions would be greatly appreciated.
Am I completely bricked?
I'm stuck in a boot loop with Asus / Unlocked appearing and unable to get to recovery. I've tried connecting with win 8.1 via usb but adb does not see devices. i assume running fastboot is the same situation. I can see the device listed APX and understand that Nvflash can help with that but there is no nvflash for Tegra 4.
I'm not sure how it got to this state - could be me or device. it is new and i considered returning save for the Device is Unlocked message
Ironically, this is my second Tf701t as the first cracked the screen. Considering taking motherboard out of old and putting in new (or visa vera) but I'm really bad with hardware.
Do I really have 2 broken devices I'll try anything.
Thanks for any (emotional) support ...
sonicthoughts said:
I'm stuck in a boot loop with Asus / Unlocked appearing and unable to get to recovery. I've tried connecting with win 8.1 via usb but adb does not see devices. i assume running fastboot is the same situation. I can see the device listed APX and understand that Nvflash can help with that but there is no nvflash for Tegra 4.
I'm not sure how it got to this state - could be me or device. it is new and i considered returning save for the Device is Unlocked message
Ironically, this is my second Tf701t as the first cracked the screen. Considering taking motherboard out of old and putting in new (or visa vera) but I'm really bad with hardware.
Do I really have 2 broken devices I'll try anything.
Thanks for any (emotional) support ...
Click to expand...
Click to collapse
This happened in my TF300T, yes is a hard brick.
Nvflash only works if you did work before.
Here is a guide to ifixit a TF700 perhaps help you. :good:
Would it not make more sense to swap the screens over?
Sent from my HTC Desire 610 using XDA Free mobile app
lpdunwell said:
This is the place for various bits and pieces of information/facts/wtf collected whilst digging around in our TF701.
Use at your own peril.
UPDATE: I know the staging partition is where to blob (bootloader) goes, but as I found out, that's only half of the story.
It seems like the bootloader takes the contents of staging at boot time and puts them where they belong.
Now if anybody has more details about this, that would be great.
Sources:
Lots of own work
http://forum.xda-developers.com/showpost.php?p=47767352&postcount=71
https://github.com/AndroidRoot/BlobTools
Click to expand...
Click to collapse
Thank you for your analysis! I wonder does the "staging" partition contain temporary updates, and the blob flashed to it will automatically decompress to the correct partitions in the next boot?
In other words, in order to update the bootloader and the recovery system, I could do either:
1.
Code:
fastboot flash staging bootloader
fastboot flash recovery TWRP.img
Or:
Code:
blobpack -s bootloader-TWRP.blob EBT bootloader.EBT SOS TWRP.img
fastboot flash staging bootloader-TWRP.blob
Are they equivalent?
Stuck with the old bootloader
[CODE said:
fastboot erase boot
fastboot erase staging
fastboot format system
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery.img
fastboot reboot-bootloader[/CODE]
check the version displayed. Is it 10.14.1.47? if not, hard reset to bootloader ([vol-] + [power])
boot recovery kernel (RCK)
install zip
choose zip from sdcard
UL-K00C-xx-10.14.1.47-user.zip
Yes
wait and pray to odin
+++ go back +++
reboot system now
Yes - Disable recovery flash (doesn't actually matter)
Yes - Root device (/system/xbin/su) (just kidding, this doesn't work)
Please consider clicking thanks
Sources:
Lots of own work
http://forum.xda-developers.com/showpost.php?p=47767352&postcount=71
https://github.com/AndroidRoot/BlobTools
Click to expand...
Click to collapse
I am stuck, for some reason after following these steps when the device reboots it is still with the old recovery and bootloader. Can anybody help please?
xabier87 said:
I am stuck, for some reason after following these steps when the device reboots it is still with the old recovery and bootloader. Can anybody help please?
Click to expand...
Click to collapse
What are you trying to do? Which BL and recovery do you currently have?
Flashable zips for the last bootloaders are here: http://forum.xda-developers.com/showpost.php?p=61045480&postcount=2
berndblb said:
What are you trying to do? Which BL and recovery do you currently have?
Flashable zips for the last bootloaders are here: http://forum.xda-developers.com/showpost.php?p=61045480&postcount=2
Click to expand...
Click to collapse
Thanks for the info! I might try with these zips and bootloaders. I am trying to reset my tablet or make it work. Had cm-12.1-20160711-NIGHTLY-tf701t.zip on it with TWRP recovery and US_epad-10.26.1.18-20131217 bootloader but it recently stoppped working. I do have access to the bootloader and recovery but after following the fastboot instructions and rebooting nothing is changed on the tablet.
Q&A for [HACK]Partition Table Tool for LG L90(really more data)
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [HACK]Partition Table Tool for LG L90(really more data). If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
Hello, I've tried your script but now I'm not able ro mount cache or flash the stock rom. If you could help me this would be great!
http://forum.xda-developers.com/lg-l90/help/flash-stock-rom-t2953340
Kind regards
I think that this is not a fault repartitioning but rather drivers. Try select "CS_EMERGENCY" for PhoneMode.
If you can not to mount cache format try in recovery. If not working try this:
Code:
adb shell
make_ext4fs /dev/block/mmcblk0p33
tune2fs -c 0 -i -1 -C -1 /dev/block/mmcblk0p33
reboot recovery
BigMajster said:
I think that this is not a fault repartitioning but rather drivers. Try select "CS_EMERGENCY" for PhoneMode.
If you can not to mount cache format try in recovery. If not working try this:
Code:
adb shell
make_ext4fs /dev/block/mmcblk0p33
tune2fs -c 0 -i -1 -C -1 /dev/block/mmcblk0p33
reboot recovery
Click to expand...
Click to collapse
Hello, thank you for helping me! But when I boot the phone into Cyanogenmod, your commands doesn't work.
Code:
C:\adb>adb shell
$ make_ext4fs /dev/block/mmcblk0p33
make_ext4fs /dev/block/mmcblk0p33
open: Permission denied
$
Edit.: Oh man, just forgot the su! Now I'm able to mount cache! Thanks a lot! But I still can't flash the stock rom. Any idea?
j8o said:
Hello, thank you for helping me! But when I boot the phone into Cyanogenmod, your commands doesn't work.
Code:
C:\adb>adb shell
$ make_ext4fs /dev/block/mmcblk0p33
make_ext4fs /dev/block/mmcblk0p33
open: Permission denied
$
Edit.: Oh man, just forgot the su! Now I'm able to mount cache! Thanks a lot! But I still can't flash the stock rom. Any idea?
Click to expand...
Click to collapse
Code:
adb shell
su
make_ext4fs /dev/block/mmcblk0p32
make_ext4fs /dev/block/mmcblk0p33
make_ext4fs /dev/block/mmcblk0p34
tune2fs -c 0 -i -1 -C -1 /dev/block/mmcblk0p32
tune2fs -c 0 -i -1 -C -1 /dev/block/mmcblk0p33
tune2fs -c 0 -i -1 -C -1 /dev/block/mmcblk0p34
reboot recovery
BigMajster said:
Code:
adb shell
su
make_ext4fs /dev/block/mmcblk0p32
make_ext4fs /dev/block/mmcblk0p33
make_ext4fs /dev/block/mmcblk0p34
tune2fs -c 0 -i -1 -C -1 /dev/block/mmcblk0p32
tune2fs -c 0 -i -1 -C -1 /dev/block/mmcblk0p33
tune2fs -c 0 -i -1 -C -1 /dev/block/mmcblk0p34
reboot recovery
Click to expand...
Click to collapse
I've run all this commands but it didn't helped.
j8o said:
I've run all this commands but it didn't helped.
Click to expand...
Click to collapse
Code:
adb shell
su
parted -s /dev/block/mmcblk0 print
and upload screenshot
BigMajster said:
Code:
adb shell
su
parted -s /dev/block/mmcblk0 print
and upload screenshot
Click to expand...
Click to collapse
Code:
# parted -s /dev/block/mmcblk0 print
sh: parted: not found
#
You boot system, so how problem have you now?
You boot system, so how problem have you now?
Click to expand...
Click to collapse
I'm not able to flash the stock rom.
Update. I get the phone to read adb serial # but it says offline. I'm having trouble trying to flash a custom recovery into it right now. Its a little more own tho.. I spend some time guessing random passwords. Should I stop that? I probably won't pick it by I might do more damage. Dammit my other one a brick too. Now all I have left that work are this galaxe s3 and an evo 4g with a cracked to hell screen. I can experiment on the l90 and the lg lucid till they work or break. Any help is appreciated..
To the op, you might want to put a disclaimer on this thread. Seems a little chancy to me.
[help] D405n stuck after trying tu use "Partition Table tool for LG L90"
Hi,
First this is my first post on this forum, so I can't post directly on the "Partition Table Tool for LG L90" thread
I use candy5 rom and twrp.
My problem is after I have used the partition tool, I have re-flash candy5 custom rom, and now it's stuck at the rom boot, and I'm unable to enter the recovery. So it seems to be bricked :-/
In adb my devices is detect but offline.
Can someone help me?
Thanks.
grizzzlly said:
Hi,
First this is my first post on this forum, so I can't post directly on the "Partition Table Tool for LG L90" thread
I use candy5 rom and twrp.
My problem is after I have used the partition tool, I have re-flash candy5 custom rom, and now it's stuck at the rom boot, and I'm unable to enter the recovery. So it seems to be bricked :-/
In adb my devices is detect but offline.
Can someone help me?
Thanks.
Click to expand...
Click to collapse
What is size of partition? Gapps installed?
I have choose "maximal" option, gapps not installed
Try to install CM11 maybe Candy takes up too much space
yup, but my real problem now is just I can't enter in the recovery.
Why? You can go to recovery by key combo
exactly, the key combo works but the device reboot before entering the recovery.
If you want to restore it to life using this method http://forum.xda-developers.com/lg-l90/general/guide-flash-stock-kdz-offline-lg-l90-t2803479 but select "CS_EMERGENCY" for PhoneMode.
Unless there is no other option.
thanks, ill try this.
But I think it will not work cause my device don't boot and so is no detected on my computer.:crying:
My story why I need an EFS or a radio image for Zuk Z2 pro ?
I've bricked radio/modem in my ZUK Z2 pro by hidden settings and „Set GSM/UMTS band” to USA band (only choice)
I live in Europe. I am a quite advanced user, I always root every phone.
Android Google play offered me to install an app „hidden settings”. I did.
There was a select radio band option. I clicked it just to check. In old MTK phones in engineering mode there were a list, like this http://www.cellphonemic.com/image/cache/data/B9500-band-500x500.jpg
But in new ZUK Z2 pro with android 6 there was a choice of USA band (only choice).
Something like this
http://attach.en.miui.com/forum/201608/23/031335orzj1vxxar1vymvm.png.thumb.jpg
It affected only the first SIM slot. Now my first SIM cannot connect - cannot send/receive calls and cannot send SMS. Changing to 3G and 2G gives me a no service. Changing to 4G gives me connection but only data works, cannot call, cannot send a SMS.
Many people have this problem after „Set GSM/UMTS band” to USA band (only choice). This is not a ZUK Z2 problem but Android settings problem.
IT'S STUPID that it could be undone. In OLD android there were a list:
"Automatic", "EURO Band", "USA Band", "JAPAN Band", "AUS Band", "AUS2 Band"
Method:
start an adb shell
type:
am start -n com.android.settings/.BandMode
works.
In new android there is only one entry "USA band".
I know people tried many things.
“Factory reset but that didn't help.”
“I did factory reset and nothing, I installed the factory image and either. “
I did for instance:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
Restart. No result.
It's very frustrating that the software will not allow me to reverse what he did.
Problem probably is here:
https://android.googlesource.com/pl....0_r26/src/com/android/settings/BandMode.java
Many people on many forums described this on many different phones and there is no solution.
One guy mentioned:
“Switch the phone to FLIGHT/AIRPLANE MODE (I did this by dragging down the top menu bar on my phone which is running a custom rom)
Press the menu key and SELECT RADIO BAND - you'll see the complete list of country bands - do NOT select a band yet....”
but it does NOT work for zuk z2 pro.
Zuk Z2 pro is no alone. One said: “Tks 4 ur guide !” but another “I try your trick,but not work in my device.”
One guy (Bitdomo's) made a custom rom for “nexus 5x” - instead of querying the baseband for available band modes just displays all six band modes. People were happy. “I flashed your ROM and then Phone Information had Auto in select band using which I switched back to GSM.”
https://img.xda-cdn.com/Lpw6Ao9fHG6...es.hu/151126/ffsafas_www.kepfeltoltes.hu_.png
or “ I resolved the problem by flashing Bidomo's ROM”.
But I don't have Nexus 5, I have Zuk Z2 pro.
So the only solution to change baseband is changing the source code of BandMode.java, compile and flash my own rom in the Zuk Z2 pro ?
Not cool Google.
There is probably also a second option:
“Well guys, if anyone else is having this problem now, there is an easier method. You can just restore your efs backup. Yes it's for root users only, but if you have it, it's as easy as rebooting to twrp and restoring efs then reboot without wiping anything.
Btw I have really no idea why google didn't implement an auto band option...”
But I don't have EFS backup...
some said:
“i just flash radio .img solved.”
I don't have radio.img for Zuk Z2 pro
Probably this setting has changed just a byte in a configuration. Does anybody have any idea where could it be ? Or any idea how to fix this baseband ?
Please help.
PS Fortunately second SIM card in my Zuk Z2 pro works. Strange, heh?
Maybe radio.img exists in every zuk z2 Pro?
Verstuurd vanaf mijn Z2 Pro met Tapatalk
---------- Post added at 01:58 PM ---------- Previous post was at 01:57 PM ----------
Just tried with es file explorer which couldn't find it
Verstuurd vanaf mijn Z2 Pro met Tapatalk
I;m going to try this
https://forum.xda-developers.com/one-e8/help/signal-selecting-usa-band-4636-menu-t3091439
and this
https://forum.xda-developers.com/android/general/lenovo-vibe-shot-z90-7-unlock-radio-t3198395
I will report
Here ya go broseph; this is the NON-HLOS.BIN I just extracted from the ZUI 2.5.335 QPST package for the Z2 Pro. If you're already rooted & have a custom ROM installed, reboot into bootloader and you should just be able to "fastboot -i 0x2b4c flash modem NON-HLOS.BIN" from wherever you extracted the .bin file from the archive, and be back in business. Probably want to use that over trying to swipe one from a different model. Good luck!
https://www.androidfilehost.com/?fid=529152257862723402
Problem SOLVED, but crazy.
As I mentioned I ****ed up my sim1 network when I clicked hidden settings (also can be reach by *#*#4636#*#*) and „Set GSM/UMTS band” to USA band (only choice in ZUK Z2 pro). Then my first sim1 could not call/send sms. Sim2 worked ok.
Even
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
and restart had had no result.
My baseband was:
#> getprop | grep -i baseba
[gsm.version.baseband]: [.2.0.c1.9-00026-M8996FAAAANAZM-1]
[gsm.version.baseband1]: [.2.0.c1.9-00026-M8996FAAAANAZM-1
I downloaded
https://drive.google.com/drive/folders/0B_e7IyAKmSLcTE0wdXcxdDhFb2c?usp=sharing
the same
filename: zuk_z2_baseband_2.0.079.zip
Baseband version: .2.0.c1.9-00026-M8996FAAAANAZM-1
supported Android version: 6.x/7.x
mentioned here https://zukfans.eu/community/threads/zuk-z2-baseband-collection-versions.4565/
There was a file
bytes 81568256 name NON-HLOS.bin
This was for ZUK z2, I have "zuk z2 pro" version but someone said it is the same.
The versions matched I hope.
But before I flashed it I made a backup of my modem by
# ls -l /dev/block/bootdevice/by-name/ | grep modem
lrwxrwxrwx 1 root root 16 Sep 28 1970 modem -> /dev/block/sde11
lrwxrwxrwx 1 root root 15 Sep 28 1970 modemst1 -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 Sep 28 1970 modemst2 -> /dev/block/sdf2
# dd if=/dev/block/sde11 of=/storage/emulated/0/DCIM/Camera/NON-HLOS-my.bin
194560+0 records in
194560+0 records out
99614720 bytes (95.0MB) copied, 1.575881 seconds, 60.3MB/s
and then I copied NON-HLOS-my.bin by android ftp server to my local computer disk. It was REALLY IMPORTANT !
I flashed
adb reboot bootloader
fastboot -i 0x2b4c flash modem non-hlos.bin
fastboot -i 0x2b4c erase modemst1
fastboot -i 0x2b4c erase modemst2
fastboot -i 0x2b4c reboot
(*) non-hlos was from
zuk_z2_baseband_2.0.079.zip
Baseband version: .2.0.c1.9-00026-M8996FAAAANAZM-1
After reboot I had neither cell network nor wifi network !!!
Again erasing:
adb reboot bootloader
fastboot -i 0x2b4c erase modemst1
fastboot -i 0x2b4c erase modemst2
fastboot -i 0x2b4c reboot
The same
No wifi ! no sim 1, no sim2 !!!
**** I said.
So fortunately I had a backup.
So
adb reboot bootloader
fastboot -i 0x2b4c flash modem NON-HLOS-my.bin
fastboot -i 0x2b4c erase modemst1
fastboot -i 0x2b4c erase modemst2
fastboot -i 0x2b4c reboot
My wifi network and sim2 network were back, but not only ! Crazy thing, but my sim1 started working again !
Crazy heh ?
Probably this new NON-HLOS.bin which didn't work wrote something in the configuration and after re-flashed NON-HLOS-my.bin again it was able to went away from this stupid USA band and refreshed.
After this: sim1 and sim2 work again. Both can see GSM/3G, I can call/send sms by both.
SOLVED
same problem here
same problem and I tried your approach withouth luck....
PS: fastboot cannot find modemst1 and modemst2 , however i've createad a backup of the block devices from adbshell....
I've tried writing different version of NON-HLOS without luck ... I've checke also the baseband using the img from frank76 according the post that you linked without luck.
It is a HW .... IMHO.
Let us know if your terminal is still stable.
[email protected] said:
Let us know if your terminal is still stable.
Click to expand...
Click to collapse
Everything is stable. But you must notice that I am back on my own modem/radio code.
All stupid steps forth and back which I did in fact only reset the configuration
PS
Is there a page where people could find a non-hlos.bin for the ZUK z2 pro which is not the same as for the zuk z2 pure.
I can upload my [gsm.version.baseband]: [.2.0.c1.9-00026-M8996FAAAANAZM-1] for zuk z2 pro.
# cat baseband_2.0.079_.2.0.c1.9-00026-M8996FAAAANAZM-1/NON-HLOS.bin | grep c1.9-00026-M8996FAAAANAZM -a | tail -n 1
/local/mnt/workspace/CRMBuilds/MPSS.TH.2.0.c1.9-00026-M8996FAAAANAZM-1_20160605_203214/b/modem_proc/core/securemsm/secpil/chipset/msm8996/src/sec_pil.c/local/mnt/workspace/CRMBuilds/MPSS.TH.2.0.c1.9-00026-M8996FAAAANAZM-1_20160605_203214/b/modem_proc/core/securemsm/secpil/chipset/msm8996/src/sec_pil_auth.c/local/mnt/workspace/CRMBuilds/MPSS.TH.2.0.c1.9-00026-M8996FAAAANAZM-1_20160605_203214/b/modem_proc/core/securemsm/secpil/chipset/msm8996/src/mba/sec_pil_env.c/local/mnt/workspace/CRMBuilds/MPSS.TH.2.0.c1.9-00026-M8996FAAAANAZM-1_20160605_203214/b/modem_proc/core/securemsm/secpil/chipset/msm8996/src/sec_pil_priv.cheap_ptr != NULL osal_create_thread() failed since we reached maximum thread count
Click to expand...
Click to collapse
# cat my-backup/NON-HLOS.bin | grep c1.9-00026-M8996FAAAANAZM -a | tail -n 1
/local/mnt/workspace/CRMBuilds/MPSS.TH.2.0.c1.9-00026-M8996FAAAANAZM-1_20160605_203214/b/modem_proc/core/securemsm/secpil/chipset/msm8996/src/sec_pil.c/local/mnt/workspace/CRMBuilds/MPSS.TH.2.0.c1.9-00026-M8996FAAAANAZM-1_20160605_203214/b/modem_proc/core/securemsm/secpil/chipset/msm8996/src/sec_pil_auth.c/local/mnt/workspace/CRMBuilds/MPSS.TH.2.0.c1.9-00026-M8996FAAAANAZM-1_20160605_203214/b/modem_proc/core/securemsm/secpil/chipset/msm8996/src/mba/sec_pil_env.c/local/mnt/workspace/CRMBuilds/MPSS.TH.2.0.c1.9-00026-M8996FAAAANAZM-1_20160605_203214/b/modem_proc/core/securemsm/secpil/chipset/msm8996/src/sec_pil_priv.cheap_ptr != NULL osal_create_thread() failed since we reached maximum thread count
Click to expand...
Click to collapse
You can guess that it is the same for the zuk z2 and my for zuk z2 PRO version .... but...
look at this... That's why on the same version of baseband but for zuk z2 my both sim and wireless were permanently off-line.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
[email protected] said:
PS: fastboot cannot find modemst1 and modemst2 , however i've createad a backup of the block devices from adbshell....
Click to expand...
Click to collapse
Very strange. Maybe your partition table is f&cked up.
Try this, this is an equivalent
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst2
Ps What
# ls -l /dev/block/bootdevice/by-name/ | grep modem
gives you ?
juyer said:
Very strange. Maybe your partition table is f&cked up.
Try this, this is an equivalent
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst2
Ps What
# ls -l /dev/block/bootdevice/by-name/ | grep modem
gives you ?
Click to expand...
Click to collapse
well, this is the output
Code:
z2:/ # ls -l /dev/block/bootdevice/by-name/ | grep modem
lrwxrwxrwx 1 root root 21 1970-01-01 13:32 modem -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 1970-01-01 13:32 modemst1 -> /dev/block/mmcblk0p37
lrwxrwxrwx 1 root root 21 1970-01-01 13:32 modemst2 -> /dev/block/mmcblk0p38
I' have the backup of all of three modem, modemst1 and modemst2 ...
Now I try to flash them with dd instead with fastboot,
in the first i flash the non-hlos.img from franko76 and in the second and third sould be the same as a "fastboot erase" right ?
Code:
# dd if=non-hlos.img of=/dev/block/bootdevice/by-name/modem
# dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
# dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst2
edit: it does not work
Code:
dd: /dev/block/bootdevice/by-name/modem: Operation not permitted
1+0 records in
0+0 records out
0 bytes transferred in 0.001 secs (0 bytes/sec)
edit of edit: ok , from ADB on recovery I can write ( TWRP)
PS: the baseband should be this one:
Code:
127|z2:/ # getprop gsm.version.baseband
M8996FAAAANAZM-1.70664.3.76387.1
---------- Post added at 04:07 PM ---------- Previous post was at 03:33 PM ----------
[email protected] said:
well, this is the output
Code:
z2:/ # ls -l /dev/block/bootdevice/by-name/ | grep modem
lrwxrwxrwx 1 root root 21 1970-01-01 13:32 modem -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 1970-01-01 13:32 modemst1 -> /dev/block/mmcblk0p37
lrwxrwxrwx 1 root root 21 1970-01-01 13:32 modemst2 -> /dev/block/mmcblk0p38
I' have the backup of all of three modem, modemst1 and modemst2 ...
Now I try to flash them with dd instead with fastboot,
in the first i flash the non-hlos.img from franko76 and in the second and third sould be the same as a "fastboot erase" right ?
Code:
# dd if=non-hlos.img of=/dev/block/bootdevice/by-name/modem
# dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
# dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst2
edit: it does not work
Code:
dd: /dev/block/bootdevice/by-name/modem: Operation not permitted
1+0 records in
0+0 records out
0 bytes transferred in 0.001 secs (0 bytes/sec)
edit of edit: ok , from ADB on recovery I can write ( TWRP)
PS: the baseband should be this one:
Code:
127|z2:/ # getprop gsm.version.baseband
M8996FAAAANAZM-1.70664.3.76387.1
Click to expand...
Click to collapse
OK: no luck....
mobile not working
Then I resumed my backup file as you did
Code:
/sdcard/Download # cd bck/
/sdcard/Download/bck # ls
modem modemst1 modemst2
/sdcard/Download/bck #
/sdcard/Download/bck #
/sdcard/Download/bck #
/sdcard/Download/bck #
/sdcard/Download/bck # dd if=modem of=/dev/block/bootdevice/by-name/modem
194560+0 records in
194560+0 records out
99614720 bytes (95.0MB) copied, 8.435222 seconds, 11.3MB/s
/sdcard/Download/bck # dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst1
dd: writing '/dev/block/bootdevice/by-name/modemst1': No space left on device
4097+0 records in
4096+0 records out
2097152 bytes (2.0MB) copied, 0.250398 seconds, 8.0MB/s
/sdcard/Download/bck # dd if=/dev/zero of=/dev/block/bootdevice/by-name/modemst2
dd: writing '/dev/block/bootdevice/by-name/modemst2': No space left on device
4097+0 records in
4096+0 records out
2097152 bytes (2.0MB) copied, 0.253253 seconds, 7.9MB/s
rebooted and nothing at all ...
Same synthoms, SIM can be unlocked and it recognized the operator but no network signal.
I've tried also to enter in the op menu using *#*#4636#*#* but I cannot change the baseband and all the stats are empty.
Fckng fckd ZUK.
Ok, lets wait that the repair center is filled by repair request in order to highlight the "ZUK radio-GATE" , for me it's matter of time looking at all the forums that are full of people claiming the same problem.
So are you saying that the "NON-HLOS.BIN" file taken directly from the ZUI 2.5 QPST release for the ZUK Z2 Pro that I uploaded for you is the wrong one? Is there a partition that I need to dump from my phone directly for you instead?
Terminator.J said:
So are you saying that the "NON-HLOS.BIN" file taken directly from the ZUI 2.5 QPST release for the ZUK Z2 Pro that I uploaded for you is the wrong one? Is there a partition that I need to dump from my phone directly for you instead?
Click to expand...
Click to collapse
I have NOT tried yours. I was afraid, it was new version and I have an old in my.
I was afraid that the new radio will be incompatible with my old android.
The Incompatible version - it was the same version from a page but version was the same but compatibility was NOT for pro version.
juyer said:
I have NOT tried yours. I was afraid, it was new version and I have an old in my.
I was afraid that the new radio will be incompatible with my old android.
The Incompatible version - it was the same version from a page but version was the same but compatibility was NOT for pro version.
Click to expand...
Click to collapse
Which version are you running? I can pull the Android 6 version from the factory ZUI 2.3 archive (or even the 1.9 one) for you instead if you like...
Terminator.J said:
Which version are you running? I can pull the Android 6 version from the factory ZUI 2.3 archive (or even the 1.9 one) for you instead if you like...
Click to expand...
Click to collapse
[gsm.version.baseband]: [.2.0.c1.9-00026-M8996FAAAANAZM-1]