yashsingh1/xdaforums huggingface dataset:
[One (M8) Android Development] donmarkoni:
[MENTION=5301689]dgtiii[/MENTION], [MENTION=3647976]guyd[/MENTION], I'll start by saying: don't give up! How many hours were you trying to bring to life your M8? If it's not measure in hours, then you gave up to soon, it's very expensive phone to give up easily. ;)

IMO, if bootloader is untouched, then it has possibility to be brought back to life. If I read correctly [MENTION=2094451]dgti[/MENTION]i you didn't flash hboot.img on last flash, right? [MENTION=3647976]guyd[/MENTION], you flash modified hboot when you got brick, or am I wrong?

When I got QHSUSB_DLOAD mode on M7, it was not logical, although I was messing with bootloader, replacing it with engineering one, I was constantly comparing everytnihg with diff and m5sum. Finally it booted. Oh, how I was happy. :) But it didn't stop me from flashing custom rumrunner engineering bootloader later on. Now I'm using custom firewater bootloader, waiting for engineering one.:cool:

[MENTION=1102297]Sneakyghost[/MENTION], this requires your attention too, so let me begin... I hope you understand me, as I may sound paranoid... :eek:

Looks like something fishy is going on with this phone. Either HTC doesn't want us to mess with it, making confusing changes, so we can't find patterns, or somebody is placing messed up files on M8 forums.

I can't properly unpack any radio.img, always have errors on two file, but it could be just me ( help? :eek: ).

Also there is a difference in my mmcblk0p20 (radio) partition which is WWE and [MENTION=1631739]mike1986.[/MENTION]'s firmware 1.54.401.1 zip posted here which should be WWE, as I already said in radio thread here.

I'm testing while writing these post, so right now it looks to me like that is the difference why some versions work for some and not for the others, as stated here also. Flashing one with "MBA " (MBA and five SPACEs) on 0x0032520 address works for me, while flashing other with "A7B80E1 " (A seven B eight zero E one and one SPACE at the end) makes radio stuck in WCDMA mode (Dialer/*#*#4636#*#*/Phone information/Set preferred network type) and cant be changed to GSM/WCDMA/LTE auto, while Settings/About/Software information/More/Baseband version says: Unknown.

I'll do some more tests by hex editing few versions and flashing to check if working.
[One (M8) Android Development] Sneakyghost:
Sorry guys something really dodgy happening out there right now. There is a thread for the M7 with modified hboots which caused a number of bricks today.

It followed the 5.11 release.

I got notified this morning that there were lots of bricks and people blamed the dude who modded the hboots but then it turns out there were two hboot revisions, both same version number, both rolling out with the same OTA and after hearing about your bricks, i am nearly sure, that HTC screwed up something in the bootloader code.

Apparently the M7 victims were partly able to recover by repeatedly pressing power and voldown, here on the M8 it would be VolUp i believe.

I still dont have my M8 back and its still not possible to S-OFF but even if i had it, i would hold back from flashing any new firmware right now until we know what is causing this desaster.

And one more thing: if you do zips, please please please do NOT use winrar! Those zips do work most of the time but sometimes dont. Use 7Zip, it manages the right compression tech. WinRar has something messing up the zips occasionally. If i were you, i'd exclude any unsecure stuff from the process, it can be fatal for your phone as you might have just experienced ;)

[EDIT]

I was just discussing this with a friend. I have not gotten around reading much of those threads where the bricks happened.

My friend reckons the facts are:

6 OTA updates rolling right now

3 of them are major OS updates (M7)

5 Bricks reported on M7

2 Bricks reported here on M8

= this can still be read as collateral damage of a bigger OTA wave. It is not necessarily unusual.

It was also noted that 3 of the 5 M7 cases were able to recover.

Then there is a chance that the guys providing the firmware packs were unpacking and rezipping wrong and caused the damage.

Then we have to take into account wonkey EMMC chips that sometimes have a hard time to initialize and that changes in bootcode can make them not start up (hence the 3 M7 people could recover by keeping to try and get them to boot).

I will keep an eye on this but it could be you two were just extremely unlucky.
[One (M8) Android Development] donmarkoni:
I believe I can say their's name as in mine that there is no need to apologise. ;)

I am following closely what is going on too.

