CONFIRMED!! BRICKS: Radio and SPL + New SAFETY theory

---

Another theory (unconfirmed, but seems logical): Safely change between ANY SPLs using recovery.
http://forum.xda-developers.com/show...8&postcount=87
The short version: You go into recovery, set it to write the new radio/hboot update.zip, then before rebooting, WIPE THE RECOVERY PARTITION. When it reboots in boot-recovery mode after updating the radio/hboot, it'll fail properly and force you into fastboot rather than ending up in limbo. This *should* be safe, even against mismatched radio/spl.


This is the (confirmed) theory regarding the relationships between the radio/hboot/recovery:

That ALL radios are compatible with ALL SPLs.
That bricks are NOT caused by radio/spl incompatibility, but by FAILURE TO BOOT RECOVERY.

I realize that that sounds bold and goes against the grain and what people think that they know.

Up until now, there have been some wild theories about bricks. One of the early ones is that there was a relation between the mainboard code and the chance of bricking -- specifically, that a mainboard labeled as "DVT" will brick whereas a mainboard labeled as "PVT" will not. This theory, though still widely believed, is FALSE. There are conclusive reports of DVT boards being successfully loaded with the deathspl. The simple fact that there are very very FEW DVT boards in the wild contributes to the lack of proof.

A second, and much more conclusive theory, is that the RADIO version affects the chances of bricking. While in general, having a 2.x or 3.x radio seems to reduce the chances of bricking, there are STILL observable instances of bricks despite this. In other threads, I have referred to the "unknown factor" that triggers this.

While I haven't been able to isolate this unknown factor, I have been able to come to a theory regarding overall radio compatibility based on the results of experimentation by forum member ezterry, who has been able to both successfully REVERSE a brick, as well as ESCAPE the current rogers firmware lockdown.

His work can be found in the following two threads:
http://forum.xda-developers.com/showthread.php?t=591048
http://forum.xda-developers.com/showthread.php?t=649431

Specifically, the results are as follows;
Observed in a BRICKED PHONE containing a 1.x radio and deathspl:
The phone was jammed into boot mode 3 -- recovery, and ignored boot-time signals to alter boot mode -- specifically, the camera button, which should, under normal circumstances, activate FASTBOOT. It appears that boot-time signals are ignored when the device is not in normal boot mode. The solution was from bluelight mode (trackball+power) to override a security lockout using jtag, and force it into fastboot using serial console. And yes, the deathspl's fastboot mode was successfully activated from a boot through a 1.x radio.

What is not clear at this moment is why a recovery boot is unsuccessful. This is the unknown factor. Under certain circumstances, I'm sure that the specific recovery image installed may not be compatible with either the radio or the spl -- this could be due to an EBI 0/1 kernel issue. Or possibly some effect of the deathspl's partition remapping. I suggest a possibility that the radio/spl *combination* may not be compatible with the recovery. In any event, the solution may be to FORCE the thing to go to FASTBOOT mode upon reboot and then using fastboot to flash known good system images. This, though not isolating the unknown factor, will make it irrelevant.

First, I suggest flashing radio and SPL using FASTBOOT ONLY.
Second, I suggest WIPING ALL PARTITIONS (obviously with the exception of radio and spl) -- this is supposed to force the device into fastboot mode, HOWEVER, it is not clear if this would work in the event that the device is already stuck in recovery-boot. It might.
THIRD, I suggest completing this step with a "fastboot reboot-bootloader".

Also note this:
Under normal circumstances, when leaving fastboot mode, the device should be configured for a NORMAL BOOT. I therefore introduce another possibility: That when using FASTBOOT to install the radio and/or SPL, you are GUARANTEED NOT TO BRICK (not guaranteed at this point since it has not been verified). A normal bootup will obviously fail, however, when rebooting from a "softbrick", it will again try normal boot mode -- which means that it WILL accept boot time signals, like the CAMERA button to enter fastboot.

Specifics on boot mode:
There are three selectable boot modes;

Normal boot,
recovery boot,
fast boot.

Normal boot mode is fine since it will accept boot time signals. Fast boot mode is fine since it will both allow you to flash anything you want as well as clear any set boot flags. It is only the RECOVERY boot mode that is dangerous. In fact, it is SO dangerous, that in my opinion, it should NOT be possible to set this flag. Recovery mode should ONLY be accessible through boot-time signalling.

So the solution to avoid bricking is in ENSURING that the device does NOT get the "recovery" boot mode flag set. The other solution is in developing (as ezterry has expressed a desire to do...) an SPL that IGNORES the boot mode 3.

I feel smarter just from reading all of that.

+1

I wish there was a thread "like" button like on fb lol nice thoery

My name is Sheldon and I support this message.

Recently bricked a G1 for the first time (And I have done many SPL/Radio flashes before on multiple G1's) and it was only during reboot into recovery after a flash that the battery got pulled by mistake causing it to brick.

Reason I support this theory is because at that moment the phone was flagged to recovery boot and did not complete this process successfully after flashing a new SPL. It was the ENG spl I was flashing too.

A+ on the write up to OP.

+1 nice theory and well written out

Not so sure about any SPL + radio combination working.

Specifically there were some really weird cases of bricks for users flashing new radio and SPL for Magic (1.76.X HBOOT, 6.35.X RADIO) on a 32B Magic. Afterwards their ROM authentication always failed for some reason.

So there are combination that actually do not work?

I have to admit, I feel cleverer after reading the whole thing

+1 for good writeup.

Originally Posted by xxmonsterx

I wish there was a thread "like" button like on fb lol nice thoery

Sorry, digression:

Can we petition for one? Seriously, I have been seeing comments on having a 'like' button over XDA since the new revamp.

I might disagree with this theory because my g1 used to run with a broken recovery image. A couple of months ago I tried to figure out what was the max size of an recovery image. A way of testing this was by flashing an image that was very large and seeing how much will be copied. So let's say the recovery image can only be up to 10 mb but instead I flashed a 70 mb image. It will get flashed but no error massage will appear. So then I rebooted and went into recovery mode. It didn't work out and got stuck on a black screen. So I rebooted, reflashed ra-recovery image, test it out, and it worked out perfectly. Sadly I didn't recovery any speific amount of size for the recovery image. If the android OS runs much like a computer, First it will check the bios, bootloader, recovery, and then load the rom, or start to run the enviroment for the android operating system. Can someone check what those the update-script say in the deathspl.

Hrm ... didn't see this thread was made

may want to check out my update.
http://forum.xda-developers.com/show...&postcount=398