[Atrix 4G Android Development] eval-:
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 00[B]0[/B]1
new: 0000 0000 0000 0001 0000 0000 0000 00[B]1[/B]1

So, if you see something in /sys/firmware/fuse/ReservedOdm like:

10000000000010001000[B][U]3[/U][/B]00004000

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)