Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,741,628 Members 40,247 Now Online
XDA Developers Android and Mobile Development Forum

[DEBUG] Calling all (AT&T) 0x1000 'hard' bricks!

Tip us?
 
eval-
Old
(Last edited by eval-; 25th July 2011 at 12:22 AM.)
#1  
Retired Recognized Developer - OP
Thanks Meter 331
Posts: 227
Join Date: Sep 2008
Arrow [DEBUG] Calling all (AT&T) 0x1000 'hard' bricks!

UPDATE

It is clear from many users now that the 2.3.4 / 4.5.91 OTA burns a fuse, specifically in ReservedOdm[1], which switched from:
Code:
Select Code
old:  0000 0000 0000 0001 0000 0000 0000 0001
new:  0000 0000 0000 0001 0000 0000 0000 0011
So, if you see something in /sys/firmware/fuse/ReservedOdm like:
Code:
Select Code
10000000000010001000300004000
You *should not* SBF to anything except PUDDING or an SBF with PUDDING, or AT&T 4.5.91.
Any official motorola .sbf, EXCEPT 4.5.91, will leave you in hard-brick nvflash land
...

(I will make a new post and call for more data for Chinese 0x1000 errors)


Here is an AT&T specific putative explination for their 0x1000 issues:

Our phones have a fuse, a set of one-time-programmable bits, called 'ReservedOdm' (reserved for the original design manufacturer, Motorola.) Using a fuse in this set, the unreleased 2.3.3 bootloader implemented 'fastboot oem unlock' which burns a bit in ReservedOdm[0] and sets these 32 bits (represented as 8 hex values) to 0x00004000. There are 8 ReservedOdm[] 32bit values, or 8x32 (256) fuses. Once one is burned (set to 1) it cannot be un-burned. Hence, a 'fuse'.

You can view the state of your ReservedOdm by looking at /sys/firmware/fuse/ReservedOdm, if you are root. Mine looks like this:
10000000000010001000100004000
(before unlock:
10000000000010001000100000000)

Broken down (Odm as short for ReservedOdm):
Code:
Select Code
Odm[3]   | Odm[2]   | Odm[1]   | Odm[0]
00010000 | 00000001 | 00010001 | 00004000
We don't really understand Odm[3], but it likely gets burned by flashing an .sbf or some other process, not everyone has a 1 there. You don't see Odm[7] through [4] because leading zeros are dropped from the printf output. Also, some people (pre-first-sbf?) seem to have 00000001 not 00010001 in Odm[1].

Why discuss unlocking? Because although downgrade bricking is not directly related to unlocking, in the end it is caused by another fuse, in ReservedOdm[1].

Talented dev nothize has disassembled bootloaders and determined that AT&T 1.8.3 and earlier, and most chinese bootloaders, expect that only the last bit of Odm[1] is 1. By burning the next-to-last bit, Moto broke ability to downgrade.

Basically, SVF:105:1:2 means, at lower word (16bits) of Odm[1], (called "105" dunno why) we expect the first '1' to be in position '1' but we found it at position '2', barf. Ie, for AT&T bricking case, we wanted Odm[1] should have been 0x????0001 (binary 0001 for last 4 bits) but we got 0x????0003 (last 4 bits, binary 0011) instead. By barf I mean drop to nvflash mode which only motorola service can use, since only they have our 'secure boot key' which nvflash requires. Thus, the hard brick when certain (older and/or chinese) bootloaders find this unexpected fuse burned.

Now although 4.5.91 OTA & sbf burn a fuse, you only brick if you run a bootloader that expects it not to be burned (ie, stock 1.8.3 or below.) Similarly, you can burn the Odm[0] fuse to get 0x00004000, but it won't do you any good unless your bootloader cares. So far there is one bootloader which cares, from 2.3.3, 4.5.47 (unreleased build) and lets you 'oem unlock', burning that Odm[0] fuse, and if it's burned, lets you fastboot, skips signature checks, etc.

