[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:

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:

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):

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)

Good thread for our bricked friends. Nice one!

Originally Posted by Ronaldo_9

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.

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:

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 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

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

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

Originally Posted by Sthony

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.

Originally Posted by kennethpenn

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:

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.

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.