[DEBUG] Calling all (AT&T) 0x1000 'hard' bricks!
It is clear from many users now that the 2.3.4 / 4.5.91 OTA burns a fuse, specifically in ReservedOdm
, 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:
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 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:
Broken down (Odm as short for ReservedOdm):
Odm | Odm | Odm | Odm
00010000 | 00000001 | 00010001 | 00004000
We don't really understand Odm, but it likely gets burned by flashing an .sbf or some other process, not everyone has a 1 there. You don't see Odm through  because leading zeros are dropped from the printf output. Also, some people (pre-first-sbf?) seem to have 00000001 not 00010001 in Odm.
Why discuss unlocking? Because although downgrade bricking is not directly related to unlocking, in the end it is caused by another fuse, in ReservedOdm.
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 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, (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 should have been 0x????0001
(binary 0001 for last 4 bits) but we got 0x????0003
(last 4 bits, binary 001
1) 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 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 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 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
it lets you enter fastboot and 'oem unlock.' Then, in the future, even if it notices this 'bad' fuse is burned in Odm, because you have the Unlocked fuse burned in Odm 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.
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
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)