If you run any other bootloader besides 'Pudding', it doesn't matter if your fuse is burned, you're 'effectively' locked (other BLs don't care to give you permissions.) But since fuse burning is irreversible, once you go back to the unlockable bootloader, it will notice you burned that fuse, and print 'Unlocked' in the corner. So although your fuse is burned, you don't get the benefits of it, unless you flash 'Pudding' (4.5.47) or an sbf with 'Pudding' in it.

Pudding/4.5.47-BL is also a special for another reason. Although it also does not like Odm[1] to be 0x00010003 (like 1.8.3/pre) and displays error 0x1000, it lets you escape. It gives you a really nice menu of options so you can flash something higher (only 4.5.91 right now) if you want to stay locked, or it lets you enter fastboot and 'oem unlock.' Then, in the future, even if it notices this 'bad' fuse is burned in Odm[1], because you have the Unlocked fuse burned in Odm[0] it gives you a pass, and boots anyway. So flashing Pudding or something+Pudding after 4.5.91 might give you a little heart attack, but in the end it should be harmless.


Preserved for posterity below (if you have a Chinese/Korean/Hong Kong Atrix please continue to post your ReservedOdm plus model, location, carrier, current build/sbf please, until I start a new thread.)


ATTENTION
The purpose of this thread is to assist currently 'hard' bricked users seeing 0x1000 on boot, and to understand why this happens. People who have un-bricked please skip to the end of the post. Talented dev nothize has disassembled some bootloaders and thinks perhaps this is a fuse check failure. Also, he has been able to glean some info from the chinese-language threads about this same error some weeks ago. It has been very hard to try to make sense of this issue after being away by combing through hundreds of posts. Let's keep this thread uncluttered.


HOW TO HELP

Everyone who has seen 0x1000:

Post a short description of how you got there, what you see (ie, do you boot loop?) For example, ATT users: Did you OTA from 1.8.3 to 4.5.40 or 4.5.91? Had you flashed 'Pudding' before OTA? Were you locked or unlocked? Did you see any messages about 'BP' during any RSD flash or OTA upgrades? If you recovered, exactly how (full Pudding+1.8.3 or just Pudding. If you were locked, did you have to unlock? etc.) INCLUDE SVF STRING (if any.) Be concise and specific.


If you managed to un-brick:

0. (Root your phone, see: here)
1. As root, cd to /sys/firmware/fuse
2. Run: "for i in * ; do echo $i `cat $i`; done"
3. Post output here, especially of "ReservedOdm" fuse
(Include: carrier, previous .sbfs & bootloaders used, if unlocked, current BL)


(The following is depreciated, probably not worth doing... 0x1000 on 1.8.3 bootloader [or older] is different to the Hong Kong/China 0x1000, and also different for users lucky enough to flash 2.3.3/Pudding after OTA)
If you are currently bricked:
[Note, this is not a fix, but we'd like to know if you can 'see' your device on your PC's USB. If you have, or can make, a factory cable this test will be more conclusive, especially if you see any sort of 'Nvflash' message]

0. (Be sure your battery is charged!!)
1. Unplug phone, remove battery, leave disconnected for at least 10s
2. Hold down the volume-up before and during battery insertion
3. Continue to hold down volume-up (never release it!) and connect to PC
(If you've held volume-up more that 30s after inserting battery, you can release)
4. Try to see your device in RSD
5. If Step #4 fails, try to see your device in linux 'lsusb' (like: "watch -n .1 lsusb" before connecting phone to PC)
6. Post your results in this thread!

(PM me if you use windows freeware lsusb or usbview. I don't run windows and can't test, but would gladly post instructions)
The Following 22 Users Say Thank You to eval- For This Useful Post: [ Click to Expand ]
 
Ronaldo_9
Old
#2  
Senior Member
Thanks Meter 103
Posts: 1,028
Join Date: May 2010
Location: London
Good thread for our bricked friends. Nice one!
HTC Desire-->Galaxy S i9000---> Moto Atrix--->Galaxy S2-->iPhone 4--->iPhone 4s--->Galaxy Nexus--->Nexus 4--->iPhone 5-->HTC One-->Nexus 5-->HTC One m8
The Following 2 Users Say Thank You to Ronaldo_9 For This Useful Post: [ Click to Expand ]
 
eval-
Old
#3  
Retired Recognized Developer - OP
Thanks Meter 331
Posts: 227
Join Date: Sep 2008
Quote:
Originally Posted by Ronaldo_9 View Post
Good thread for our bricked friends. Nice one!
This is exactly the kind of spam I do not want on this thread. If this starts to happen I will close this thread.

Please respect the big red underlined request in the first post and do not post in this thread unless you have experienced 0x1000 yourself, and have something useful to contribute.

Thanks in advance for valuing our time.
The Following 3 Users Say Thank You to eval- For This Useful Post: [ Click to Expand ]
 
kennethpenn
Old
#4  
kennethpenn's Avatar
Retired Forum Moderator / Retired Recognized Developer
Thanks Meter 3793
Posts: 2,702
Join Date: Nov 2006
Location: Washington, D.C.

 
DONATE TO ME
Six step plan is a no go for me. I tried it quite a few times with two different batteries.

One battery is low-ish on charge and it reads the following under the traditional error:
Code:
Select Code
Entering NVFlash recovery mode
Battery is too low to flash
The other battery is full. It reads the error for about three seconds and then quickly flashes the "NVFlash recovery mode" line before it turns blank. The screen just goes dark. Still, the device must be on, because it won't let me reboot without battery pull.
 
jakew02
Old
(Last edited by jakew02; 12th July 2011 at 01:43 PM.)
#5  
Recognized Developer / Recognized Contributor
Thanks Meter 2317
Posts: 2,065
Join Date: Mar 2011
Location: Philadelphia
@kenneth that's exactly what happened with me.

I have already gotten a new atrix and dumped the busted one back to AT&T (on the pretense of a battery dying while doing an OTA update.) So unfortunately I cannot help figure this out.

But for my two cents, im still a firm believer that using a factory cable to connect the phone w/o a battery to a PC holds the solution we seek.

I attempted to make my own, but at 7am after going all day at work (im in the US Marine Corps Infantry ) I was falling asleep while soldering. Im going to work on it again this weekend though.

Sent from my MB860 using XDA App
 
Sthony
Old
#6  
Junior Member
Thanks Meter 0
Posts: 9
Join Date: Mar 2011
I had the 0x1000 error yesterday morning by flashing pudding. I don't think was a hard brick due too the fact that I was able to recover.

Sent from my MB860 using XDA Premium App
 
robonoob
Old
#7  
Member
Thanks Meter 2
Posts: 40
Join Date: Jun 2010
Location: Bay Area
Same issue as jakew02, how ever I still have my bricked atrix. I will get a fully charged battery and try to get some results but I have the same symptoms as Kenneth as well as in phone starts for about 3 seconds and immediatley needs a battery pull. I'm off work in a few hours and will post results then.

Sent from my MB860 using XDA App
 
eval-
Old
(Last edited by eval-; 12th July 2011 at 04:25 PM.)
#8  
Retired Recognized Developer - OP
Thanks Meter 331
Posts: 227
Join Date: Sep 2008
Quote:
Originally Posted by Sthony View Post
I had the 0x1000 error yesterday morning by flashing pudding. I don't think was a hard brick due too the fact that I was able to recover.

Sent from my MB860 using XDA Premium App
Please guys... the more descriptive the better.

Sthony, you OTAd to 4.5.91 from 1.8.3 by putting the .zip in /sdcard and fastboot menu into Recovery? Then, you flashed Pudding and soft-bricked. How did you recover? Were you unlocked before OTA? Or you only unlocked after flashing pudding?

Can those of you who recovered please cat /sys/firmware/fuse/ReservedOdm ? (as root)

We would like to determine what prevents you all from downgrading (and maybe, possibly, get the still-bricked out of nvflash mode, but this will probably require cable + SBK). So it will help knowing exactly what versions you went FROM and TO (with OTA inbetween) and the type of 0x1000 you got (bootloop with RSD option using battery during volume-up method, VS. nvflash, VS. fastboot menu) including the SVF (usually 105:1:2) message if possible.
 
bl0wf1sh
Old
(Last edited by bl0wf1sh; 12th July 2011 at 04:46 PM.)
#9  
Senior Member
Thanks Meter 25
Posts: 236
Join Date: Feb 2011
Quote:
Originally Posted by kennethpenn View Post
Six step plan is a no go for me. I tried it quite a few times with two different batteries.

One battery is low-ish on charge and it reads the following under the traditional error:
Code:
Select Code
Entering NVFlash recovery mode
Battery is too low to flash
The other battery is full. It reads the error for about three seconds and then quickly flashes the "NVFlash recovery mode" line before it turns blank. The screen just goes dark. Still, the device must be on, because it won't let me reboot without battery pull.
Kenneth, same here.

the 6-step thing is a no go for me. It flashes the NV thing very quickly, then goes dark. At least I know what I did wrong, and quite stupidly so
- On 2.3.4 stock
- tried to push a de-odexed services.jar , deleting the services.odex (stupid in hindsight)
- pushed kenneth's boot.img and system.img (without reading that the system needs to be UNLOCKED)
- since the only thing left was RSD, tried to flash 1.2.6, which failed. BOOM. hard brick.

I only hope my stupidity helps people not make the same mistakes.

Will try to give it to a moto service center tomorrow, see if they can fix it.

*EDIT* doing the steps in the first posts without battery but plugged into wall outlet leaves the phone in "starting nvflash... battery too low to flash." If you push in the battery, and then pull out the cable, the screen stays on. Not sure if that helps anything, since I don't know how to do nvflash, and don't have the right tools to begin with.
Now on padFone Infinity *rooted* - the first phone where I do not feel like needing a ROM

Previous phones:
Motorola cd930 > Nokia 3330 > Motorola v120 > Siemens S55 > Siemens M50 (sold quickly) > Sony Ericsson K700i (broken) > Nokia 6288 > LG Viewty > Acer Liquid (broken) > HTC Nexus One (kept as secondary phone) > Motorola Atrix 4G > HTC One X
 
knigitz
Old
(Last edited by knigitz; 12th July 2011 at 04:30 PM.)
#10  
Senior Member
Thanks Meter 44
Posts: 222
Join Date: May 2010
Please fill out and use the following template when posting to this thread:

1. Before the 2.3.4 (4.5.91) OTA upgrade, did you flash a fresh install of 1.8.3 .sbf from RSD?

2. If the answer to #1 was no, what mods (if any) did you have installed at the time of your 2.3.4 (4.5.91) OTA flash (cwm, pudding, root, et cetera...), also what version of software were you on if not 1.8.3?

3. After flashing the 2.3.4 (4.5.91) OTA by putting the update.zip in the root of your /sdcard-ext/ and booting into the stock recovery, did you install any mods (cwm, pudding, root, et cetera...)?

NOTE: If you did not flash the 2.3.4 (4.5.91) OTA by putting the update.zip in the root of your /sdcard-ext/ and booting into a stock recovery, please detail what method you used to get to the 2.3.4 (4.5.91) OTA. This thread is only for users who flashed with this method.

4. Did you use RSD to flash anything else while on the 2.3.4 (4.5.91) OTA, such as pudding?

5. Did you use fastboot to flash anything else while on the 2.3.4 (4.5.91) OTA, such as cwm or preinstall root?

6. Did you then try to flash back to the stock 1.8.3 .sbf via RSD? If so, what version of RSD Lite did you use?

7. If the answer to #6 was no, what version of .sbf did you flash via RSD, also what version of RSD Lite did you use?

8. Did you encounter the 0x1000 error after trying to downgrade to a lower version .sbf?

9. Have you been able to recover from the 0x1000 error and resume normal functionality? If so, what software version are you currently on?

10. Please detail below exactly what had occurred during and after the downgrade to a lower version .sbf via from the 2.3.4 (4.5.91) OTA. If you were able to recover, please detail the steps that led up to your recovery. Also what type of 0x1000 you got (bootloop with RSD option using battery during volume-up method, VS. nvflash, VS. fastboot menu) including the SVF (usually 105:1:2) message if possible.

Also include everything required from the first post of this thread. This is very important.

If you can also provide filenames for the files you've flashed, that would be optimal.

The Following 3 Users Say Thank You to knigitz For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes