I've been looking everywhere for an official Huawei ROM for the Mediapad M2-802L for the last couple of days, but had no luck until I went on the Huawei Taiwan site (I was trying all their international support sites one by one). Huawei seems to have pulled the 802L ROMs from everywhere except the Huawei Taiwan support site.
This site seems to be the only one hosting an 802L ROM as of this writing (2215hrs EDT 2016-08-24). I've just flashed this ROM on my (US English) phone and it flashed fine, rebooted and came back up with all my apps and data.
The ROM version is B003, and the full filename is: M2-802L_V100R001C209B003CUSTC209D002_Android_5.1.1_EMUI_3.1.rar (the link can be a bit slow at first, but it does eventually download).
Note that if you've got a custom recovery and/or have rooted your M2-802L, you'll need to reflash the stock RECOVERY.IMG and BOOT.IMG and remove the rooting before you can flash this ROM (you don't need to relock your bootloader). You can use the Huawei Update Extractor found in this thread to get the official RECOVERY.IMG and BOOT.IMG from this ROM, and flash them in fastboot mode before you do the actual update (the following steps are NOT NECESSARY if you did not install a custom recovery and/or root your phone):
Remove the rooting from your phone using the method recommended by your root app.
Enter fastboot mode by either using ADB ("adb reboot bootloader") or by first shutting down the phone and then powering it up while holding down the VOLDN key.
Connect the phone by USB to your computer and then fire up ADB to issue fastboot commands.
Flash the official recovery image (which you extracted from the official ROM using the Huawei Update Extractor):
Code:
fastboot flash recovery <PATH/TO/YOUR/RECOVERY.img>
Flash the official Boot image (which you extracted from the official ROM using the Huawei Update Extractor):
Code:
fastboot flash boot <PATH/TO/YOUR/BOOT.img>
Reboot your phone a couple of times to make sure that the flash of the original recovery and boot image flash have taken. You can reboot when in fastboot mode by either issuing the command "fastboot reboot" in your ADB terminal, or just holding down your power button for a few seconds until it reboots.
Now you can flash the ROM from the downloaded file, as follows:
Extract the contents of the rar archive from the downloaded package. There will be a folder called "dload" inside a folder called "sd".
Copy this "dload" folder to your SD card (you can copy it to either the internal or the external SD, it doesn't matter).
Go to your phone's "Settings". There, navigate to "Updater"->"Menu"->"Local Update", select the displayed option, and allow it to install. Your phone will boot into the original OEM recovery and install the ROM, after which it should (hopefully) boot into the new ROM.
I just tried this ROM on my US English phone and it works fine; it even downloads and installs the 256MB B003-B005 official update.
Some background on why I was looking so hard for this ROM: I had a screwed B005 ROM because of a faulty interaction between TWRP and SuperSU, and had to recover from that by flashing the SYSTEM.img and DATA.IMG from the M2-801L ROM. Although the device worked just fine, making calls, receiving texts/MMS and everything, my device version showed "HUAWEI M2-801L" instead of "HUAWEI M2-802L" (obviously) because I hadn't saved my original build.prop and phone.prop files (I could have replaced the 801L build.prop and phone.prop with the 802L ones after I had flashed the 801L firmware). Considering that a new official OTA update for Android 6 is rumored to be arriving in September, I wanted to make sure that my phone was set up in the proper way with no inconsistencies, so that I could install the new update when it arrives. I even wrote to Huawei support but they weren't helpful. Ah well, who needs em
I'm running this ROM (after bricking my device and trying just about every recovery method possible). I had 2 oddities with it. The first one may have just been coincidence but it wouldn't keep the Play store open for more than a few seconds. I cleared cache, data and everything else but in the end had to sideload the Play store APK to get it to work. I think Play Services must have updated before the Store so then the store was incompatible and crashed.
Secondly, my smart cover no longer works. If I open the cover the screen lights for a few seconds but doesn't respond to touch. Then if Ihit the power button, it takes about 8 seconds but then still isn't responsive. Repeat and then it comes to life. Take it out of the case, no problem. Disable smart cover in settings and we're good. As far as I can tell, there is a specific smart cover available in Asia for this device but it is no good with a generic one. The original ROM worked fine with my cover.
I have contacted Huawei support asking for a link to the Aussie ROM but a week and several back and forth emails later, they haven't told me anything. Apparently they have escalated my call and a senior will call me back.
wmoore said:
I'm running this ROM (after bricking my device and trying just about every recovery method possible). I had 2 oddities with it. The first one may have just been coincidence but it wouldn't keep the Play store open for more than a few seconds. I cleared cache, data and everything else but in the end had to sideload the Play store APK to get it to work. I think Play Services must have updated before the Store so then the store was incompatible and crashed.
Secondly, my smart cover no longer works. If I open the cover the screen lights for a few seconds but doesn't respond to touch. Then if Ihit the power button, it takes about 8 seconds but then still isn't responsive. Repeat and then it comes to life. Take it out of the case, no problem. Disable smart cover in settings and we're good. As far as I can tell, there is a specific smart cover available in Asia for this device but it is no good with a generic one. The original ROM worked fine with my cover.
I have contacted Huawei support asking for a link to the Aussie ROM but a week and several back and forth emails later, they haven't told me anything. Apparently they have escalated my call and a senior will call me back.
Click to expand...
Click to collapse
Hm. I've been using this ROM for a while now and haven't noticed any such issues (I'm using a generic smart cover I bought off the US Amazon site). How exactly did you flash this ROM? What were the exact steps you used? I ask because I think what may be happening is that you may possibly have bits and pieces left over from your original aussie ROM that is experiencing some culture shock with the Taiwanese bits of this ROM
At any rate, what I would recommend to try to fix your issues is to reflash the full ROM again, with the original Huawei BOOT and RECOVERY partitions of course (it'll still keep all your data and apps, don't worry, I've done this a few times now in my R&D):
If you're rooted, remember to unroot first
If you have a custom recovery like TWRP then remember to flash the stock recovery and boot partitions back first. Let me know if you need to know how to get these partitions or how to flash them.
Stick the "dload" directory of this ROM directory back on to your SD card, access the Updater, choose the "Local Update" option and update from there. It should reboot into the Huawei recovery and flash the full ROM, which (I think) is all partition images contained in the UPDATE.APP for the ROM).
Let the ROM reboot. It should now say that its "upgrading" your apps. After a bit, if you access the updater, you should see a "B003 to B005" OTA update available which is about 256 MB. Select to download and install this update.
See how it behaves after this update is installed.
As a final cleaning step, reboot into the recovery by first shutting it off and then pressing the power button with VOLDN pressed simultaneously. In the recovery menu, select the "Clear cache/Dalvik cache" (don't remember exact wording because I pretty much immediately flash the latest TWRP for this device), let it clean the cache, then reboot and see if your problems go away.
I've been running this ROM in the US on the AT&T network quite troublefree (except for AT&T outages) ever since I first flashed this ROM - all my subsequent troubles are usually caused by my messing around with it trying to learn stuff by poking around where I don't belong :cyclops:
beast.in.black said:
Hm. I've been using this ROM for a while now and haven't noticed any such issues (I'm using a generic smart cover I bought off the US Amazon site). How exactly did you flash this ROM? What were the exact steps you used? I ask because I think what may be happening is that you may possibly have bits and pieces left over from your original aussie ROM that is experiencing some culture shock with the Taiwanese bits of this ROM
At any rate, what I would recommend to try to fix your issues is to reflash the full ROM again, with the original Huawei BOOT and RECOVERY partitions of course (it'll still keep all your data and apps, don't worry, I've done this a few times now in my R&D):
If you're rooted, remember to unroot first
If you have a custom recovery like TWRP then remember to flash the stock recovery and boot partitions back first. Let me know if you need to know how to get these partitions or how to flash them.
Stick the "dload" directory of this ROM directory back on to your SD card, access the Updater, choose the "Local Update" option and update from there. It should reboot into the Huawei recovery and flash the full ROM, which (I think) is all partition images contained in the UPDATE.APP for the ROM).
Let the ROM reboot. It should now say that its "upgrading" your apps. After a bit, if you access the updater, you should see a "B003 to B005" OTA update available which is about 256 MB. Select to download and install this update.
See how it behaves after this update is installed.
As a final cleaning step, reboot into the recovery by first shutting it off and then pressing the power button with VOLDN pressed simultaneously. In the recovery menu, select the "Clear cache/Dalvik cache" (don't remember exact wording because I pretty much immediately flash the latest TWRP for this device), let it clean the cache, then reboot and see if your problems go away.
I've been running this ROM in the US on the AT&T network quite troublefree (except for AT&T outages) ever since I first flashed this ROM - all my subsequent troubles are usually caused by my messing around with it trying to learn stuff by poking around where I don't belong :cyclops:
Click to expand...
Click to collapse
I suspect you're right. As for how did I flash this ..... Truth is there is no way I could recreate the steps. I wrote about it in the "help I've soft-bricked ..." thread. It was more a matter of luck that judgement that I got the tablet recovered.
I'll give this a go though and see what happens. I wasn't aware there was a newer ROM than B003. Mind you, I've been trying to get some information from Huawei for over a week and have finally given up. Huawei says speak to Vodafone, Vodafone says speak to Huawei.
---------- Post added at 03:19 PM ---------- Previous post was at 02:55 PM ----------
wmoore said:
I suspect you're right. As for how did I flash this ..... Truth is there is no way I could recreate the steps. I wrote about it in the "help I've soft-bricked ..." thread. It was more a matter of luck that judgement that I got the tablet recovered.
I'll give this a go though and see what happens. I wasn't aware there was a newer ROM than B003. Mind you, I've been trying to get some information from Huawei for over a week and have finally given up. Huawei says speak to Vodafone, Vodafone says speak to Huawei.
Click to expand...
Click to collapse
When I tried to run the update from SD card, it gets to about 75% and then tells me the update failed. I reboot and come straight back to where I was before.
In my bootloader I have "FRP Lock" which I believe is to do with password / PIN lock. However I cannot remove those as "something" is holding on to them. I removed my company Exchange account and deactivated the Google "find my phone" administrator. But I;m not sure what else is hogging it, or even if this is the actual problem.
wmoore said:
I suspect you're right. As for how did I flash this ..... Truth is there is no way I could recreate the steps. I wrote about it in the "help I've soft-bricked ..." thread. It was more a matter of luck that judgement that I got the tablet recovered.
I'll give this a go though and see what happens.
Click to expand...
Click to collapse
Fair enough. I did see your post there, but there wasn't enough detail for me to go on.
If you're feeling brave, you can try a fastboot erase and manual flash of the SYSTEM partition from the OEM Taiwanese ROM (as I had outlined in the other thread), before you try the full update again (but see below).
I also wonder: to solve what I strongly suspect are "chimera ROM" issues due to an incomplete original flash which initially resurrected your phone, whether perhaps you might need to manually flash one or more of the other partition images present in the Taiwanese ROM's UPDATE.APP (I'm just taking a SWAG here) to allow a subsequent proper update process to work:
Code:
MCUIMAGE.img
CUST.img
USERDATA.img
SENSORHUB.img
TRUSTFIRMWARE.img
Unfortunately, there is practically no information available on what any of these Huawei partition images are for, so it's pretty much "take a guess based on the image name", which may or may not be what one thinks it is, especially given that Huawei is a Chinese company, with all the attendant language issues that can exist in such a scenario.
wmoore said:
I wasn't aware there was a newer ROM than B003.
Click to expand...
Click to collapse
The B003->B005 update is not a full ROM, it's just a 250MB partial update which is only available OTA, as far as I know. The only full ROM (2.5GB) currently out in the wild for the M2-802L seems to be the B003 ROM (or at least, it's the only one I've found in about 3 weeks of frantic searching).
wmoore said:
Mind you, I've been trying to get some information from Huawei for over a week and have finally given up. Huawei says speak to Vodafone, Vodafone says speak to Huawei.
Click to expand...
Click to collapse
Bloody typical. I had sent Huawei more than a few emails asking for the bootloader unlock code, as well as several frantic emails begging for the 802L ROM when I had accidentally messed up my own factory ROM due to the TWRP+SuperSU interop glitch. All I got from them was the written equivalent of "P*$$ off" from Huawei's US support as well as China support, so I said "Eff these guys" and just paid the DC-Unlocker guys 4 euros for the privilege of getting the unlock code, which was fast, painless and efficient. I then figured that there had to be an 802L ROM available somewhere, and I spent about 2 weeks going through all of Huawei's international channel support sites until I found it in a single place: the Taiwan site.
wmoore said:
---------- Post added at 03:19 PM ---------- Previous post was at 02:55 PM ----------
When I tried to run the update from SD card, it gets to about 75% and then tells me the update failed. I reboot and come straight back to where I was before.
In my bootloader I have "FRP Lock" which I believe is to do with password / PIN lock. However I cannot remove those as "something" is holding on to them. I removed my company Exchange account and deactivated the Google "find my phone" administrator. But I;m not sure what else is hogging it, or even if this is the actual problem.
Click to expand...
Click to collapse
Actually, the FRP lock is controlled by the Developer option "Allow OEM Unlock". If you have developer options enabled, it should show up in your settings, under the "System" settings menu (see attached images).
However, even if your FRP is locked it should not prevent you from flashing the official Huawei image. Could you post the recovery log of the failed update? The recovery log of the OEM Huawei recovery is located at
Code:
/splash2/recovery_log
on your internal SD's filesystem, so you can maybe use adb or a file manager on your phone to get it out of the phone to post it here. I don't know if I have a matchstick's chance in Nordic hell to find what the issue is, but I'm willing to take a look...
beast.in.black said:
Fair enough. I did see your post there, but there wasn't enough detail for me to go on.
If you're feeling brave, you can try a fastboot erase and manual flash of the SYSTEM partition from the OEM Taiwanese ROM (as I had outlined in the other thread), before you try the full update again (but see below).
I also wonder: to solve what I strongly suspect are "chimera ROM" issues due to an incomplete original flash which initially resurrected your phone, whether perhaps you might need to manually flash one or more of the other partition images present in the Taiwanese ROM's UPDATE.APP (I'm just taking a SWAG here) to allow a subsequent proper update process to work:
Code:
MCUIMAGE.img
CUST.img
USERDATA.img
SENSORHUB.img
TRUSTFIRMWARE.img
Unfortunately, there is practically no information available on what any of these Huawei partition images are for, so it's pretty much "take a guess based on the image name", which may or may not be what one thinks it is, especially given that Huawei is a Chinese company, with all the attendant language issues that can exist in such a scenario.
The B003->B005 update is not a full ROM, it's just a 250MB partial update which is only available OTA, as far as I know. The only full ROM (2.5GB) currently out in the wild for the M2-802L seems to be the B003 ROM (or at least, it's the only one I've found in about 3 weeks of frantic searching).
Bloody typical. I had sent Huawei more than a few emails asking for the bootloader unlock code, as well as several frantic emails begging for the 802L ROM when I had accidentally messed up my own factory ROM due to the TWRP+SuperSU interop glitch. All I got from them was the written equivalent of "P*$$ off" from Huawei's US support as well as China support, so I said "Eff these guys" and just paid the DC-Unlocker guys 4 euros for the privilege of getting the unlock code, which was fast, painless and efficient. I then figured that there had to be an 802L ROM available somewhere, and I spent about 2 weeks going through all of Huawei's international channel support sites until I found it in a single place: the Taiwan site.
Actually, the FRP lock is controlled by the Developer option "Allow OEM Unlock". If you have developer options enabled, it should show up in your settings, under the "System" settings menu (see attached images).
However, even if your FRP is locked it should not prevent you from flashing the official Huawei image. Could you post the recovery log of the failed update? The recovery log of the OEM Huawei recovery is located at
Code:
/splash2/recovery_log
on your internal SD's filesystem, so you can maybe use adb or a file manager on your phone to get it out of the phone to post it here. I don't know if I have a matchstick's chance in Nordic hell to find what the issue is, but I'm willing to take a look...
Click to expand...
Click to collapse
First problem is I don't have Enable OEM Unlock in dev options.
When I try to flash TWRP, I get
[email protected]:~/Downloads$ sudo fastboot flash recovery twrp-3.0.2-0-mozart.img
target reported max download size of 471859200 bytes
sending 'recovery' (25330 KB)...
OKAY [ 0.590s]
writing 'recovery'...
FAILED (remote: Command not allowed)
finished. total time: 0.590s
Click to expand...
Click to collapse
Bootloader says PHONE Unlocked and FRP Lock but it seems to me that my bootloader is locked, as I cannot do anything at all with it. If I try fastboot oem unlock, I get:
[email protected]:~/Downloads$ sudo fastboot oem unlock
...
FAILED (remote: Necessary to unlock FRP!)
finished. total time: 0.221s
Click to expand...
Click to collapse
I'm running Linux so the DC Unlocker tool won't work. I might have to find a Windows machine to try that.
wmoore said:
First problem is I don't have Enable OEM Unlock in dev options.
When I try to flash TWRP, I get
Bootloader says PHONE Unlocked and FRP Lock but it seems to me that my bootloader is locked, as I cannot do anything at all with it. If I try fastboot oem unlock, I get:
I'm running Linux so the DC Unlocker tool won't work. I might have to find a Windows machine to try that.
Click to expand...
Click to collapse
Hmmm... what is the exact output of
Code:
fastboot oem get-bootinfo
for you? It is possible that your "Phone unlocked" message may be bogus like it was for the original poster of the "softbricked" thread, although I have no explanation for how that situation came to be. And not having the "Enable OEM Unlock" option in your dev options is deeply disturbing and more than a little suspicious...
SAY!!!! Hang on a bit!! I just realized something: Your reply in the softbrick thread (which the original poster created for the 803L) said that you downloaded the ROM which I had linked in this thread....but my ROM is for the 802L, which is the model I have.
Now, here are the specs from the Huawei site for the 802L and 803L:
Code:
M2-802L
GSM:850/900/1800/1900MHz
UMTS:850(B5/B19)/900/1700/1800/1900/2100MHz
LTE -FDD:Band 1/2/3/4/5/7/8/19/26/28;
LTE -TDD:Band 41/40
WLAN:2.4/5GHz
M2-803L
GSM:850/900/1800/1900MHz
UMTS:850/900/1900/2100MHz;TD-SCDMA:Band 34/39;
LTE -FDD:Band 1/3/7;LTE -TDD:Band 38/39/40/41
WLAN:2.4/5GHz
I have a very important question for you: Is your phone an 803L or an 802L?
This is of prime importance because they have different radio hardware (for starters - see the specs above; there might be other hardware differences)!
Due to this different hardware, the contents of the important partitions that contain the low-level kernel drivers and other ancillary information related to configuring and operating them will be totally different for the two different models! That is why I left the OP in that thread to his own devices using his own ROM - because the 802L ROM would be totally unsuitable at a low-level device-driver level for his phone!
Now, if your phone is indeed the 803L, then much becomes clear!
Consider: If you've got a partial flash of the 802L ROM on your 803L, that would likely explain your strange issues with the smart case etc. In fact, I'm surprised that you aren't having more and deeper issues, but likely the "Failed" update in the Huawei recovery is what is actually saving you from catastrophe here: it's actually refusing to flash the low-level partitions that deal with the hardware at the device layer and which would seriously damage your phone and hard-brick it if the flash actually succeeded.
In addition, if your phone is an 803, that would also sort of explain your weird "Phone unlocked but FRP locked" state that no one but you and the OP in the softbrick thread are reporting - one might draw the conclusion that there is some ROM bug (which especially shows up when one is trying to unlock the phone) in the 803L which is causing this behavior.
As an aside, I'm now also wondering if the poor OP in that thread is also an aussie with a Vodaphone-flogged device...
Yeah mine is definitely the m2-802l. And I think your right about the bogus unlocked notification in the bootloader. My plan at the moment is this:
1 Get rid of the FRP lock. I found an article describing how to do it. Basically remove all Google accounts, then wipe / factory reset.
2 Get an unlock code and try unlock bootloader with fastboot and / or dc unlocker on a windows PC.
I'm not at a computer at the moment but I suspect the result of the command you mentioned will be "remote: command not allowed". Most fastboot command give me that. I'll test the theory shortly.
wmoore said:
Yeah mine is definitely the m2-802l. And I think your right about the bogus unlocked notification in the bootloader. My plan at the moment is this:
1 Get rid of the FRP lock. I found an article describing how to do it. Basically remove all Google accounts, then wipe / factory reset.
2 Get an unlock code and try unlock bootloader with fastboot and / or dc unlocker on a windows PC.
I'm not at a computer at the moment but I suspect the result of the command you mentioned will be "remote: command not allowed". Most fastboot command give me that. I'll test the theory shortly.
Click to expand...
Click to collapse
OK. So fastboot oem get-bootinfo tells me my bootloader is unlocked
[email protected]:~/Downloads$ fastboot oem get-bootinfo
...
(bootloader) unlocked
OKAY [ 0.000s]
finished. total time: 0.000s
Click to expand...
Click to collapse
But pretty much anything else "fastboot" tells me command not allowed. I cannot flash recovery or boot, etc.
So I removed ALL accounts from the device, then rebooted to recovery and cleared cache, the wipe / factory reset. On booting back up and not adding an account, I still don't have Enable OEM Unlock in dev options, and still have FRP Lock on the bootloader screen. I tried fastbook oem frp-unlock and it looks like I need some kind of key.
[email protected]:~/Downloads$ fastboot oem frp-unlock
...
FAILED (remote: FRPKEY parse fail)
finished. total time: 0.000s
Click to expand...
Click to collapse
I had a look at dc-unlocker and they want 15 Euro for an FRP unlock so I'll call that plan B.
With no accounts on the device and after a factory reset, I reloaded the ROM from SD card and again it failed at about 70%. So I'm a bit stuck at the moment.
wmoore said:
Yeah mine is definitely the m2-802l. And I think your right about the bogus unlocked notification in the bootloader. My plan at the moment is this:
1 Get rid of the FRP lock. I found an article describing how to do it. Basically remove all Google accounts, then wipe / factory reset.
2 Get an unlock code and try unlock bootloader with fastboot and / or dc unlocker on a windows PC.
I'm not at a computer at the moment but I suspect the result of the command you mentioned will be "remote: command not allowed". Most fastboot command give me that. I'll test the theory shortly.
Click to expand...
Click to collapse
Ah OK. Then likely your failed update is due the weird situation in which your poor bootloader finds itself. Good luck with the wipe/factory reset.
BTW, at some point if you could run another update from the Updater using the "Local Update" option and the full original UPDATE.APP in the dload dir on your SD, and then give me the recovery_log from it, that would be great. Maybe I can learn something from it...and hopefully (faint hope) there may be something in there which may give us a clue as to how/why your phone is in this poor :crying: state.
beast.in.black said:
Ah OK. Then likely your failed update is due the weird situation in which your poor bootloader finds itself. Good luck with the wipe/factory reset.
BTW, at some point if you could run another update from the Updater using the "Local Update" option and the full original UPDATE.APP in the dload dir on your SD, and then give me the recovery_log from it, that would be great. Maybe I can learn something from it...and hopefully (faint hope) there may be something in there which may give us a clue as to how/why your phone is in this poor :crying: state.
Click to expand...
Click to collapse
I tried to get the recovery log but I'm getting permission denied using adb shell and have no access to it via any app. Not having root, or the ability to get it is a PITA to say the least. I'll keep you posted.
wmoore said:
First problem is I don't have Enable OEM Unlock in dev options.
When I try to flash TWRP, I get
Bootloader says PHONE Unlocked and FRP Lock but it seems to me that my bootloader is locked, as I cannot do anything at all with it. If I try fastboot oem unlock, I get:
I'm running Linux so the DC Unlocker tool won't work. I might have to find a Windows machine to try that.
Click to expand...
Click to collapse
Silly me. I got the recovery log by using adb pull
wmoore said:
Silly me. I got the recovery log by using adb pull
Click to expand...
Click to collapse
This log file is sensational!! Damn it wouldn't display properly but basically the end of the log file has FAIL in huge letters!
But actually I can see two things.
1.
[2016-09-11 21:22:46 657] int symlink_dir(const char*, const char*),line=1649: symlink_dir source_dir:/cust/vodafone/au is not exist!
Click to expand...
Click to collapse
So I need a Vodafone specific ROM, and 2:
failed to mount /dev/block/mmcblk1p1 on /sdcard: No such file or directory
Click to expand...
Click to collapse
Looks like the my device has a different set of partitions. As far as I can tell there is no fdisk on the device (a tried to run /sbin/fdisk in adb shell). So back to Vodafone I go.
After having a huge rant at Vodafone (I have 3 devices with them and 2 are coming off contract ) it looks like they might be trying to help now. They are trying to get me the OTA files at least. Interestingly, the latest update they released was B006 in Feb 2016 but even when on stock mine was on B003 and there was never an update available. I've laid it on thick that there must have been an issue with the device from day 1!
wmoore said:
After having a huge rant at Vodafone (I have 3 devices with them and 2 are coming off contract ) it looks like they might be trying to help now. They are trying to get me the OTA files at least. Interestingly, the latest update they released was B006 in Feb 2016 but even when on stock mine was on B003 and there was never an update available. I've laid it on thick that there must have been an issue with the device from day 1!
Click to expand...
Click to collapse
Happy to hear that you've managed to narrow down the issue. Apologies for being offline for the last couple of days; I was ill.
Regarding your log file, the messages related to mmcblk failures are harmless; it looks like the update script is just guessing at where /sdcard may be. Since it then proceeds with the update, it is not actually an issue.
The bigger problem (as you noticed) is this:
Code:
[2016-09-11 21:22:46 657] int main_cust(int),line=1865: the vendor country in this phone is: vodafone/au
[2016-09-11 21:22:46 657] int main_cust(int),line=1866: input status = 1
[2016-09-11 21:22:46 657] int main_cust(int),line=1867: =================Cust Process================
[2016-09-11 21:22:46 657] int main_cust(int),line=1975: Huawei cust,please wait...
[2016-09-11 21:22:46 657] int judge_custombin(),line=1661: data/custom.bin not exsit!
[2016-09-11 21:22:46 657] int custing_by_vendorcountry(),line=1731: linking by vendorcountry ...
[2016-09-11 21:22:46 657] int symlink_dir(const char*, const char*),line=1649: symlink_dir source_dir:/cust/vodafone/au is not exist!
[2016-09-11 21:22:46 658] int link_source(),line=1686: linking data/cust to cust/vendor/country is fail...
[2016-09-11 21:22:46 658] int custing_by_vendorcountry(),line=1736: linking source is fail...
[2016-09-11 21:22:46 658] int main_cust(int),line=1983: [FAC:Radar_focus_on_fac:CUST]custing_by_vendorcountry fail!
Huawei cust fail.
I:finish_recovery and unmount sdcard ret = 0
Are you able to fastboot flash partitions successfully? I was thinking that if you are able to do that, then while you're waiting for a reply from Vodafone, we can try a couple of things:
First thing, you can try to individually flash the CUST.img, CACHE.img and USERDATA.img partitions from the OEM 802L UPDATE.APP in this thread:
Code:
fastboot flash cust /path/to/CUST.img
fastboot flash userdata /path/to/USERDATA.img
fastboot flash cache /path/to/CACHE.img
and then retry the full update
If the above doesn't work, flash an updated CUST.img and DATA.img partition which I'll give you (the ones in the OEM UPDATE.APP are actually just blank partitions), which will set your custom vendor country and /data/custom.bin files to a default international setting instead of locking you to Vodafone. Let me know if the above doesn't work, so I can prepare the new partitions for you.
Another interesting line I saw in the log was:
Code:
modem_has_6085: 6085 not exit,-1
huawei_nv_bin: no 6085 modem!
I wonder if my updates have the same message; if not, then maybe the Vodafone ROM may have been potentially monkeyed with by the Vodafone guys.
beast.in.black said:
Happy to hear that you've managed to narrow down the issue. Apologies for being offline for the last couple of days; I was ill.
Regarding your log file, the messages related to mmcblk failures are harmless; it looks like the update script is just guessing at where /sdcard may be. Since it then proceeds with the update, it is not actually an issue.
The bigger problem (as you noticed) is this:
Code:
[2016-09-11 21:22:46 657] int main_cust(int),line=1865: the vendor country in this phone is: vodafone/au
[2016-09-11 21:22:46 657] int main_cust(int),line=1866: input status = 1
[2016-09-11 21:22:46 657] int main_cust(int),line=1867: =================Cust Process================
[2016-09-11 21:22:46 657] int main_cust(int),line=1975: Huawei cust,please wait...
[2016-09-11 21:22:46 657] int judge_custombin(),line=1661: data/custom.bin not exsit!
[2016-09-11 21:22:46 657] int custing_by_vendorcountry(),line=1731: linking by vendorcountry ...
[2016-09-11 21:22:46 657] int symlink_dir(const char*, const char*),line=1649: symlink_dir source_dir:/cust/vodafone/au is not exist!
[2016-09-11 21:22:46 658] int link_source(),line=1686: linking data/cust to cust/vendor/country is fail...
[2016-09-11 21:22:46 658] int custing_by_vendorcountry(),line=1736: linking source is fail...
[2016-09-11 21:22:46 658] int main_cust(int),line=1983: [FAC:Radar_focus_on_fac:CUST]custing_by_vendorcountry fail!
Huawei cust fail.
I:finish_recovery and unmount sdcard ret = 0
Are you able to fastboot flash partitions successfully? I was thinking that if you are able to do that, then while you're waiting for a reply from Vodafone, we can try a couple of things:
First thing, you can try to individually flash the CUST.img, CACHE.img and USERDATA.img partitions from the OEM 802L UPDATE.APP in this thread:
Code:
fastboot flash cust /path/to/CUST.img
fastboot flash userdata /path/to/USERDATA.img
fastboot flash cache /path/to/CACHE.img
and then retry the full update
If the above doesn't work, flash an updated CUST.img and DATA.img partition which I'll give you (the ones in the OEM UPDATE.APP are actually just blank partitions), which will set your custom vendor country and /data/custom.bin files to a default international setting instead of locking you to Vodafone. Let me know if the above doesn't work, so I can prepare the new partitions for you.
Another interesting line I saw in the log was:
Code:
modem_has_6085: 6085 not exit,-1
huawei_nv_bin: no 6085 modem!
I wonder if my updates have the same message; if not, then maybe the Vodafone ROM may have been potentially monkeyed with by the Vodafone guys.
Click to expand...
Click to collapse
No worries. Hope you're feeling better
The latest from Voda is that they won't give me a ROM but if I take it back in store, they will ONLY charge me $120 for repair (instead of $250). The reason being the "unauthorised" software I installed - even though it is correct for the device and from the manufacturer - has voided the warranty. Of course I've told them to stick it where the sun don't shine
In terms of flashing, I still can't flash anything. Most fastboot commands come back with "remote: command not allowed". Even though the bootloader says it is unlocked. I'm suspicious of 2 things: FRP being locked and Enable OEM Unlock missing from the menu.
DC-Unlocker claims to unlock FRP for 15Euro so I might give that a shot. The cust.img and data.img files you're talking about - would I be able to repack those back into the update.app and flash them that way? Right now that seems to be the only way I can flash anything.
wmoore said:
No worries. Hope you're feeling better
The latest from Voda is that they won't give me a ROM but if I take it back in store, they will ONLY charge me $120 for repair (instead of $250). The reason being the "unauthorised" software I installed - even though it is correct for the device and from the manufacturer - has voided the warranty. Of course I've told them to stick it where the sun don't shine
Click to expand...
Click to collapse
Those blackguards! (wish I could use something stronger, but the XDA forums have a TOS item about strong language)
I would venture to guess that their "repair" is pretty much flash the ROM - I'm sure they have it and are just not handing it out.
The following lines in your log, which are the first ones to have a build number of M2-802LV100R001C113B006 (the other 2011 timestamped log entries with the M2-80XYV100R001C500B021 build number were likely the factory test flashes in China, because the locale is CN) say:
Code:
[2011-01-03 09:26:58 663] int huawei_recovery_main(int, char**),line=1637: Command: "recovery" "UPDATE:DATAIMG"[2011-01-03 09:26:58 663] int huawei_recovery_main(int, char**),line=1642:
[2011-01-03 09:26:58 663] void print_special_property(),line=1472: ro.board.platform = hi3635
[2011-01-03 09:26:58 663] void print_special_property(),line=1472: ro.build.date = Wed Jan 20 12:01:33 CST 2016
[2011-01-03 09:26:58 663] void print_special_property(),line=1472: ro.build.date.utc = 1453262493
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.build.display.id = M2-802LV100R001C113B006
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.build.product = hi3635
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.build.description = MOZART-user 5.1.1 LMY47X eng.huawei.20160120.113848 test-keys
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.build.fingerprint = Huawei/MOZART/hi3635:5.1.1/LMY47X/huawei01201148:user/test-keys
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.confg.hw_systemversion = M2-802LV100R001C113B006_SYSTEM
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.confg.hw_fastbootversion = V100R001C00B000_FASTBOOT
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.confg.hw_recoveryversion = M2-802LV100R001C113B006_RECOVERY
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.name = MOZART
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.board = hi3635
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.brand = Huawei
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.model = HUAWEI
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.device = hi3635
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.locale.region = US
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.locale.language = en
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.CustCVersion = C113
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.CustDVersion = D001
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.runmode = normal
[2011-01-03 09:26:58 664] int huawei_recovery_main(int, char**),line=1647:
[2011-01-03 09:26:58 666] int huawei_engine_enter(),line=173: Enter huawei_engine_enter()...
[2011-01-03 09:26:58 666] int huawei_engine_enter(),line=174: Recovery boot ->cmd: boot-recovery, ->status: , ->recov: recovery
UPDATE:DATAIMG
[2011-01-03 09:26:58 772] int huawei_engine_enter(),line=190:
Mount external sd card to /sdcard success!
[2011-01-03 09:26:58 773] int huawei_sd_usb_update(bootloader_message*),line=404: enter huawei_sd_usb_update()...
[2011-01-03 09:26:58 773] int huawei_sd_usb_update(bootloader_message*),line=477: update_type = 3, is_factory_update=1.
[2011-01-03 09:26:58 774] int sd_update_prefunc(),line=135: push SD_BEGIN_L0
[2011-01-03 09:26:58 774] int sd_update_prefunc(),line=137: push SD_PRE_L1
[2011-01-03 09:26:59 779] int sd_update_prefunc(),line=141: current battery level = 59.
[2011-01-03 09:26:59 779] int sd_update_prefunc(),line=167: pop SD_PRE_L1
[2011-01-03 09:26:59 779] int sd_dataimg_update_func(),line=192: push SD_PROCESS_L1
[2011-01-03 09:26:59 779] recovery_sd_dataimg_update,line=1292: Enter recovery_sd_update()...
[2011-01-03 09:26:59 780] recovery_sd_dataimg_update,line=1297: Mount Ext SD card success...
[2011-01-03 09:26:59 794] dload_app_path_name_get,line=1100: the dload_name is /sdcard/dload/vodafone/au/update_data_vodafone_au.app
.[2011-01-03 09:26:59 805] recovery_sd_dataimg_update,line=1306: package_percent:0.950000, package_seconds:9.
And what's interesting about that is that it says that your ROM build is B006; I haven't seen a B006 out in the wild for the 802L - not on OTA, not on any third-party sites, not on any of the Huawei support sites. What's even more interesting is the line which refers to /sdcard/dload/vodafone/au/update_data_vodafone_au.app. Both these together now make me even more certain that your phone ROM was probably a special Vodafone customization.
Of course, the "B006" may be the ROM version which denotes a carrier-customized ROM and as such it may be that other carrier-sold 802L's may also have this ROM version number... that's just a guess, though.
wmoore said:
In terms of flashing, I still can't flash anything. Most fastboot commands come back with "remote: command not allowed". Even though the bootloader says it is unlocked. I'm suspicious of 2 things: FRP being locked and Enable OEM Unlock missing from the menu.
DC-Unlocker claims to unlock FRP for 15Euro so I might give that a shot.
Click to expand...
Click to collapse
Yes, that may be your only hope at this point (see below). In one of your previous posts you said that your oem-info command said that the phone was unlocked, but I noticed that the time taken by the command was 0 - which is very suspicious indeed, and leads me to believe that this is a bogus response.
BTW, did you try the dc-unlocker Unbrick guide which I had linked to a few posts back?
wmoore said:
The cust.img and data.img files you're talking about - would I be able to repack those back into the update.app and flash them that way? Right now that seems to be the only way I can flash anything.
Click to expand...
Click to collapse
Well...the trouble is, flashing an UPDATE.APP on a phone which already has some settings will first check the existing data partition for the /data/custom.bin file (it's a text file, despite the name) to find out which is the customer vendor being used by the phone. So without being able to rewrite this file to reset the vendor back to a generic vendor (instead of your very specific "vodafone" vendor), even the repacked UPDATE.APP will fail because it will again fail the cust check.
That's why I wanted to know if fastboot flashing worked, because I wanted to create new partition images which would set your data partition to contain this custom.bin set to a generic vendor, and your cust partition to contain this generic vendor settings like on my phone (just in case the vodafone tossers had removed it).
beast.in.black said:
Those blackguards! (wish I could use something stronger, but the XDA forums have a TOS item about strong language)
I would venture to guess that their "repair" is pretty much flash the ROM - I'm sure they have it and are just not handing it out.
The following lines in your log, which are the first ones to have a build number of M2-802LV100R001C113B006 (the other 2011 timestamped log entries with the M2-80XYV100R001C500B021 build number were likely the factory test flashes in China, because the locale is CN) say:
Code:
[2011-01-03 09:26:58 663] int huawei_recovery_main(int, char**),line=1637: Command: "recovery" "UPDATE:DATAIMG"[2011-01-03 09:26:58 663] int huawei_recovery_main(int, char**),line=1642:
[2011-01-03 09:26:58 663] void print_special_property(),line=1472: ro.board.platform = hi3635
[2011-01-03 09:26:58 663] void print_special_property(),line=1472: ro.build.date = Wed Jan 20 12:01:33 CST 2016
[2011-01-03 09:26:58 663] void print_special_property(),line=1472: ro.build.date.utc = 1453262493
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.build.display.id = M2-802LV100R001C113B006
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.build.product = hi3635
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.build.description = MOZART-user 5.1.1 LMY47X eng.huawei.20160120.113848 test-keys
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.build.fingerprint = Huawei/MOZART/hi3635:5.1.1/LMY47X/huawei01201148:user/test-keys
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.confg.hw_systemversion = M2-802LV100R001C113B006_SYSTEM
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.confg.hw_fastbootversion = V100R001C00B000_FASTBOOT
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.confg.hw_recoveryversion = M2-802LV100R001C113B006_RECOVERY
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.name = MOZART
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.board = hi3635
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.brand = Huawei
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.model = HUAWEI
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.device = hi3635
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.locale.region = US
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.locale.language = en
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.CustCVersion = C113
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.product.CustDVersion = D001
[2011-01-03 09:26:58 664] void print_special_property(),line=1472: ro.runmode = normal
[2011-01-03 09:26:58 664] int huawei_recovery_main(int, char**),line=1647:
[2011-01-03 09:26:58 666] int huawei_engine_enter(),line=173: Enter huawei_engine_enter()...
[2011-01-03 09:26:58 666] int huawei_engine_enter(),line=174: Recovery boot ->cmd: boot-recovery, ->status: , ->recov: recovery
UPDATE:DATAIMG
[2011-01-03 09:26:58 772] int huawei_engine_enter(),line=190:
Mount external sd card to /sdcard success!
[2011-01-03 09:26:58 773] int huawei_sd_usb_update(bootloader_message*),line=404: enter huawei_sd_usb_update()...
[2011-01-03 09:26:58 773] int huawei_sd_usb_update(bootloader_message*),line=477: update_type = 3, is_factory_update=1.
[2011-01-03 09:26:58 774] int sd_update_prefunc(),line=135: push SD_BEGIN_L0
[2011-01-03 09:26:58 774] int sd_update_prefunc(),line=137: push SD_PRE_L1
[2011-01-03 09:26:59 779] int sd_update_prefunc(),line=141: current battery level = 59.
[2011-01-03 09:26:59 779] int sd_update_prefunc(),line=167: pop SD_PRE_L1
[2011-01-03 09:26:59 779] int sd_dataimg_update_func(),line=192: push SD_PROCESS_L1
[2011-01-03 09:26:59 779] recovery_sd_dataimg_update,line=1292: Enter recovery_sd_update()...
[2011-01-03 09:26:59 780] recovery_sd_dataimg_update,line=1297: Mount Ext SD card success...
[2011-01-03 09:26:59 794] dload_app_path_name_get,line=1100: the dload_name is /sdcard/dload/vodafone/au/update_data_vodafone_au.app
.[2011-01-03 09:26:59 805] recovery_sd_dataimg_update,line=1306: package_percent:0.950000, package_seconds:9.
And what's interesting about that is that it says that your ROM build is B006; I haven't seen a B006 out in the wild for the 802L - not on OTA, not on any third-party sites, not on any of the Huawei support sites. What's even more interesting is the line which refers to /sdcard/dload/vodafone/au/update_data_vodafone_au.app. Both these together now make me even more certain that your phone ROM was probably a special Vodafone customization.
Of course, the "B006" may be the ROM version which denotes a carrier-customized ROM and as such it may be that other carrier-sold 802L's may also have this ROM version number... that's just a guess, though.
Yes, that may be your only hope at this point (see below). In one of your previous posts you said that your oem-info command said that the phone was unlocked, but I noticed that the time taken by the command was 0 - which is very suspicious indeed, and leads me to believe that this is a bogus response.
BTW, did you try the dc-unlocker Unbrick guide which I had linked to a few posts back?
Well...the trouble is, flashing an UPDATE.APP on a phone which already has some settings will first check the existing data partition for the /data/custom.bin file (it's a text file, despite the name) to find out which is the customer vendor being used by the phone. So without being able to rewrite this file to reset the vendor back to a generic vendor (instead of your very specific "vodafone" vendor), even the repacked UPDATE.APP will fail because it will again fail the cust check.
That's why I wanted to know if fastboot flashing worked, because I wanted to create new partition images which would set your data partition to contain this custom.bin set to a generic vendor, and your cust partition to contain this generic vendor settings like on my phone (just in case the vodafone tossers had removed it).
Click to expand...
Click to collapse
It's making more sense as we go. When first having the convo woth Voda, they sent me this link and asked if this was what I wanted - http://vodafone.intelliresponse.com...n=Huawei+MediaPad+M2+8.0+4G+-+Software+update
It is for B006 though I'm 99% certain my device was showing B003 when I got it and it never told me an update was available. But on the evidence, I guess it must have somehow been B006 but still reporting as B003? I don't know.
I've tried so many things .... I don't think I did try to DC-Unlocker Phoenix thing. Looks scary but I'll give it a look at the weekend. Thanks for sticking with this.
wmoore said:
It's making more sense as we go. When first having the convo woth Voda, they sent me this link and asked if this was what I wanted - http://vodafone.intelliresponse.com...n=Huawei+MediaPad+M2+8.0+4G+-+Software+update
It is for B006 though I'm 99% certain my device was showing B003 when I got it and it never told me an update was available. But on the evidence, I guess it must have somehow been B006 but still reporting as B003? I don't know.
Click to expand...
Click to collapse
If you can get Vodafone to give you the file for that update, GRAB IT AND DON'T LET GO! I saw that page when I was searching for Vodafone Au Huawei updates, but wasn't able to find a download link for it.
The first reference I find to B003 in your log is here (see last line):
Code:
[2016-09-04 06:05:36 331] int huawei_recovery_main(int, char**),line=1637: Command: "recovery" "UPDATE:SD"[2016-09-04 06:05:36 331] int huawei_recovery_main(int, char**),line=1642:
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.board.platform = hi3635
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.build.date = Fri Aug 28 17:16:28 CST 2015
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.build.date.utc = 1440753388
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.build.display.id = M2-802LV100R001C113B006
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.build.product = hi3635
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.build.description = MOZART-user 5.1.1 LMY47X eng.huawei.20150828.170621 test-keys
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.build.fingerprint = Huawei/MOZART/hi3635:5.1.1/LMY47X/huawei08281715:user/test-keys
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.confg.hw_systemversion = M2-802LV100R001C113B006_SYSTEM
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.confg.hw_fastbootversion = V100R001C00B000_FASTBOOT
[2016-09-04 06:05:36 331] void print_special_property(),line=1472: ro.confg.hw_recoveryversion = M2-802LV100R001C209B003_RECOVERY
Going by the date and the version number of ro.confg.hw_systemversion which is still M2-802LV100R001C113B006 I'm assuming that somewhere before this, you actually had a fastboot flash recovery command succeed, using the recovery from the B003 ROM linked in my first post here. However, prior to this flash attempt your version number should have read B006 (subject to certain caveats regarding the contents of the CURVER partition, and what was contained in your original build.prop and a couple of other system files).
Following this series of log entries, the very next series of log entries then contains this:
Code:
[2016-09-07 07:53:33 279] int huawei_recovery_main(int, char**),line=1637: Command: "/sbin/recovery" "--wipe_data_factory_reset" "--locale=en_AU"[2016-09-07 07:53:33 279] int huawei_recovery_main(int, char**),line=1642:
[2016-09-07 07:53:33 279] void print_special_property(),line=1472: ro.board.platform = hi3635
[2016-09-07 07:53:33 279] void print_special_property(),line=1472: ro.build.date = Fri Aug 28 17:16:28 CST 2015
[2016-09-07 07:53:33 279] void print_special_property(),line=1472: ro.build.date.utc = 1440753388
[2016-09-07 07:53:33 279] void print_special_property(),line=1472: ro.build.display.id = M2-802LV100R001C209B003
[2016-09-07 07:53:33 279] void print_special_property(),line=1472: ro.build.product = hi3635
[2016-09-07 07:53:33 279] void print_special_property(),line=1472: ro.build.description = MOZART-user 5.1.1 LMY47X eng.huawei.20150828.170621 test-keys
[2016-09-07 07:53:33 279] void print_special_property(),line=1472: ro.build.fingerprint = Huawei/MOZART/hi3635:5.1.1/LMY47X/huawei08281715:user/test-keys
[2016-09-07 07:53:33 279] void print_special_property(),line=1472: ro.confg.hw_systemversion = M2-802LV100R001C209B003_SYSTEM
[2016-09-07 07:53:33 280] void print_special_property(),line=1472: ro.confg.hw_fastbootversion = V100R001C00B000_FASTBOOT
[2016-09-07 07:53:33 280] void print_special_property(),line=1472: ro.confg.hw_recoveryversion = M2-802LV100R001C209B003_RECOVERY
As you see, now the version number of ro.confg.hw_systemversion has become M2-802LV100R001C209B003 which is the version number of my ROM. So the previous flash succeeded in replacing all your system partitions, but failed in updating the cust info. As did this flash attempt and all subsequent ones.
wmoore said:
I've tried so many things .... I don't think I did try to DC-Unlocker Phoenix thing. Looks scary but I'll give it a look at the weekend.
Click to expand...
Click to collapse
Yeah, I understand. However, the dc-unlocker guys are really helpful, as I can attest since I used their online chat support for an issue I was having. Their help/guides are usually quite thorough, as well. You should try it, and if you run into issues give their support line a holler.
wmoore said:
Thanks for sticking with this.
Click to expand...
Click to collapse
You're most welcome. It irks me when a problem goes unsolved - in fact, I even looked up shipping rates to/from Oz-USA, but for what it would cost for a round trip for the phone, you might as well just get a new device
However, let's keep plugging away at this until we're absolutely out of ideas - hopefully it'll be solved before we reach that point :cyclops:
Well Voda us really trying to keep me happy but they absolutely refusing to release the software. They've now said I can have a brand new device (not a refurb) for $120. I am tempted but I won't go for it. Now that Huawei has released the kernel source I'm hoping that somebody will cook up a custom ROM for us.
---------- Post added at 05:38 PM ---------- Previous post was at 05:29 PM ----------
Actually I am considering the replacement. If nothing else it means I have some resale value in future. It will cost me ~$30-35 for FRP and bootloader unlock codes from dc-unlocker anyway and even then I have no guarantees. Hmm.......
Related
I was flashing my yakjuxw over to yakju, when fastboot started failing to load system.img.
I have tried 4.0.2 and 4.0.1. Every image except for system.img works.
Code:
[[email protected] yakju-itl41f]# fastboot flash system system.img
error: cannot load 'system.img'
And it doesn't work using the zip either;
Code:
[[email protected] yakju-itl41f]# fastboot update *.zip
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
failed to allocate 325426112 bytes
error: update package missing system.img
I am running Archlinux.
Somewhere in the ./flash-all.sh script my ``sdcard'' was wiped, so I've lost my nandroid(s), but I can boot CWM from my PC. Help?
Open the zip file in a explorer-window somewhere and locate the system.img file and then try the first one over again.
None of these files are magic and they are pretty easy to explore to find the components you are looking for.
Are you sure you've unpacked things correctly?
What does the output from "ls -la" run in the the same folder say?
josteink said:
Open the zip file in a explorer-window somewhere and locate the system.img file and then try the first one over again.
None of these files are magic and they are pretty easy to explore to find the components you are looking for.
Are you sure you've unpacked things correctly?
What does the output from "ls -la" run in the the same folder say?
Click to expand...
Click to collapse
I unpacked the zip, so all the images in it are in this folder, but here's the output:
Code:
[[email protected] yakju-itl41f]# ls -la
total 663156
drwxr-x--- 2 david users 4096 Jan 18 20:17 .
drwxr-xr-x 4 david users 4096 Jan 18 20:07 ..
-rw-r----- 1 david users 93 Nov 21 18:20 android-info.txt
-rw-r--r-- 1 david users 4151296 Jan 1 2009 boot.img
-rw-r----- 1 david users 2363392 Nov 24 09:44 bootloader-maguro-primekj10.img
-rwxr-x--- 1 david users 831 Nov 24 09:44 flash-all.sh
-rw-r----- 1 david users 189165717 Nov 24 09:44 image-yakju-itl41f.zip
-rw-r----- 1 david users 12583168 Nov 24 09:44 radio-maguro-i9250xxkk1.img
-rw-r--r-- 1 david users 4491264 Jan 1 2009 recovery.img
-rwxrwxrwx 1 david users 325426112 Jan 1 2009 system.img
-rw------- 1 david users 140856312 Nov 22 11:09 userdata.img
Did you actually ever unlock fast boot? Just guessing here, at this point.
Sent from my Galaxy Nexus using Tapatalk
redownload stock images?
just an update, this is solved. The solution was found in rebooting my pc, which is something I, as a Linux user, seldom do, and my laptop cannot be trusted to boot due to its buggy BIOS.
Sent from my Galaxy Nexus
Korntoff said:
just an update, this is solved. The solution was found in rebooting my pc, which is something I, as a Linux user, seldom do, and my laptop cannot be trusted to boot due to its buggy BIOS.
Sent from my Galaxy Nexus
Click to expand...
Click to collapse
Ridiculously old thread, I realize, so I feel kinda bad bumping it, but it's an early result on Google when searching for this problem, so I'll update a bit.
Rebooting will work, but isn't necessary, and is inconvenient. You just need to kill fastboot, it's hung with another process.
In linux, open up a terminal.
Code:
ps ax|grep fastboot
Note the PID(s)
Code:
kill -9 <PID1> <PID2>...<PIDn>
Another reason for this error is if you have device encryption enabled. In order to restore factory image, you first need to format /data to remove encryption.
I have no idea why this causes the error "cannot load system.img", but it definitely does.
Cerinthus said:
Ridiculously old thread, I realize, so I feel kinda bad bumping it,
In linux, open up a terminal...
Click to expand...
Click to collapse
Thanks for posting this.
In windows, I used task manager to find the ADB process and killed it, and then it worked fine.
groopk said:
Thanks for posting this.
In windows, I used task manager to find the ADB process and killed it, and then it worked fine.
Click to expand...
Click to collapse
To do this without searching thought task manager , just type "adb kill server " and then " adb start server" :thumbup:
Sent from my SCH-I605 using Tapatalk
quite an old thread again, but replying anyway.
The "failed to allocate ***** bytes" message means that it failed on memory of your computer, not on the storage of your phone.
Code:
fastboot.c
...
void *unzip_file(zipfile_t zip, const char *name, unsigned *sz)
{
...
*sz = get_zipentry_size(entry);
datasz = *sz * 1.001;
data = malloc(datasz);
if(data == 0) {
fprintf(stderr, "failed to allocate %d bytes\n", *sz);
return 0;
}
...
If it turns out that your machine has too small memory(unfortunately, which was also my case), you could unzip the file containing img files and flash system, boot and recovery images one by one. It's just the same.
great help
On the verge of flashing lolipop on my beloved n5, I got stuck with that stupid errror.
Thanks for the helpfull post.
downgrade to 4.4.4
just downgrade to 4.4.4 and then flash android 5.... mine worked....
FreakyTux said:
quite an old thread again, but replying anyway.
The "failed to allocate ***** bytes" message means that it failed on memory of your computer, not on the storage of your phone.
Code:
fastboot.c
...
void *unzip_file(zipfile_t zip, const char *name, unsigned *sz)
{
...
*sz = get_zipentry_size(entry);
datasz = *sz * 1.001;
data = malloc(datasz);
if(data == 0) {
fprintf(stderr, "failed to allocate %d bytes\n", *sz);
return 0;
}
...
If it turns out that your machine has too small memory(unfortunately, which was also my case), you could unzip the file containing img files and flash system, boot and recovery images one by one. It's just the same.
Click to expand...
Click to collapse
This was it! Thanks for posting!
Update ADB. That worked for me
same problem
i tried everything above but nothing works ..... can anyone help me out here
Alternate Way that always works..!!
1. Install TWRP recovery.
2. Mount USB Storage
3. Copy the system.img to phone storage
4. Select Install and then Select Install Image
5. Select the system.img file
6. Select partition as system
7. Confirm install
Done..
Korntoff said:
I was flashing my yakjuxw over to yakju, when fastboot started failing to load system.img.
I have tried 4.0.2 and 4.0.1. Every image except for system.img works.
Code:
[[email protected] yakju-itl41f]# fastboot flash system system.img
error: cannot load 'system.img'
And it doesn't work using the zip either;
Code:
[[email protected] yakju-itl41f]# fastboot update *.zip
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
failed to allocate 325426112 bytes
error: update package missing system.img
I am running Archlinux.
Somewhere in the ./flash-all.sh script my ``sdcard'' was wiped, so I've lost my nandroid(s), but I can boot CWM from my PC. Help?
Click to expand...
Click to collapse
rakesh.aggarwal said:
1. Install TWRP recovery.
2. Mount USB Storage
3. Copy the system.img to phone storage
4. Select Install and then Select Install Image
5. Select the system.img file
6. Select partition as system
7. Confirm install
Done..
Click to expand...
Click to collapse
with lots of thanks and much love!! fixed my device yeeyyyy!!!!
Hello,
today as i was accessing my email on Opera Mobile, the SuperSU window popped up by itself and asked me for root acces for a program called "debuggerd.exynosabuse". I dont know what this debuggerd.exynosabuse is and i didnt open any apk before the SU window suddenly popped up..so naturally i denied it root access...then I went into the SuperSU log file and I saw that it kept trying to get root access for two minutes continuously and about 15 tries... also it doesnt have any icon in the apps section of SuperSU. Any ideas what this is about?
Thanks
Look for the app in app drawer named exynos abuse.
Sent from my GT-N7100 using xda app-developers app
Ok. So I m looking for what exactly? I have already mentioned that it is called debuggerd.exynosabuse. it is not the exynos abuse apk, which I used to root my phone and patch the exploit. It is a different app that has no icon in the SU logfile. This debuggerd is always trying to get root access to modify some root files but I have it denied in SU. It tries to get root access 50 times a day or more. What is this program and where did it come from and what should I do with it. Thanks.
Maybe clear data...
Sent from my GT-N7100 using xda app-developers app
You are not alone
http://www.chainfire.eu/articles/126/ExynosAbuse_APK_released_/
may be malware
Try a full wipe including system cache and dalvik and data.
Then flash latest stock rom and root via cfautoroot.
Also backing up anything using any software is not recommended as malware might have infected it.
Sent from my GT-N7100 using xda app-developers app
I just had the same experience for the first time, unfortunately seeing it was a part of ExynosAbuse, I authorized it...
I then saw a lot going on, and in between SuperSU notifications, I saw Adblock Plus notifications too... Maybe related?
As I said try full wipe and flash latest stock rom.
Sent from my GT-N7100 using xda app-developers app
Well, I'd like to know before I wipe, it's not an easy thing to do for me right now, plus if it's something in the app and I reinstall the app after wiping, I'll have the same problem...
Than you for your input Dr Ketan. I see that this is a relatively new problem and its got people wondering/worried, I appreciate that this issue has come to your attention.
Dear UtkarshGupta, Sure anyone can nuke their phone and wipe all and flash new, but thats not what the xda community is about. We are here to share, communicate, support, enhance, develop, and learn.
Understanding the problem would be the first step in to solving it. When we know what is the size of the problem, we would then know how to deal with it appropriately. It might be something simple that can be cleaned easily, no nuke needed.
As for me, I am happy with my 4.1.1 jb. I dont want to flash any new firmware.
By now I have taken several screen shots of it trying to get root access to many files and even it was trying to change values and commands but all were denied ofcourse because I have it blocked in SU. If it would help the devs or anyone else, I can attach the screenshots if need be.
Well, I have some news.
I removed debuggerd from SuperSU authorizations. Later on, I used Chrome and I got all these requests again. This time, I refused (and took screenshots). At the end, Chrome didn't load the webpage. But mostly, I had no internet connection at all!
Then, I remembered that the first time I had the request, it was when using the web browser. And then, I realized it happened the day after I installed Android Adblock Plus.
I uninstalled it, rebooted, and then my connection worked. I'll try to remove debuggerd from the SuperSU blacklist to see if it still happens.
Anyone can correlate?
Hi,
I had the same problems :
- debuggerd.exynosabuse requested SU privileges
- enter in an infinite loop, use a lot of battery power, automatic reboot of the device more than twice a day
So I tried to remove these files. In order to do that you need :
- a rooted device (su installed and working)
- Android Terminal Emulator installed from Googleplay in the device
Launch Android Terminal Emulator
Enter the commands below :
su (accept su privileges, prompt disappears)
mount -o remount,rw /system
cd /system/bin
rm debuggerd
rm debuggerd.exynosabuse
reboot
It works for me. I hope it will work for you.
debuggerd.exynosabuse
From what I can see, the /system/bin/debugger has been replaced with a script that reads:
#!/system/bin/sh
chmod 0400 /dev/exynos-mem
/system/bin/debuggerd.exynosabuse
Then, debuggerd.exynosabuse seems to launch instead of the normal debuggerd. I suppose some applications may call debuggerd by design, which explains why there are some random popups. Here are the "strings" for debuggerd.exynosabuse which appears to be the renamed original (need to verify). This thread then shows that it appears to do the reported actions.. by design? Would be interesting to trace it down a bit more to determine if the carrier/app developer is sending process dumps back to home for analysis which could contain sensitive data.
ELF
p\4
/system/bin/linker
__aeabi_unwind_cpp_pr0
__dso_handle
__INIT_ARRAY__
__FINI_ARRAY__
memset
property_get
atoi
__stack_chk_fail
__stack_chk_guard
__android_log_vprint
open
close
__errno
strcmp
strlen
vsnprintf
__aeabi_unwind_cpp_pr1
snprintf
strcpy
fprintf
__sF
calloc
free
strdup
fputs
strftime
write
strerror
strtoul
_edata
__bss_start
_end
realloc
memmove
read
socket_local_client
socket_local_server
getsockopt
fopen
fgets
fclose
fcntl
poll
accept
usleep
ioctl
dump_tombstone
dump_backtrace_to_file
getpid
__isthreaded
memcmp
sprintf
__libc_init
fchown
chown
stat
mkdir
sigaction
inotify_init
inotify_add_watch
kill
ptrace
opendir
readdir
readdir_r
closedir
fileno
waitpid
bsd_signal
time
system
fflush
localtime_r
unwind_backtrace_ptrace
demangle_symbol_name
get_backtrace_symbols_ptrace
find_symbol_ptrace
free_backtrace_symbols
format_backtrace_line
try_get_word_ptrace
load_ptrace_context
free_ptrace_context
liblog.so
libcutils.so
libc.so
libcorkscrew.so
/proc/%d/cmdline
%F %T
----- pid %d at %s -----
Cmd line: %s
<unknown>
/proc/%d/comm
"%s" sysTid=%d
Could not attach to thread: %s
Could not obtain stack trace for thread.
%s
ptrace detach from %d failed: %s
/proc/%d/task
----- end %d -----
Sending request to dump task %d.
Error dumping backtrace.
Error dumping tombstone.
Tombstone written to: %s
cannot get credentials
timed out reading tid
read failure? %s
invalid crash request of size %d
/proc/%d/task/%d
tid %d does not exist in pid %d. ignoring debug request
/proc/%d/status
Tgid:
Uid:
Gid:
tid %d does not exist. ignoring explicit dump request
ptrace attach failed: %s
debug.db.uid
failed responding to client: %s
ptrace continue failed: %s
dumpstate -k -t -z -d -o /data/log/dumpstate_app_native -m %d
[email protected]%s
process stopped due to unexpected signal %d
********************************************************
* Process %d has been suspended while crashing. To
* attach gdbserver for a gdb connection on port 5039
* and start gdbclient:
* gdbclient app_process :5039 %d
* Wait for gdb to start, then press HOME or VOLUME DOWN key
* to let the process continue crashing.
********************************************************
/sys/class/leds/red/brightness
/sys/class/leds/green/brightness
/sys/class/leds/blue/brightness
/sys/class/leds/red/device/blink
/sys/class/leds/left/cadence
0,0
255
1,0
debuggerd resuming process %d
debuggerd committing suicide to free the zombie!
logd
android:debuggerd
debuggerd: Oct 4 2012 16:24:21
Usage: -b [<tid>]
-b dump backtrace to console, otherwise dump full tombstone file
If tid specified, sends a request to debuggerd to dump that task.
Otherwise, starts the debuggerd server.
out of memory
/dev/input
could not get event, %s
could not get event
SIGILL
SIGABRT
SIGBUS
SIGFPE
SIGSEGV
SIGPIPE
SIGSTKFLT
SIGSTOP
ILL_ILLOPC
ILL_ILLOPN
ILL_ILLADR
ILL_ILLTRP
ILL_PRVOPC
ILL_PRVREG
ILL_COPROC
ILL_BADSTK
BUS_ADRALN
BUS_ADRERR
BUS_OBJERR
FPE_INTDIV
FPE_INTOVF
FPE_FLTDIV
FPE_FLTOVF
FPE_FLTUND
FPE_FLTRES
FPE_FLTINV
FPE_FLTSUB
SEGV_MAPERR
SEGV_ACCERR
UNKNOWN
pid: %d, tid: %d, name: %s >>> %s <<<
pid: %d, tid: %d, name: %s
#%02d %08x %08x %s (%s+%u)
#%02d %08x %08x %s (%s)
%08x %08x %s (%s+%u)
%08x %08x %s (%s)
#%02d %08x %08x %s
%08x %08x %s
backtrace:
%s
stack:
........ ........
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
ro.build.fingerprint
unknown
Build fingerprint: '%s'
cannot get siginfo: %s
signal %d (%s), code %d (%s), fault addr %08x
cannot get siginfo for %d: %s
memory map around fault addr %08x:
%08x-%08x %s
(no map below)
(no map for address)
(no map above)
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
signal %d (%s), code %d (%s), fault addr --------
/data/tombstones
/data/tombstones/tombstone_%02d
failed to open tombstone file '%s': %s
DEBUG
waitpid failed: %s
unexpected waitpid response: n=%d, status=%08x
timed out waiting for tid=%d to die
timed out waiting for tid=%d to stop
%08x
%08lx
%s %s
memory near %.2s:
code around pc:
code around lr:
cannot get registers: %s
r0 %08x r1 %08x r2 %08x r3 %08x
r4 %08x r5 %08x r6 %08x r7 %08x
r8 %08x r9 %08x sl %08x fp %08x
ip %08x sp %08x lr %08x pc %08x cpsr %08x
d%-2d %016llx d%-2d %016llx
scr %08lx
r0r1r2r3r4r5r6r7r8r9slfpipsp
GCC: (GNU) 4.6.x-google 20120106 (prerelease)
GNU
gold 1.10
aeabi
ARM v7
.shstrtab
.interp
.dynsym
.dynstr
.hash
.rel.dyn
.rel.plt
.text
.ARM.extab
.ARM.exidx
.rodata
.preinit_array
.init_array
.fini_array
.ctors
.dynamic
.got
.bss
.comment
.note.gnu.gold-version
.ARM.attributes
be careful 'RM'ing everything
tcharlier said:
Hi,
I had the same problems :
- debuggerd.exynosabuse requested SU privileges
- enter in an infinite loop, use a lot of battery power, automatic reboot of the device more than twice a day
So I tried to remove these files. In order to do that you need :
- a rooted device (su installed and working)
- Android Terminal Emulator installed from Googleplay in the device
Launch Android Terminal Emulator
Enter the commands below :
su (accept su privileges, prompt disappears)
mount -o remount,rw /system
cd /system/bin
rm debuggerd
rm debuggerd.exynosabuse
reboot
It works for me. I hope it will work for you.
Click to expand...
Click to collapse
should you remove 'debuggerd' & 'debuggerd.exynosabuse' they would simply return from the dead.
i believe they are trying to catch and identify a neardeath experience, in this case relating to exynosabuse. this could be the 4.1.2 upgrade and exynosabuse not sitting comfortably together or it may have been intended to work this way - chainfire is the best source for this answer.
debuggerd is called to examine the problem occurrence point on the source code from a crash dump before the main function is carried out. any prog's with dynamic links can automatically connect to debuggerd and generate crash dumps.
i do find it a bit unsettling when root privileges are asked for something that was never installed as an apk and then devours cpu and battery until nothing is left.
more research needs to be done as to what is really going on...
refer to Koba's blog - 'debuggerd of Android'
No more bugging
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Noob.Saibot said:
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Click to expand...
Click to collapse
apologies, i should have been clearer, as i too had root privy requests whilst on 4.1.1 - however the frequency of this increased noticeably once upgraded to 4.1.2. also i have no other apk's title being added to the debuggerd name in system/bin. i had only 2 files in system/bin - the 1st was "debuggerd" and the second "debuggerd.exynosabuse". this seems to be saying that something is specific enough about exynosabuse for the separately titled file to appear.
if anyone finds any other files identified in this way please comment.
so in all, i should have said, for me, that the debuggerd bugged me more, via the massive increase in root requests, when sitting with 4.1.2 than it did when i had 4.1.1 installed.
again, anyone with ideas as to what and why this debuggerd saga is taking place would be greatly appreciated.
I'm having the same issue, denying debuggerd.exynosabuse in SuperSU just causes my phone to reboot when the requests come through. This happens multiple times a day.
It is probably a malware.
Update to 4.1.2 asap.
Sent from my GT-N7100 using xda app-developers app
Noob.Saibot said:
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Click to expand...
Click to collapse
I am getting "debuggered.exynosabuse cannot be deleted" when I try this method
EDIT: didn't have it set to write, got it to work. Will report back in a few days on whether or not it shows up again.
---------- Post added at 02:39 PM ---------- Previous post was at 02:23 PM ----------
UtkarshGupta said:
It is probably a malware.
Update to 4.1.2 asap.
Sent from my GT-N7100 using xda app-developers app
Click to expand...
Click to collapse
Others in this thread have said that updating doesn't fix the problem, and that it's actually more persistent on 4.1.2
I appreciate offering your assistance, but does anyone know for certain what's going on or are we all just speculating?
Hi!
As with Galaxy S2, I have ported the u-boot bootloader to the Galaxy Nexus. It can be chainloaded from samsung bootloader (loaded instead of linux kernel) safely.
It could be useful to have multiple ROMs on one device or test other OS like Ubuntu or Genode.
Detailed installation guide is available at Ksys Labs LLC wiki http://ksyslabs.org/doku.php?id=gnex_uboot .I'll just copy-paste it here
Happy hacking and don't forget to visit our wiki at http://ksyslabs.org !
===== Rationale ======
There were a couple reasons to port u-boot to Galaxy Nexus
* Security: we cannot trust the proprietary samsung bootloader
* Implementing dual-boot for original and custom firmware
* Booting Genode operating system
===== Demo =====
===== Compilation from source =====
Source code is in https://github.com/Ksys-labs/uboot-tuna
There exist two branches of interest
* master - contains the official stable releases. may be force-pushed and rebased, beware
* tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode
To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that's what I'm using and some users reported that newer compilers produce broken binaries.
There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL.
Flashing instead of SBL has the following advantages
* Faster boot time than chainloading
* Ability to use the standard partitioning layout
There is a number of issues and therefore we do not recommend flashing it instead of SBL
* No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you'll have to use OMAPFlash to restore the device if you flash a non-working kernel
* No display initialization. You'll have to disable the "Check for Bootloader initialization" option in kernel config
By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address **0x81808000**.
If you want to build the SBL replacement version, edit the **include/configs/omap4_tuna.h** file and uncomment the **#define TUNA_SPL_BUILD** line. X-loader loads the bootloader to the address **0xa0208000**.
Code:
export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-
U_BOARD=omap4_tuna
make clean
make distclean
make ${U_BOARD}_config
make -j8 ${U_BOARD}
mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg
===== Installation =====
==== Chainloaded Mode ====
You'll need the root access to your device.
You can take the prebuilt u-boot here. http://ksyslabs.org/lib/exe/fetch.php?media=gnex-uboot-chainloaded.img
The u-boot has the support for android boot images. When flashed instead of the SBL, it boots the kernel off the "Boot" partition. When chainloaded, it looks for the kernel in **/system/boot/vmlinux.uimg** . Additionally, it first looks for the **/system/boot/boot.scr.uimg** so you can put custom commands there and override the kernel image.
It also supports booting custom images from **/sdcard/boot/vmlinux.uimg** and **/sdcard/boot/boot.scr.uimg**
If you need larger images, I suggest that you use the **tuna-fosdem-hacks** branch, format the cache partition to ext2 and put the files to **/cache/media/boot/**
push the files to your device via adb
Code:
adb push gnex-uboot-chainloaded.img /sdcard/
adb hell
now, in the device shell, do the following
Code:
su
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/boot > /sdcard/vmlinux.uimg
mount -o remount,rw /system
mkdir /system/boot
cp /sdcard/vmlinux.uimg /system/boot/
cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
sync
reboot
Instead of installing gnex-uboot-chainloaded.img via dd, you can use fastboot
Code:
fastboot flash:raw boot u-boot.img
===== Replacing samsung bootloader =====
OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB.
Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed. The installation procedure is roughly the same, but use **sbl** partition. And also install xloader from http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
Code:
adb push gnex-xloader-working.img /sdcard/
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP.
Search the internet for the archive named "OMAPFlash_tuna.zip" which has md5 "ddbf07a1d36b044c40af5788a83b5395". We cannot upload it here because of the unclear license status.
===== Making images =====
You can either use Android's mkbootimg to produce ANDROID! type images (not recommended) or u-boot's mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images.
==== making a custom boot image ====
Code:
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg
#alternatively, just do that when compiling linux
#do not forget to add mkimage to your PATH variable
make uImage
==== making a custom boot script ====
Code:
mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg
===== Booting Modes =====
The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android "reboot to recovery" and "reboot to bootloader" features
* Normal Boot -> no keys are pressed, cyan LED
* Recovery Boot -> Volume Up key pressed, green LED
* Custom Boot -> Volume Down key pressed, blue LED
* USB RNDIS mode -> both Volume keys pressed, purple LED
===== Pitfalls =====
* No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you're chainloading, right?
* Serial number is always 0123456789abcdef or sth like that. Anyone to fix that?
* UART support is quirky. The device will likely hang if booted with the UART cable. Workaround: boot without the UART cable and plug right after the purple LED flashes.
===== A sample boot script for android =====
Make a boot.scr.uimg from it and push it to the correct location.
Code:
setenv bootargs "mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18
no_console_suspend console=ttyFIQ0";
setenv loaddaddr 0x82000000;
setenv devtype mmc;
setenv devnum 0;
setenv kernel_part 0xc;
setenv kernel_name /media/boot/vmlinux.uimg;
echo Load Address: ${loaddaddr};
echo cmdline:${bootargs};
if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then
bootm ${loaddaddr};
exit 0;
elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then
bootm ${loaddaddr};
exit 0;
else
echo failed to boot custom image;
fi
Nice!
Before there actually wasn't any dual boot stuff for Nexus but now there is really much....
I will laugh if someone ports still another dual boot loader to Nexus, E.g BootiQi dual boot loader or what it is..., (for Jét it is JétQi) but I don't remember the original dual boot files names...
Any toro support?
Sent from my Galaxy Nexus using xda app-developers app
saber.srod said:
Any toro support?
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
You may try it out. It is flashed instead of kernel, not overwriting the bootloader, so should be safe. As we don't have any Toro devices, we're not particularly interested in providing support for them unless someone steps up with a patch
Also, make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed.
Click to expand...
Click to collapse
do you have PRIMEKK14 file?
cause I couldn't find it on this thread:
http://forum.xda-developers.com/showthread.php?t=1587498
or this one is PRIMEKK14?
http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
any enlightenment please?
savantist said:
do you have PRIMEKK14 file?
cause I couldn't find it on this thread:
http://forum.xda-developers.com/showthread.php?t=1587498
or this one is PRIMEKK14?
http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
any enlightenment please?
Click to expand...
Click to collapse
The latter one is the one I'm using on my phone so it should work.
sp3dev said:
The latter one is the one I'm using on my phone so it should work.
Click to expand...
Click to collapse
I wanna use the chainloaded method, so first thing I should do is fastboot-ing that .img just like another bootloader file? then chainload the u-boot file?
but it looks like I'm replacing samsung SBL (replacing SBL method) if I do that, doesn't it?
savantist said:
I wanna use the chainloaded method, so first thing I should do is fastboot-ing that .img just like another bootloader file? then chainload the u-boot file?
but it looks like I'm replacing samsung SBL (replacing SBL method) if I do that, doesn't it?
Click to expand...
Click to collapse
Yes, you can actually fastboot it via
"fastboot flash:raw boot u-boot.img"
and no, you don't need to mess with xloader for chainloading
sp3dev said:
Yes, you can actually fastboot it via
"fastboot flash:raw boot u-boot.img"
and no, you don't need to mess with xloader for chainloading
Click to expand...
Click to collapse
so it's ok to do chainloading in PRIMELC03 bootloader? If yes, I'm success...
finally "The Great Sp3dev"
nice work like always,
playing with it now,let's see where it goes
Sent from my Galaxy Nexus using xda premium
sp3dev said:
The latter one is the one I'm using on my phone so it should work.
Click to expand...
Click to collapse
ah, I bricked my phone with your gnex-xloader-working using following script... It is only 128K. Is that right?
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
Is PRIMEKK14 bootloader the only one to work since we only have http://forum.xda-developers.com/showthread.php?t=1587498 this thread for bootloader and there's no flashable version of PRIMEKK14?
I use OMAPFlash to save it having PRIMEKK15 bootloader and I do not have the courage to do it again...
dlhxr said:
ah, I bricked my phone with your gnex-xloader-working using following script... It is only 128K. Is that right?
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
Is PRIMEKK14 bootloader the only one to work since we only have http://forum.xda-developers.com/showthread.php?t=1587498 this thread for bootloader and there's no flashable version of PRIMEKK14?
I use OMAPFlash to save it having PRIMEKK15 bootloader and I do not have the courage to do it again...
Click to expand...
Click to collapse
Oh well, I specially edited the post so that chainloaded users don't flash loader. You only need the xloaded if you flash u-boot instead of SBL. Otherwise, treat u-boot just as linux kernel.
As for replacing bootloader, I guess PRIMEKK15 should also work, I just didn't notice when the security check was introduced. Yeah, use OMAPFlash to recover anyway. And note that you cannot use my precompiled u-boot to replace SBL. As written in the beginning of the post, you need to change a define in config and recompile because the load address and partition layout are different for chainloading and direct booting cases.
Very nice! Keep the good work up! :good:
sp3dev said:
Oh well, I specially edited the post so that chainloaded users don't flash loader. You only need the xloaded if you flash u-boot instead of SBL. Otherwise, treat u-boot just as linux kernel.
As for replacing bootloader, I guess PRIMEKK15 should also work, I just didn't notice when the security check was introduced. Yeah, use OMAPFlash to recover anyway. And note that you cannot use my precompiled u-boot to replace SBL. As written in the beginning of the post, you need to change a define in config and recompile because the load address and partition layout are different for chainloading and direct booting cases.
Click to expand...
Click to collapse
Some feedback here. I flashed u-boot to boot partition and save the original boot image to /system/boot/vmlinux.uimg.
Without any key pressed it shows
Code:
Wrong Image Format for boot command
Error: can't get kernel image!
Not booting xxxxxxxxx
Fail to boot
The characters on the screen does not show well and some of them can't be recognized....
When I press the volume up, it boot into recovery.
When I press the volume down, it shows
Code:
File not found /media/boot/vmlinux.uimg
Unrecognized filesystem type
Fail to boot
Something is wrong with my procedure?
Another small question. I want to make a zip to flash the U-boot, but always failed. I have to use fastboot command to flash gnex-uboot-chainloaded.img to boot.img.
What is in my updater-script.
Code:
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");
package_extract_file("gnex-uboot-chainloaded.img", "/tmp/gnex-uboot-chainloaded.img");
package_extract_file("META-INF/com/google/android/switch_boot.sh", "/tmp/switch_boot.sh");
set_perm(0, 0, 0777, "/tmp/switch_boot.sh");
run_program("/tmp/switch_boot.sh");
set_perm(0, 0, 0777, "/system/boot/vmlinux.uimg");
unmount("/system");
What is in my switch_boot.sh
Code:
#!/sbin/sh
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/boot > /tmp/vmlinux.uimg
mkdir /system/boot
cp /tmp/vmlinux.uimg /system/boot/
cat /tmp/gnex-uboot-chainloaded.img /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
It seems the last line doesn't work...
Code:
cat /tmp/gnex-uboot-chainloaded.img /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
If I use the following command in updater-script,
Code:
package_extract_file("gnex-uboot-chainloaded.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
The device enters bootloader directly showing no boot image after reboot....
dlhxr said:
If I use the following command in updater-script,
Code:
package_extract_file("gnex-uboot-chainloaded.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
The device enters bootloader directly showing no boot image after reboot....
Click to expand...
Click to collapse
That's because SBL expects the boot partition to contain the image in ANDROID! format. It creates the image itself when you flash via fastboot with the ":raw" suffix.
Try that
Code:
mkbootimg --kernel gnex-uboot-chainloaded.img --ramdisk /dev/null -o u-boot.aimg
Not sure why the original boot image didn't work for you. Are you copying the boot.img to vmlinux.uimg or the raw zImage? you should do the former, the u-boot expects either the "ANDROID!" image or the one made with mkimage.
If anything, you could try repacking the boot image yourself or try mine to see if it boots (it's for jb 4.1.1 though)
http://rghost.ru/44686398
chainloading method, in fact it works on PRIMELC03 too...
btw,
if I flash the xloader (replacing bootloader method), then how am I gonna back to original samsung bootloader/PRIMELC03 since there isn't fastboot support in your u-boot bootloader?
using odin? or omapflash? :crying:
thanks.
savantist said:
chainloading method, in fact it works on PRIMELC03 too...
Click to expand...
Click to collapse
ok, I probably didn't make it clear enough. chainloading works with any bootloader and is safe.
savantist said:
btw,
if I flash the xloader (replacing bootloader method), then how am I gonna back to original samsung bootloader/PRIMELC03 since there isn't fastboot support in your u-boot bootloader?
using odin? or omapflash? :crying:
thanks.
Click to expand...
Click to collapse
if you can boot android or recovery, thenuse dd it to /dev/block/blah-blah-blah, otherwise - omapflash.
sp3dev said:
ok, I probably didn't make it clear enough. chainloading works with any bootloader and is safe.
if you can boot android or recovery, thenuse dd it to /dev/block/blah-blah-blah, otherwise - omapflash.
Click to expand...
Click to collapse
you wrote it on wrong part on first page yesterday, makes me little bit confused, but it's corrected now...
but to do "replacing bootloader method", one should flash PRIMEKK14 or PRIMEKK15 bootloader before, right?
wow... omapflash...
savantist said:
you wrote it on wrong part on first page yesterday, makes me little bit confused, but it's corrected now...
but to do "replacing bootloader method", one should flash PRIMEKK14 or PRIMEKK15 bootloader before, right?
wow... omapflash...
Click to expand...
Click to collapse
well, some bootloaders after PRIMEKK may work, but I have not tested and we had some new phones with the recent firmware versions from stock, and u-boot failed to work there until xloader was downgraded
Hello.
To the point:
We need to patch this file
drivers/video/broadcom/kona_fb.c
find these lines (for me 97-101):
Code:
#define SUSPEND_LINK_DELAY_MS 100
static bool enable_corners = true;
static struct pi_mgr_qos_node g_mm_qos_node;
and set enable_corners to false.
That's it
Cheers
heyjoe66 said:
Hello.
To the point:
We need to patch this file
drivers/video/broadcom/kona_fb.c
find these lines (for me 97-101):
Code:
#define SUSPEND_LINK_DELAY_MS 100
static bool enable_corners = true;
static struct pi_mgr_qos_node g_mm_qos_node;
and set enable_corners to false.
That's it
Cheers
Click to expand...
Click to collapse
Or revert patch from aosp
Sent from my SM-G935F using XDA-Developers Legacy app
For anyone who wants to add this change to your current Marshmallow ROM, you can turn off the rounded corners on the fly in ADB. You need to type 'su' for root permissions, then type the following:
Code:
echo N > /sys/module/kona_fb/parameters/enable_corners
Obviously this would revert on reboot - for a permanent change you need to do the following:
Unpack boot.img (CarlivImageKitchen, Google it)
Add a line to init.common.rc (right below the other 'write sys/module' command) as follows:
Code:
write /sys/module/kona_fb/parameters/enable_corners N
Repack the boot.img (using CarlivImageKitchen)
Reboot the watch to the bootloader, eg, adb reboot bootloader
Then run
Code:
flashboot flash boot your_new_boot.img
Then run
Code:
fastboot boot your_new_boot.img
Congrats, your screen has square corners again!
Omg thanks!
A long time ago, I posted in a forum thread about my difficulty in trying to revive my M2003J15SG and after having my ethereal Windows install bricked. I switched to Fedora and tried my hand there, where surprisingly, things worked very well. I'm not calling this a guide because I'm basically piecing this together from my bash_history and recollection. I have used the word guide too many times to keep that sentence but yeah, it may be shaky in some places.
Disclaimer
Code:
/*
* Your warranty is... still valid?
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns.
*
* I have removed the part about laughing at you because I'm not a meanie :3
*
* But yeah, this text is as-is. We provide this work to you without
* warranty of any kind, express or implied and in no event shall the authors
* be liable for any claim, damages or other liability in any way, shape or form,
* arising from, out of, in connection with the work
*
*/
A few things to note
This is an attempt to document my experience with BROM recovery of a phone that I bricked because I flashed an incorrect littlekernel image. If you're able to use other methods (using fastboot, recovery mode, hell, even preloader mode, you should probably go with that, this is a last resort).
This guide does involve opening your device, you will need a heat gun, a few picks and a screwdriver. No, this is not optional.
If you've read the excellent guide by VD171 on bypassing authentication and flashing, you may notice the important text that states
> Once you get "Protection disabled" at the end, without disconnecting phone and usb, run SP Flash Tool
That's because if you do disconnect and attempt to reconnect your device, it won't be recognized anymore. On Windows, this manifests as the infamous "USB device not recognized" error. This isn't you installing incorrect drivers, that's the device behaving erratically.
To have a second go at it, you have to press Vol Up + Power for about 60 seconds before you can retry.
To enter BROM mode, you need to press Vol Down and no other key, and then plug in your device.
This guide while being Fedora-specific, could be translated to other Linux distros assuming you have the necessary packages installed and have the appropriate permissions and udev rules set
This model of device doesn't need the kamakiri-specific kernel patch
On RHEL-like distros like Rocky Linux and... RHEL, you may need to disable SELinux. I have mine disabled at install so I'm not sure how this guide will behave with SELinux enforcement enabled.
Click to expand...
Click to collapse
Ingredients
Stock MIUI ROM V11.0.5.0.QJOMIXM (the fastboot variant), which you can get from XiaomiFirmwareUpdater
SP Flash Tool v5.2020 for Linux, which you can get from SPFlashTools
VD171's readback_ui_bak.xml, which you can get from their XDA Forums thread
VD171's scatterfiles for V11.0.5.0.QJOMIXM, which you can get from their XDA forums thread
You'll specifically need MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt and MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt
mtkclient, an MTK device exploit kit, which you can find on their GitHub (you'll need their master branch, not their releases, so there'll be instructions on how to fetch it)
A box of chocolate chip cookies
Click to expand...
Click to collapse
a) Preparing the computer
Step 0: Extract all ingredients and put them into one directory for ease of access
You can do this via the command line or through your file manager, it's just for convinence. This guide will assume that everything is done in one neat folder.
Click to expand...
Click to collapse
Step 1: Install all the dependencies you'll need
Bash:
sudo dnf install android-tools git libusb-devel python3 python3-pip systemd-udev
Step 2: Prevent Linux from interfering with MediaTek serial connections
Bash:
sudo touch /etc/udev/rules.d/20-mm-blacklist-mtk.rules
echo "ATTRS{idVendor}==\"0e8d\", ENV{ID_MM_DEVICE_IGNORE}=\"1\"" | sudo tee /etc/udev/rules.d/20-mm-blacklist-mtk.rules
echo "ATTRS{idVendor}==\"6000\", ENV{ID_MM_DEVICE_IGNORE}=\"1\"" | sudo tee -a /etc/udev/rules.d/20-mm-blacklist-mtk.rules
Step 3: Clone mtkclient and install its dependencies
Bash:
git clone https://github.com/bkerler/mtkclient
cd mtkclient
pip3 install -r requirements.txt
python3 setup.py build
sudo python3 setup.py install
Step 4: Install mtkclient's bundled udev rules
Bash:
sudo usermod -a -G dialout $USER
sudo cp Setup/Linux/*.rules /etc/udev/rules.d
Step 5: Reload udev rules
Bash:
sudo udevadm control --reload-rules
sudo udevadm trigger
Step 6: Return to previous directory
Bash:
cd ..
b) Preparing the device
This is where you basically follow this iFixit guide for the purposes of just disconnecting the battery cable. So, just stop at Step 12, then put the back cover on just flush enough that you can now click the volume and power buttons and insert a cable into the USB-port but not too much so that you have to go through the effort of reopening it again (because, well, you'll have to).
Attempting to skip this will yield you STATUS_EXT_RAM_EXCEPTION.
Click to expand...
Click to collapse
c) Backing everything up
Alongside ROM and userdata, your EMMC contains your IEMI, your bootloader lock state, MAC addresses, calibration data, the whole nine yards. It's always a good idea to back things up before we get started.
Step 1: Copy readback_ui_bak.xml to the SP Flash Tool directory
Bash:
cp ./readback_ui_bak.xml ./SP_Flash_Tool_v5.2020_Linux/readback_ui_bak.xml
Step 2: Connecting your device and applying the exploit
Start off by running the exploit.
Bash:
cd mtkclient
chown +x mtk
./mtk payload
Once it says Preloader - Status: Waiting for PreLoader VCOM, please connect mobile, hold down Vol Down and connect your phone to the computer. If everything goes according to plan, you'll get an output similar to this.
Code:
Port - Device detected :)
Preloader - CPU: MT6768/MT6769(Helio P65/G85 k68v1)
Preloader - HW version: 0x0
Preloader - WDT: 0x10007000
Preloader - Uart: 0x11002000
Preloader - Brom payload addr: 0x100a00
Preloader - DA payload addr: 0x201000
Preloader - CQ_DMA addr: 0x10212000
Preloader - Var1: 0x25
Preloader - Disabling Watchdog...
Preloader - HW code: 0x707
Preloader - Target config: 0xe7
Preloader - SBC enabled: True
Preloader - SLA enabled: True
Preloader - DAA enabled: True
Preloader - SWJTAG enabled: True
Preloader - EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT: False
Preloader - Root cert required: False
Preloader - Mem read auth: True
Preloader - Mem write auth: True
Preloader - Cmd 0xC8 blocked: True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - HW subcode: 0x8a00
Preloader - HW Ver: 0xca00
Preloader - SW Ver: 0x0
Preloader - ME_ID: [redacted]
Preloader - SOC_ID: [redacted]
PLTools - Loading payload from mt6768_payload.bin, 0x264 bytes
PLTools - Kamakiri / DA Run
Kamakiri - Trying kamakiri2..
Kamakiri - Done sending payload...
PLTools - Successfully sent payload: [redacted]/mtkclient/mtkclient/payloads/mt6768_payload.bin
Click to expand...
Click to collapse
Step 3: Open SP Flash Tool
Bash:
cd ../SP_Flash_Tool_v5.2020_Linux
chmod +x flash_tool
sudo ./flash_tool
Yes, I'm aware, it's technically not advisable to grant superuser privileges to, a flashing tool but... I can't get it to work otherwise, if you know how to make it work on Fedora, drop a comment.
Click to expand...
Click to collapse
Step 4: Load the Download Agent (DA)
Click "Choose" and go to (common directory)/mtkclient/mtkclient/Loader/xiaomi_9_DA_6765_6785_6768_6873_6885_6853.bin
Click to expand...
Click to collapse
Step 5: Configure SP Flash Tool
Go to Options > Option
In General, uncheck "Storage Lifecycle Check"
In Connection, select "UART"
COM Port: /dev/ttyACM0 (it may not be the exact number, it'll just look something similar to this)
Baud rate: 921600
In Download
Uncheck "USB Checksum"
Uncheck "Storage Checksum"
Click to expand...
Click to collapse
Step 6: Backup device contents
Start by going to the "Readback" tab, it should already be populated with values that correspond to images from pgpt to otp. If you are presented with an empty table, you've need to go back and check if you've copied readback_ui_bak.xml to the correct directory.
If it shows up, then click "Read Back" and if all goes according to plan, you should see the green checkmark show up eventually.
Click to expand...
Click to collapse
d) Flashing stock firmwareStep 1: Copy scatterfiles to ROM directory
Bash:
cp ./MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt
cp ./MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt
Step 2: Flash the firmware
Return to the "Download" tab and select the MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt scatterfile we just copied in the ROM's images directory
Select "Firmware Upgrade" from the drop-down menu and then hit "Download". If all goes according to plan, you should see a green checkmark.
Click to expand...
Click to collapse
Step 3: Restore bootloader status (optional)
In case you had an unlocked bootloader before imploding your phone and don't want to bother with Xiaomi's rigmarole, then by restoring seccfg, you should get it back.
Step 3.1: Copy over seccfg from our backup
You're probably going to be using a new terminal window because SP Flash is still running, navigate to your common directory first. The backup we did earlier stored all the images within the SP Flash Tool directory. We need to use sudo because flash_tool was running with root privileges and so, was writing with root privileges as well.
Bash:
sudo cp ./SP_Flash_Tool_v5.2020_Linux/seccfg ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/seccfg
Step 3.2: Change the scatterfile, select the image and flash it
Change the scatterfile to MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt and un-select everything except seccfg
Select "Download Only" from the drop-down menu and then hit "Download". Fingers crossed, green checkmark, you should get your unlock back.
Click to expand...
Click to collapse
Step 4: Reconnect your battery and first boot
If you've reached this point and everything has worked as expected, reconnect your battery, long press the Power button and you should be greeted with a boot animation and hopefully a functioning phone.
Click to expand...
Click to collapse
e) Packing it up
Basically, just... follow the iFixit guide from Step b) in reverse and seal up your phone. I don't use this phone regularly so I never bothered sealing it, relying only on the plastic clips. You probably should but that's outside the scope of this journal.
Click to expand...
Click to collapse
f) Upgrading to Android 11 (optional)
As of this writing, LineageOS supports this device under the codename merlinx (the x is because of a conflict with the Moto G3 Turbo, which shares the same codename) and according to their install documentation, they expect a base of Android 11 and this guide flashes Android 10.
I personally used the V12.5.4.0.RJOMIXM firmware (available from XiaomiFirmwareUpdater, again, use the fastboot version) but I did an ever-so-slight change. The entire song-and-dance of needing the bypass exploit is because of "upgrades" made to the payload. I modified flash_all.sh to omit flashing the payload and the modification looks something like this (the other comment-outs were already there in the file)
Bash:
(...)
#fastboot $* flash preloader `dirname $0`/images/preloader_merlin.bin
#if [ $? -ne 0 ] ; then echo "Flash preloader error"; exit 1; fi
#fastboot $* flash efuse `dirname $0`/images/efuse.img
#if [ $? -ne 0 ] ; then echo "Flash efuse error"; exit 1; fi
fastboot $* flash logo `dirname $0`/images/logo.bin
if [ $? -ne 0 ] ; then echo "Flash logo error"; exit 1; fi
fastboot $* flash tee1 `dirname $0`/images/tee.img
"Flash preloader error"; exit 1; fi
(...)
I also commented out the reboot command at the end so I could flash LineageOS's recovery and flash the OS that I wanted.
Bash:
(...)
#fastboot $* reboot
#if [ $? -ne 0 ] ; then echo "Reboot error"; exit 1; fi
(...)
Of course, you need to boot into fastboot mode (by taking a turned off device and pressing Power + Vol Down) before you execute the script
Code:
cd merlin_global_images_V12.5.4.0.RJOMIXM_20220325.0000.00_11.0_global
chmod +x flash_all.sh
./flash_all.sh
Click to expand...
Click to collapse
Sources
https://github.com/bkerler/mtkclient
https://github.com/bkerler/mtkclient/issues/94
https://www.hovatek.com/blog/my-experience-unbricking-a-dead-boot-lg-stylo-6/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4221065/
https://forum.xda-developers.com/t/...for-merlin-redmi-10x-4g-redmi-note-9.4238149/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4223107/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4223093/
Wow !
Really amazing guide !
Nice, nice
Thank you very much for contribution