Thanks for the advices! I was using 7zip since very long time. Also, I always used FW stuff from trustworthy sources, especially bootloader. Waiting for [MENTION=711482]beaups[/MENTION] and [MENTION=4519372]Fuses[/MENTION] to make/release eng hboot. I strongly believe that it's very hard to brick with it. I hope to never prove myself wrong. :D
[One (M8) Android Development] tiho5:
What if the culprit was their former hboot (the one they had up to the unfortunate flashing)?

I think that this is possible as [MENTION=5301689]dgtiii[/MENTION] didn’t have hboot in the custom package which he made (by the way that is why he didn’t get the re-flash message, which is normal), so the logic says that his current hboot must have screwed up somewhere.

On the other hand [MENTION=3647976]guyd[/MENTION] had hboot included in the package, BUT didn’t get the re-flash message too.

What if the hboot they had already is flashing something else in mmcblk0p11, the hboot partition for instance?

For that theory to be right, they both have to have flashed only an hboot the last time they have flashed a FW package (the time preceding the unfortunate flash).

This must have been the case for dgtiii as he said that he had a custom hboot flashed after he upgraded the fw the first time.

I guess if what I say is possible that If there was something else inside that package back then with the custom hboot:

- the hboot goes flashed first

- then it is responsible for the flashing of the rest of the images in the fw package

- if the hboot from the package is faulty it was possible that provided there were also other images in that package, the new hboot might have already then put some of the other images in the wrong partition. And have a bricked device already then.

I might be totally wrong and I am sorry if I don’t make sense. Someone with more knowledge could prove me right or wrong in which case ignore this
[One (M8) Android Development] dgtiii:
[MENTION=2977387]donmarkoni[/MENTION] [MENTION=1102297]Sneakyghost[/MENTION] [MENTION=2676284]tiho5[/MENTION]

Thanks for the replies mates, I really appreciate it! I still haven't given up trying to revive my M8, but it's looking grim. I'll keep trying, phone was too expensive to be a paperweight. Based on what both of you said, everything I've been reading, and my own experience, I think it's a combination of a possible bad firmware released by HTC, and them making it harder to modify the M8 yourself (but in a very inconsistent way). There's something about the M8 that is very inconsistent: different hardware causing s-off issues (sorry Sneaky), none of the custom recoveries (TWRP, Philz) work 100% for all users in something as basic as restoring backups, as donmarkoni pointed out, flashing radios is extremely dodgy, and now firmware flashing seems suspect. It's going to make me very cautious in the future. I suspect HTC changed something in the M8 that we are not aware of yet.

I used 7zip, by the way, not winrar.

As for the hboot theory, I just don't know. I didn't flash and hboot, guyd did, and we both got the same result from the same firmware. I think on of the other images might have been the culprit. The modded hboot I flashed with 1.54.401.5 seemed to work fine without any issues for a month, so I can't see why flashing the .1540 firmware would have suddenly given issues, but who knows? I really think there's something about the M8's we do not understand yet.

Thanks again mates!
[One (M8) Android Development] Sneakyghost:
Hi, back. Was fixing PC's (mine included).

I wanted to say that none of the above is regarded off-topic by me. I am still planning on doing firmware stuff once i am able to test stuff myself (biggest horror for me: being the one giving people bricks).

Along with this piece of reassurance (please keep posting your thoughts) i'd like to ask to keep it short and precise. I am not a good thinker myself and have a hard time deriving the facts from the stories and guesses.

So far i can see only one outstanding fact besides the fact that we currently have a huge number of devices being updated:

- The Hboot that was flashed (e.g. the "new one") is NOT the cause, because one brick happened after a flash without a hboot in the package)

Everything else is guessing. My preferred guess currently is this:

- We know that the M8 has been fitted with parts from different vendors [MENTION=711482]beaups[/MENTION] will approve i reckon :D ) - this is very common and was the case on nearly every HTC device i ever had in my hands)

- We know for sure the Camera has been contracted to a different vendor to eliminate the pink tint of the M7 cam (Thats HTC statements i cite)

- We know for sure some unknown component has changed, hence Firewater won't work on a number of devices

