FRIENDS help , I think I have the brick of all bricks I followed the wiki step by step including creating and copying the nbh file. I got as far as 70% of image loading and it hung and dropped into recovery mode but could not get passed there. I have tried all forms of reset and do not get passed bootloader screen with Herm100 IPL-1.04 and SPL-2.03. This was a imate jasjam running windows mobile 5.0 to which I tried flashing to the new HTC WWE 6.0 upgrade. I have tried running usb monitor from the link but it just gives me a series of paramters in a notice window and then dops off. I have tried another verison but it is not capturing anything.
I have tried mtty and cant even get the usb> prompt after disabling the usb connect in activesync. Please help as this was a works new unit last month and I have some major explaining to do if I cant get it sorted!
Model: Imate Jasjam
ROM Before Flash: TMO_UK_3.60.110.1_6275_1.50.00.00_108_Test
Radio Before Flash: 1.50
Bootloader Before Flash: Not sure
Flash failed at: 70%
Flashing ROM: Image Vers 3.54.255.3
CID Corrupt: Assume Yes
Radio Corrupt: Assume Yes
No GSM Error: Not got that far
Stuck In Bootloader: Yes
Stuck On Windows Mobile Splash: Not got that far
Can boot into OS: No
Tried mtty command set 14 0: Yes but not getting usb>
Tried wiki problem number 4: Yes dont get passed point 3 as as soon as powers up goes to tri colour screen. Switched from serial to usb with connect of usb cable
mtty info 2 output: cannot run
Current Device Status: unusable
Tried re running install and get error 260 and 294(AFTER 1%)and - Not getting a response from PDA!
I TRIED PB + KITL method .BUT IT FAILED AS I COULD NOT ACTIVATE KITL MODE.I BELIEVE ITS NOT ACTIVATED IN MY PDA.
I SPOKE TO TO IMATE INDIA PEOPLE , THEY REPLIED THAT THE MOTHERBOARD IS TO BE CHANGED , WHICH COSTS 60% OF THE COST OF THE PDA.
CAN ANYONE HELP WITH A BOOTLOADER V2.03 ?
WAKE UP DEVELOPERS .DO SOMETHING.
tHANKS IN ADVANCE.
the output is for :
HTC_Hermes_SIM_CID_Unlock_v3a
And
RUU_Hermes_TMO_UK_3.60.110.1_6275_1.50.00.00_108_Test repectively.
So no HardSPL before you flashed?
You should still be able to get a USB monitor from it.. regardless if the thing has been thrown off the empire state building.
What USB monitor program are you using?
MTTY Set 14 0 I beleive is for a corrupt radio stack, all that does is restore your radio stack to factory form, sounds to me like you have a hybrid brick, which is corrupet or invalid CID coupled along with a corrupt radio stack..
Madcap180 said:
MTTY Set 14 0 I beleive is for a corrupt radio stack, all that does is restore your radio stack to factory form, sounds to me like you have a hybrid brick, which is corrupet or invalid CID coupled along with a corrupt radio stack..
Click to expand...
Click to collapse
set 14 0 tells the device to skip to OS boot rather than go to bootloader (opposite of set 14 1)
what we need to ascertain is exactly what bootloader version this guy is running, and then to find out what CID he has from the bootloader.
until we get these both, I think we'll have to "assume" it's ****ed.
oh and in future, don't PM me twice, it pisses me off. so consider yourself lucky I've bothered to comment.
Cmd>
Cmd>info 2
HTCSCDL__001ÄÊìHTCE
Cmd>info 7
HTC Integrated Re-Flash Utility, Common Base Version : 1.51d
Device Name: HERM100, Bootloader Version : 2.03
Built at: Jun 16 2007 01:57:22
Copyright (c) 1998-2006 High Tech Computer Corporation
CPU ID=0x41129200
Main CPLD version=0x5
Upper CPLD version=0x4
Main Board version=0x6
Cmd>info 6
HTCST ÚÈÒHTCE
Cmd>info 5
Cmd>info 4
HTCSCDL__001ÄÊìHTCE
Cmd>info 3
HTCSH
Cmd>set 14 1
Write Nand Success
HTCST ÚÈÒHTCE
Cmd>rtask 32
Command error !!!
Cmd>rtask 28
Command error !!!
Cmd>rtask 8
Command error !!!
lastly it's not KITL enable.
I´d like to know if any dev or user is currently working on unlocking the locked bootloaders on the newer Atrix phones? If no, why?
Nearly all information abour unlocking the booloader is only about the old Atrix phones and the newer ones can´t be unlocked (as you guys already now ^^)
Unfortunately I don´t see a single information about if someone with knowledge is trying to unlock he bootloader.
I only see the attemps of peoples who try to unlock the bootloader with the old tutorials
RaZoR No1 said:
I´d like to know if any dev or user is currently working on unlocking the locked bootloaders on the newer Atrix phones? If no, why?
Nearly all information abour unlocking the booloader is only about the old Atrix phones and the newer ones can´t be unlocked (as you guys already now ^^)
Unfortunately I don´t see a single information about if someone with knowledge is trying to unlock he bootloader.
I only see the attemps of peoples who try to unlock the bootloader with the old tutorials
Click to expand...
Click to collapse
Here is my opinion on this subject: http://forum.xda-developers.com/showpost.php?p=28921912&postcount=15
I realy hope it was my mistkae, but I always get the same error and I was told that it could be a driver issue or the USB ports aren´t powerful enough, but I tried everything as they wrote in the Tutorials 3 times on 3 different computers with 3 different OS
Linux said :
SBF FLASH 1.24 (mbm)
OPTICALDELUSION
=== intl-fix-try1.sbf ===
Index[5]: Unexpected chip 16
Index[6]: Unexpected chip 16
00: RDL03 0x00000000-0x002FFFFF 7F75 AP
01: RDL01 0x00800000-0x008407FF 3556 BP
02: CG02 0x00000010-0x0000580F 4615 AP
03: CG03 0x000000A0-0x0008009F 2135 AP
04: CG42 0x00000020-0x0030001F F03C AP
05: CG44 0x00000050-0x0030004F 0C66 AP
06: CG47 0x00000070-0x0008006F E7CB AP
>> waiting for phone: Connected.
>> uploading RDL03: 100.0%
-- OK
>> verifying ramloader
-- OK
>> executing ramloader
-- OK
>> waiting for phone: Connected.
>> sending erase
usb_bulk_write -110
!! failed
>> rebooting
usb_bulk_write -110
and on my Atrix : SVF:106:2:3
sec_exception:b655,eddc,eb
and I have to take out the battery because it won´t reboot by itself.
tried the IHOP sbf for International phones (got a German Atrix with 2.3.4 Vodafone branding)
I even tried the file for ATT phone and got sec exception fabe 35 35.
what could I do do fix these problem and unlock my bootloader then? Maybe different/older drivers ? USB Debugging is/was on.
Helllo,
Can someone with Nokia Lumia 800 with "Qualcomm" bootloader (which appears as disk in the system) share OSBL dump?
(It should be one of sdbX partitions with around 900K size).
i have a Lumia 800 with "Qualcomm" bootloader,can you tell me how get the osbl dump from disk?
I come from darkforcesteam.com.cn.
You can email to me:[email protected]
THANKS。
hmm if you download the software for ATF I believe you will find it in there
Hi there,
i can upload you a full dump of partition 3 of the phone, if you still need it.
Cotulla said:
Helllo,
Can someone with Nokia Lumia 800 with "Qualcomm" bootloader (which appears as disk in the system) share OSBL dump?
(It should be one of sdbX partitions with around 900K size).
Click to expand...
Click to collapse
Hey my old friend , i having it
Come online skype we will chat
Tom
I have one of file that from ATF box
I think this maybe for sdb2
cotulla would be nice to have some news
you got it or you still need
http://www.4shared.com/get/hnU0x_x8/RM801_OSBL_QUALCOMM.html
I wonder if this is properly signed...
bootloader qualcoom
Hello ! What is the latest bootloader version ? i didn't make backup
yesterday when i tried to update the radio on my dinc4g (including rcdata=radio_data and rpm=radio-powermanagement, but somehow i thought it should be okay to also include boot.img (as this is reversible by TWRP recovery and tz=trusted_zone!!) ... before i compared to similar (but supposedly reversible!! partial firmware updates with their matching firmware downgrades ... all only suggested to remove at least hboot.img and stock-recovery if included) ... there was no new hboot in the new 2014 OTA firmware and stock-recovery (along with the 2ndary bootloaders) i had removed
everything also flashed just fine, no write failed, just all "OK / OKAY" and done, BUT ... after fastboot reboot ... the phone didn't come up anymore and is now STUCK on "QHSUSB_DLOAD" mode => bricked! damn ...
unfortunately the "regular" HTC unbrick tools do not support the Dinc4G ... now i'm hunting for solutions to recover my daily driver >.> already searched xda and elsewhere: tried at least brick-detect from HTC unbrick tools, but they are mainly looking if linux registers the "qhsusb_dload" _and_ adds the partitions of the phone to the running linux ... but mine only registers the serial-usb terminal from qhsusb_dload, but _not_ the phones partition(s) >_>
only thing i found is that the qualcomm QPST (oem preprogramming!) tool sees this device (albeit as said in download-mode only) and offers to flash certain things, but i do not have a QPST backup-file for the Dinc4G to compare to and/or use that to revive my phone.
i'm therefore looking for someone with a working (and at best similarly S-OFF'ed dinc4g phone to create such a QPST backup.
any help is highly welcome
further hunting the web and lots of reading here on XDA (for similarly bricked mobiles ... from almost every manufacturer!) ... the easiest (albeit not always working) idea comes down to the following:
getting a direct dump from the eMMC memory of a running/working system in a known good state:
Is anyone willing to dump the partition table/bootloader part from their working Dinc4G with FW 2.17.605.2 (the regular ICS4.0.4 without the most current 2014 OTA) for me?... best would be from an S-OFF device like mine i assume, just to make sure it matches my situation, but S-ON should also work, as it's just for recovery-boot via microSD (if it work's on a Dinc4G)
in a busybox or other terminal as root (aka: su mode)
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/backup.bin bs=1048576 count=256
this will dump the first 128MB of your own eMMC (internal memory) including your current and working partition table and some of the boot partitions
then just zip that "backup.bin" (which should greatly reduce its size!) ... uploaded it somewhere and forward me the link ...
thanks for your help!!! :fingers-crossed:
thanks to j13smiley, who provided me with a eMMC dump from his Dinc4G ... i couldn't get my bricked fireball so far to failsafe-boot from the microSD with the dump he send me:
but I was able to reconstruct the filesystem-structure quite somewhat further than mdmower here http://forum.xda-developers.com/showthread.php?t=2077608&page=7 with the descriptive help from this thread http://forum.xda-developers.com/showthread.php?t=1959445 using the HOXL as a template for partition types on HTC devices
here is what i've come up with so far (analysing the /dev/mmcblk0 dump from j13smiley:
Code:
omitting empty partition (33)
Partition 33 is deleted
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes =!size is wrong, due to using a 16GB uSD to dump the backup!=
1 heads, 16 sectors/track, 1944768 cylinders, total 31116288 sectors =!same as above!=
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System QCname
/dev/mmcblk0p1 * 1 256 128 4d QNX4.x SBL1(cfg_data)
/dev/mmcblk0p2 257 768 256 51 OnTrack DM6 Aux1 SBL2
/dev/mmcblk0p3 769 262110 130671 5d Unknown
/dev/mmcblk0p4 262111 15269886 7503888 5 Extended EXT
/dev/mmcblk0p5 262112 262143 16 5a Unknown (CID+IMEI)
/dev/mmcblk0p6 262145 262656 256 73 Unknown
/dev/mmcblk0p7 262658 293812 15577+ 5b Unknown
/dev/mmcblk0p8 293814 294325 256 5c Priam Edisk
/dev/mmcblk0p9 294327 296374 1024 45 Unknown SBL3(qscbl)
/dev/mmcblk0p10 296376 296887 256 47 Unknown RPM(appsbl)
/dev/mmcblk0p11 296889 300984 2048 46 Unknown TZ(oemsbl)
/dev/mmcblk0p12 300986 303033 1024 4c Unknown HBOOT(aboot/fota)
/dev/mmcblk0p13 303035 303098 32 0 Empty
/dev/mmcblk0p14 303100 315387 6144 34 Unknown SPLASH
/dev/mmcblk0p15 315389 317436 1024 36 Unknown
/dev/mmcblk0p16 317438 319485 1024 0 Empty (dsps)
/dev/mmcblk0p17 319487 411646 46080 77 Unknown (radio)
/dev/mmcblk0p18 411648 432127 10240 7a Unknown (adsp/q6)
/dev/mmcblk0p19 432129 442368 5120 0 Empty (wcnss)
/dev/mmcblk0p20 442370 458750 8190+ 74 Unknown (radio_config)
/dev/mmcblk0p21 458752 491519 16384 48 Unknown BOOT(apps)
/dev/mmcblk0p22 491521 524287 16383+ 71 Unknown (recovery)
/dev/mmcblk0p23 524289 526333 1022+ 76 Unknown (misc)
/dev/mmcblk0p24 526335 534526 4096 4a Unknown MODEMST1
/dev/mmcblk0p25 534528 542719 4096 4b Unknown MODEMST2
/dev/mmcblk0p26 542721 583680 20480 19 Unknown (devlog)
/dev/mmcblk0p27 583682 583689 4 0 Empty
/dev/mmcblk0p28 583691 584202 256 23 Unknown (pdata)
/dev/mmcblk0p29 584204 584235 16 0 Empty
/dev/mmcblk0p30 584237 586797 1280+ 0 Empty (local)
/dev/mmcblk0p31 586799 586926 64 0 Empty
/dev/mmcblk0p32 586928 786431 99752 0 Empty =!possibly wrong start/end&blocks!=
/dev/mmcblk0p33 83 EXT4 (system)
/dev/mmcblk0p34 83 EXT4 (cache)
/dev/mmcblk0p35 83 EXT4 (userdata)
/dev/mmcblk0p36 c FAT32(LBA) (fat)
not fully complete yet, but still much further improved over the previous partition layout details
Anything I can do to help?
I have qdload.pl, a MPRG8960.hex and 8960_msimage.mbn from some XDA thread or other (they don't seem to work though). My fireball is functional, rooted but S-ON (I got it early and htcdev still allowed me to unlock the bootloader). It does have the OTA update though.
I'm interested because my wife's fireball is stuck in QDL mode. She's migrated to a Rezound so it's not urgent.
I suspect it got that way because I used DirtyRacun S-OFF, then went to flash the OTA update. I suspect DR modifies hboot or one of the sbl's, and when I flashed the OTA it might have put me back S-ON.
(Got motivated to try to root her phone because even though it wasn't rooted, it kept trying and failing to download the OTA, killing the battery).
The DR website has an RUU.zip that has images of all the sbl's and an hboot, so working images isn't a problem, but getting them on there is.
mutterc said:
I have qdload.pl, a MPRG8960.hex and 8960_msimage.mbn from some XDA thread or other (they don't seem to work though). My fireball is functional, rooted but S-ON (I got it early and htcdev still allowed me to unlock the bootloader). It does have the OTA update though.
Click to expand...
Click to collapse
if you don't mind: plz attach your MPRG8960.hex and 8960_msimage.mbn files here ... so i could compare against those i have.
and well, if you are still S-ON _and_ the OTA-2014 is already applied then you are "out of luck" ... at least for the next couple of weeks or even months. no S-OFF method known for OTA-2014 applied fireballs!
I suspect it got that way because I used DirtyRacun S-OFF, then went to flash the OTA update. I suspect DR modifies hboot or one of the sbl's, and when I flashed the OTA it might have put me back S-ON.
Click to expand...
Click to collapse
afaik: DR "only" uses security holes in the firmware from 2.17.605.2 (from regular ICS4.0.4 RUU) to remove S-ON/write S-OFF flag ... and then add the engineering hboot of fireball (albeit modified) ... in the general section, several users with S-OFF (before the OTA-2014!) applied now the firmware from the OTA-2014 separately and confirmed that S-OFF stayed even after the OTA and since it doesn't include any new hboot, they still have their previous one
likewise, there are different qhsusb_dload modes, depending on WHEN they kicked in... in the sense of which stage fails (attaching your qdload-fireball to a linux system, there are at least 2 distinct possibilities: a) only qdload-mode or b) qdload-mode AND enumerating partitions ... the latter one is fairly easy to cure whereas the former (like mine) is much harder to come by unfortunately >_<
The DR website has an RUU.zip that has images of all the sbl's and an hboot, so working images isn't a problem, but getting them on there is.
Click to expand...
Click to collapse
they have a RUU.zip (for 2.17.605.2) and it has the firmware bit isolated and included, but that _won't help you at all_ with a bricked phone as you need a predefined partition-layout and -structure files _and_ then manage to get your brick to accept and all load those start-up settings at once. the RUU has only the files, but _not_ their structure!
i managed to already recreate most of the partition-structure of a fireball with the help from some other xda-members, but _still_ that wasn't enough for those software-tools i tried!! maybe my MPRG8960.hex isn't correct (193.692byte / md5sum: 2534fd61ebc7c8bdd9fe0dbb90c77fb0) ... i decided to buy another 2nd-hand fireball (hopefully it should still come W/O the OTA-2014 ) ... to create/dump what is on there to resurrect my bricked fireball, yet even that is still unclear if it will work. (need to wait a few more weeks until the other fireball arrives here: intl shipping & customs take quite a while unfortunately)
kimba.
first thanks for your help with the ota foirmare in theother tread. second HOW CAN I HELP YOU.
although I am on cm11 and have the firmware updated I think that is where you want to get to.
i am reasonable good with unix and adb with directions I am sure I can get anything you need off of my phone. let me know.
kimba99 said:
if you don't mind: plz attach your MPRG8960.hex and 8960_msimage.mbn files here ... so i could compare against those i have.
likewise, there are different qhsusb_dload modes, depending on WHEN they kicked in... in the sense of which stage fails (attaching your qdload-fireball to a linux system, there are at least 2 distinct possibilities: a) only qdload-mode or b) qdload-mode AND enumerating partitions ... the latter one is fairly easy to cure whereas the former (like mine) is much harder to come by unfortunately >_<
[/i]
Click to expand...
Click to collapse
Attached as tar.gz, looks like from your size/md5sums that my MPRG8960.hex is the same.
Mine has only one device (qcserial) showing up in lsusb, which means it's not enumerating partitions, right? Which if I'm still S-OFF means one of the SBLs is scrod, right?
mutterc said:
Attached as tar.gz, looks like from your size/md5sums that my MPRG8960.hex is the same.
Mine has only one device (qcserial) showing up in lsusb, which means it's not enumerating partitions, right? Which if I'm still S-OFF means one of the SBLs is scrod, right?
Click to expand...
Click to collapse
don't just check lsusb ... try the output of
Code:
dmesg | tail
BEFORE ... you attach the bricked fireball to your linux system & then right after attaching (about 10sec later or so should be enough) check again with the SAME
Code:
dmesg | tail
if it only attaches a "qualcomm usb-2-serial device on tty*" then you're in bad luck (as me) currently ... but if dmesg shows and lists some new "/dev/sdb1 /dev/sdb2 /dev/sdb3" devices and so on ... you can fairly easy fix it (at least as _now_ we/i had extracted or better said reconstructed the partition-layout and thereby we could flash any borked or unmatching partition directly).
as for S-OFF, that _should_ have nothing to do with the reason for the brick as there are already fellows here with properly updated OTA2014 firmware _working_ with properly retained S-OFF ... and secondly, it doesn't have to be one of your SBL2*'s as it could also be TZ or RPM not matching one another (as far as I understood the SecureBoot3.0-chain) ... so it depends WHICH file you (tried to) flash (and how) that leaded to your brick.
EDIT: as for your attached MSM8960-files ... identical to mine and thereby unfortunately NOT working (afaik) for recovery of a fireball T_T
any improvements on this problem? I'm having the same problem with my phone so please let me know if you find a way to fix this problem....
bought another Dinc4G ... in replacement for my bricked one. in my trail to revive my bricked one (and/or having another Dinc4g at least to use regularly with a ROM of my choice again)
after requested, the seller _confirmed_ that the 2014-OTA has __not__ yet been applied and the phone still runs fine on 2.17.605.2 ... and "guess what" i received yesterday in my mail:
his Dinc4G _WITH_ the 2014-OTA applied & of course it's stock/locked/s-on!!! DAMN IT!!!
kimba99 said:
bought another Dinc4G ... in replacement for my bricked one. in my trail to revive my bricked one (and/or having another Dinc4g at least to use regularly with a ROM of my choice again)
after requested, the seller _confirmed_ that the 2014-OTA has __not__ yet been applied and the phone still runs fine on 2.17.605.2 ... and "guess what" i received yesterday in my mail:
his Dinc4G _WITH_ the 2014-OTA applied & of course it's stock/locked/s-on!!! DAMN IT!!!
Click to expand...
Click to collapse
That sucks. Having this phone unrooted with the 2014 update is a little like being Sandra Bullock in the film Gravity. I sure hope there's someone smarter than me working on root for this thing with the 2014 update.
not many users (or even devs!) left on our Dinc4G .... pretty unfortunate
i mean temp-root still work's (apparently) on the 2014-OTA ... and the hboot didn't change at all (it's still 1.15) ... i assume one needs to find a way to perm-root the new 2.19.605.2 stock-rom first & from there try the same (or at least similar) "s-off" attack to the 1.15-hboot as previously. it's just that the devs of the prev s-off methods don't tell WHERE or HOW they obtained write-permission to set the s-off flag
still: i managed to trigger the "tampered"-flag above my "*locked*"-flag ... *lol*
kimba99 said:
bought another Dinc4G ... in replacement for my bricked one. in my trail to revive my bricked one (and/or having another Dinc4g at least to use regularly with a ROM of my choice again)
after requested, the seller _confirmed_ that the 2014-OTA has __not__ yet been applied and the phone still runs fine on 2.17.605.2 ... and "guess what" i received yesterday in my mail:
his Dinc4G _WITH_ the 2014-OTA applied & of course it's stock/locked/s-on!!! DAMN IT!!!
Click to expand...
Click to collapse
With the news of the new s-off method for the latest OTA, I was wondering if you were able to fix your phone. Looks like the answer is no, buuuut, you now have s-off with the latest OTA! :good: !
junkmail9 said:
With the news of the new s-off method for the latest OTA, I was wondering if you were able to fix your phone. Looks like the answer is no, buuuut, you now have s-off with the latest OTA! :good: !
Click to expand...
Click to collapse
unfortunately not (yet?) ... but at least, i'm near exactly where i was left on the new phone! real incredible that i could restore my nandroid from the borked phone directly to the new one (okay, after i figured out i need to rename the TWRP-backup folder to match ne new ADB-ID of the phone ... only missing a bunch of photos, that i didn't backup prior to the brick.
i'll try again later, but the brick still doesn't accept to be flashed either way by QPST as it says it is missing "its magical token" (whatever that means, but there are several posts about that specific QPST issue with qhsusb_dload bricked phones here on xda)
finally solved ... but that SURE wasn't for the faint hearted => poor fireball had to strip completely (disassambled) ... JTAG pins are ___under___ the IMEI-battery sticker even (so that had to be removed as well) ... before the "solder party" could begin.
and then thanks to _huzein_ from "gsm-europe" (who provided the RIFF-box and soldering for some smaller money) ... and the famous _legija_ ... the developer of the RIFF-box himself! (who guided us and reflashed my brick via a remote RIFF-session) ... flashing a bricked "HTC fireball" via JTAG for the very FIRST time!! we used the dump from jsmiley13 (so thanks to him again for providing me with the dump) ... after that we needed to reflash the ENG-HBOOT (via RIFF JTAG interface again) though as it had the 1.15.1111 but showed S-OFF _locked_ ?!
now it's back alive ... after 2hrs of remote debugging, remote-flashing etc ... hopefully now, legija can implement a NEW ressurrector.dll for fireball (for the 1ST TIME) and add it as a by now newly supported device on his RIFF-box!
attached below is a small "photo-story" ... for those who are interested *lol* ... and NO it's not an optical illusion, the panels definitely appear to have some slightly different color-hue (esp the green looks not the same)
kimba99 said:
finally solved ... but that SURE wasn't for the faint hearted => poor fireball had to strip completely (disassambled) ... JTAG pins are ___under___ the IMEI-battery sticker even (so that had to be removed as well) ... before the "solder party" could begin.
and then thanks to _huzein_ from "gsm-europe" (who provided the RIFF-box and soldering for some smaller money) ... and the famous _legija_ ... the developer of the RIFF-box himself! (who guided us and reflashed my brick via a remote RIFF-session) ... flashing a bricked "HTC fireball" via JTAG for the very FIRST time!! we used the dump from jsmiley13 (so thanks to him again for providing me with the dump) ... after that we needed to reflash the ENG-HBOOT (via RIFF JTAG interface again) though as it had the 1.15.1111 but showed S-OFF _locked_ ?!
now it's back alive ... after 2hrs of remote debugging, remote-flashing etc ... hopefully now, legija can implement a NEW ressurrector.dll for fireball (for the 1ST TIME) and add it as a by now newly supported device on his RIFF-box!
attached below is a small "photo-story" ... for those who are interested *lol* ... and NO it's not an optical illusion, the panels definitely appear to have some slightly different color-hue (esp the green looks not the same)
Click to expand...
Click to collapse
Looks like I am also having the same issue. Did an exchange remote wipe and came back to my phone completely bricked, Q Download mode. I am guessing the only way is to JTAG the device? Is there any other possibilities? I have qpst, and hpst etc. What is the hex and mbn image used for?
freemenot said:
Looks like I am also having the same issue. Did an exchange remote wipe and came back to my phone completely bricked, Q Download mode. I am guessing the only way is to JTAG the device? Is there any other possibilities? I have qpst, and hpst etc. What is the hex and mbn image used for?
Click to expand...
Click to collapse
depends on HOW your fireball was bricked ... but plain QPST or similar won't help as our CPU, the MSM8960, is toooo new and the unsigned usb-loader (like QPST) won't work ... at least if it's a firmware brick!!! (as legija explained to me)
only JTAG'ing via RIFF-box would help here, _but_ official support from RIFF is _NOT yet_ given (today using my brick was his trail run for "fireball") ... it should be implemented within the next days or a few weeks maybe.
Congrats on getting it back alive!
That is some impressive major surgery. Wow!
impressive!!!
great info!
i wonder how many brave souls will ever try this. a new phone for $200 might be the easier route for most people.