- We know for sure Verizon has devices fitted with a different Touch Controller chip (because Aroma doesn't work with touch on some of them) and the GSM Firmware has 3 different touch panel drivers.

So, i guess the EMMC has different Vendors as well, like has been the case on all HTC's. This time, it might be, that one batch from one Vendor has a hard time to initialize. This is my guess. Here ends my knowledge. From here on, It would be for instance Beaups who could help with explanations and thoughts. But i also realize he won't be up for that most likely, so we need to find out ourselves.

Still, my previous statement holds true: we should hold back flashing and observe what happens during the next days. It could be nothing after all.
[One (M8) Android Development] tiho5:
One thing is sure: This place lacks a pro(per) firmware thread...

I sincerely hope you get yours S-Offed, mate. I don't like this m8 mess now.
[One (M8) Android Development] guyd:
In my case, I was 100% original stock Dev Edition 1.12.1540.17 firmware. I did have a custom ROM, custom Recovery, and custom Kernel. That's it. So I thought that flashing the Dev Edition 1.54.1540.9 firmware would be a simple process. Boy, was I wrong! :eek:

I never flashed a modified hboot.
[One (M8) Android Development] Sneakyghost:
emmc_appsboot.mbn on HTC ONE M8 - purpose

There is a new file called "emmc_appsboot.mbn" which i thought might play a role in firmware flashing on the M8. I spent a considerable amount of time yesterday reading through the plain-text part of that file (about half of it is obfuscated or encrypted). The plain-text consists of only error messages and gives a fair idea about what this does.

- It is not included in an OTA, only in the RUU, so it cannot be required for all firmware flashes

- It covers memory related errors (internal NAND and SDcard)

- It covers a wide range of fastboot/usb related errors

- It carries no values anywhere but a ton of variables, i assume its not holding any specific data, rather flashing routines

- It is having a lot of stuff that looks similar to what a bootloader would be doing.

I am interested in working out a solid theory what this does. Maybe someone with a better understanding of the flashing process could have a look and share his thoughts?

Google results for emmc_appsboot.mbn:

- https://www.codeaurora.org/cgit/qui.../?id=77b7b326a9183153bdf6d838ea92ee125900dfd9

- http://www.android-hilfe.de/huawei-...ne-aenderung-nach-fastboot-3.html#post3928040 <-- German. Its a partition list from a Huawei. It suggests MBN is an image format and appsboot is a partition too.

- http://xdaforums.com/showthread.php?t=2641245 <-- Looks like sneaky is finding out pretty old stuff that was already covered long time ago.

There are more google results suggesting that appsboot is an open bootloader like the hboot but resulting out of the work of Code Aurora and made for QualComm chips. So this is a new boot instance loading before or after hboot? Do we need it? Do we forget about it entirely? Do we remove it and only flash hboot?

Maybe, if this is left untouched and we brick our bootloaders, aboot allows for better unbricking access? Assuming it loads first, then boots hboot?

This would be important for determining if we need to include this file in future packs and if yes, then when.

[MENTION=3647976]guyd[/MENTION] i am sorry to say but the preconditions you describe have nothing wrong with them and the fact that there was another brick without even a hboot in the pack, is an even clearer indication of this just gone wrong badly for no reason we could influence. Such stuff has happened before. Its not that unusual.

One thing i am still thinking about is this thing about different EMMC manufacturers and some chips maybe just being bad. It also wouldn't be the first time that happens.
[One (M8) Android Development] Sneakyghost:
Neither do i but we have to establish a bit of new knowledge for us noobs first, and need a solid testing device. My Phone is currently at Arvato Sercices Solutions in Germany with the message "warranty rejected - user manipulation" and a foto of my unlocked bootloader as proof.

I had an ugly fight on social media, post and phone with my carrier because in my opinion, they sold the device and they have to make sure its not faulty but they insist that it is something HTC/Arvato has to solve and that they have nothing to do with it. I sent them a written and signed contract cancellation request and they declined, reasoning that the phone service had nothing to do with the mobile service. They force me to stick with them another 23 months and endure their terrible rip-off service (It is 1&1 Internet AG for the germans around here).

I contacted HTC Support and flagged my phone for HTC Elevate Premium support, hoping i get it back without being charged. The minimum would be to have it sent back free of charge and avoid the 21 Euro they want for just checking it. The best would be an exchange under warranty. I would also make do with a repair job though.

Well, what do i have learned so far? I will share and others might contribute.

New firmware images:

- adsp.img <-- not new but required to be replaced with the sprint HK Edition image for the Harmann/Kardon tech to work because the Advanced Digital Signal Processor is what offers the sound processing and if you want a higher bit resolution in sound, this will have to be changed. Provided, the hardware is capable of it (which we know it is).

- dt.img <-- New Kernel Tech requires a DT image. I have searched the forum and seen that the kernel devs (@Faux123 and [MENTION=4684315]flar2[/MENTION]) have been talking about it and are aware of this new image.

- emmc_appsboot.mbn <-- Probably a new bootloader stage before or after Hboot. Unclear how we need to look at this.

- persist.img <-- 4Mb empty file, just one obfuscated line in there. Totally unclear to me yet.

- sensor_hub.img <-- most likely drivers. Needs to be established what exactly it is and how important/universal/exchangeable it is

- sdi.img <-- seems to be related to sensors or some hardware stuff as well. Had a look but can't guess what it is.

- wcnss.img <-- WiFi partition is back. It was dropped on the M7 in favor of a folder structure within system. Now its back. Could affect Tmo WiFi calling actually. Gonna talk to my dev guys about it because ViperOne already has WiFi Calling for Tmo working without exchanging this partition but it could be needed to make it working if someone with a non-Tmo phone hooks up to Tmo Service.
[One (M8) Android Development] dgtiii:
Good info on the firmware files, thanks Sneaky. This is why we need you mate!

Sucks about your phone, what do stuck pixels have to do with an unlocked bootloader? That's just nonsense they are trying to pull that on you. I hope they just give you a new phone.

Still trying to revive my M8, no luck so far....
[One (M8) Android Development] Sneakyghost:
Well. Pixels have nothing to do with software manipulation. But we know that HTC is using this every now and again to get around expensive replacements. I am not sure this is in compliance with EU law but i have no money for an expensive lawsuit. I would love to process this legally though. Get them to do what they have to and create a reference case for future incidents like this, so that customers dont need to each time sue them to get their rights. But as i said: no money for such adventures. So i will just hope to get a goodwill decision.
[One (M8) Android Development] housry23:
I just had a similar thing happen here in the US. I purchased the developer edition through HTC.com. I had dead pixels and initiated a replacement. When they got my phone and "inspected" it, they denied me warranty service and said I had to pay them 140USD to continue because the repair was "out of warranty". I called them and it was because the phone was s-off. I argued enough to get them to reverse the decision and send my replacement. But...they had photos of the bootloader being s-off. I was not dealing with a carrier, but HTC directly. I argued that there's no way that s-off could possibly cause dead pixels. They insisted that it could. If certain software modifications were done, it could get the phone hot and mess up the LCD. I laughed. Anyway, they should replace it. It's insane to think that software issues could possibly cause dead pixels! I hope you get it straightened out sneaky. It's really sad that you have to go through this. Unlocking a bootloader should not cause a warranty void. Especially in Europe. Don't you have laws that protect you against this type of treatment? You should have just bricked it all together. I almost just had them send my phone with the dead pixels back to me. I told them I'm going to Reddit and every other online source for this story and I'll never buy HTC again. I figured it was worth one last argue and the guy talked to his supervisor and got the fee waived and my replacement is on its way!
[One (M8) Android Development] Sneakyghost:
I'm aware. I've researched it. Technically, being S-OFF enables you to overclock and overheat the device, which in turn can cause pixels to fail. Yet, we all know this is highly unlikely.

Your situation is 100% identical to mine, I'm also dealing with HTC at the moment. The only real difference is that they charge a lot more here (284).

suspended...waiting for M8 to return ...
[One (M8) Android Development] Behold_this:
The thing about that, sneaky, is that you and I are both aware that HTC regularly provides s-off phones when they give them away (give a ways through elevate, htcdev events, Twitter and other channels) and they do not deny warranty claims on those devices.

If one person won't help you guys, ask for their manager and keep moving up until somebody does. Persistence pays off and the squeaky wheel gets the grease.
[One (M8) Android Development] donmarkoni:
Hey mate! :D Any news about your phone?
[One (M8) Android Development] Sneakyghost:
Got it back a while ago, unrepaired, claimed there was no fault.

Now waiting for some lucky guy to find a new vulnerability to exploit so I can have S-OFF. The current exploit seems to have been identified by HTC now, seeing that they successfully shut it down with the last international and T-Mobile OTA's. So, my device is not really up for firmware testing, still. Sorry.

mobile post... lazy typing...
[One (M8) Android Development] donmarkoni:
Sorry to hear that... :( I really hope some exploit is found soon. :fingers-crossed:
[One (M8) Android Development] Sneakyghost:
I'll be having a security unlocked device by wednesday night. I am readying a firmware thread layout till then and prep some packages which i will then test from wednesday onwards and upload successively.

I am undecided as to whether use this thread or rather make a new one.

Opinions?

Added a POLL on page 1 for this. Please vote!

Poll closes Wednesday, 11th of June. Results will decide.

#LowLevelDemocracy
[One (M8) Android Development] donmarkoni:
Great news! :) But, how? If it's not a secret? ;)

You do what ever you decide, fcuk democracy, it's poorly thought of, many idiots decide for few smart people. ;)

Hehe... Just kidding. :) You bring good company around in your threads. :)

Cheers!
[One (M8) Android Development] tiho5:
I'm happy to learn that finally you're joining the S-Off side of the force :)

With or without an S-Offed device you could have chosen NOT to make such thread

So a Thank You for choosing to undertake this is in order!
[One (M8) Android Development] Sneakyghost:
Looks like i am going to set up a new thread then...

thanks for the voting.

Teaser:

First ZIP's that will go up:

- 1.54.401.5_WWE_rename_to_ROM.zip and the .10 update

- 1.57.531.7_TMUS_rename_to_ROM.zip

If i find a risk-ignoring tester:

- 1.54.654.9_SPRINT_rename_to_ROM.zip and the .13 update

These will be issued as FullWipe and NoWipe versions as known from the M7 thread already.

The FUU will only be put up once and be empty. The ZIP's will be there to download and the FUU will be one method to flash as an alternative to the manual fastboot way like we have always done. So, the FUU will be the 2.12.2014 ARUWizard we got with the sprint RUU and the zips will be made as usual.
[One (M8) Android Development] beaups:
Yay. Can't wait to see all the bricks!
[One (M8) Android Development] Sneakyghost:
Is there something I don't know? Please do share [MENTION=711482]beaups[/MENTION].

All I know is there's been a series of bricks with unidentified cause, were I need to read up on to figure out what to avoid.

After all, my main goal has always been to offer safe firmware with as much info as possible so people can be safe and learn how to do it properly. I wouldn't like to create a thread that achieves the opposite...

[EDIT]

Beaups was kind enough to provide further info via PM. To sum it up: he was half joking and apparently, the serious part is something i have come to avoid anyway. Mainly concerns about Frankenbuilds consisting of either mixed CID/MID Firmware or mixed software generation Firmware.

He also pointed out that the M8 seems to be more vulnerable in terms of wrong/incompatible Firmware parts.

The new thread will address this. There will be strict rules i follow when creating the zips, mainly being: No messing with android-info.txt, no mixing of MID/CID, No mixing of different software generations, keep any zip the way it would have come from HTC.

Mainly that is what i was doing on the M7 already at last, i had given up on mixing stuff pretty early already and was following these rules more strictly later in 2013.

This means the choice of zips will be very limited and the main goal of the new thread will be to provide a RUU-like pack where HTC does not let us have a RUU. Expect less updates and more clarity. Expect no modified hboots.
[One (M8) Android Development] Galaen:
And this is why I have been waiting on your thread to get started and have not messed with my firmware. Nothing against the other people, but you never led me astray on the m7. I fear change. [emoji12]

Sent from my AT&T HTC One M8
[One (M8) Android Development] donmarkoni:
[MENTION=1102297]Sneakyghost[/MENTION], thanks for relaying important info. Appreciate the stuff you do for us, and the magic [MENTION=711482]beaups[/MENTION] and [MENTION=4519372]Fuses[/MENTION] make.
[One (M8) Android Development] Sneakyghost:
Got my S-OFF unit. Cloned my old device over, already using it.

Wife had a car accident yesterday, currently occupied with sorting out lawyer, insurance etc. Will look after this as soon as everything is sorted at home. Sorry for the inconvenience. Think at the weekend i find the time.
[One (M8) Android Development] donmarkoni:
No rush mate, first thing first! From your post I can conclude that she's alright, so thanks God for that. :)