FORUMS
Remove All Ads from XDA

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

2,649 posts
Thanks Meter: 99
 
By lbcoder, Account currently disabled on 30th March 2010, 04:59 PM
Post Reply Email Thread
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.
The Following 2 Users Say Thank You to lbcoder For This Useful Post: [ View ] Gift lbcoder Ad-Free
 
 
30th March 2010, 05:49 PM |#2  
docsparks's Avatar
Senior Member
Thanks Meter: 242
 
Donate to Me
More
I feel smarter just from reading all of that.

+1
30th March 2010, 06:08 PM |#3  
xxmonsterx's Avatar
Senior Member
Thanks Meter: 18
 
More
I wish there was a thread "like" button like on fb lol nice thoery
30th March 2010, 06:18 PM |#4  
Sheldonjace's Avatar
Senior Member
Flag Springfield, MO
Thanks Meter: 1
 
More
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.
31st March 2010, 01:33 AM |#5  
ultma75's Avatar
Senior Member
Flag Houston, Texas
Thanks Meter: 80
 
More
+1 nice theory and well written out
31st March 2010, 03:53 AM |#6  
xaueious's Avatar
Senior Member
Flag Toronto
Thanks Meter: 179
 
More
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?
31st March 2010, 04:05 AM |#7  
Senior Member
Thanks Meter: 22
 
More
I have to admit, I feel cleverer after reading the whole thing

+1 for good writeup.
31st March 2010, 04:07 AM |#8  
Senior Member
Thanks Meter: 22
 
More
Quote:
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.
31st March 2010, 06:12 AM |#9  
Senior Member
Thanks Meter: 17
 
Donate to Me
More
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.
31st March 2010, 06:32 AM |#10  
ezterry's Avatar
Retired Recognized Developer
Flag Asheville, NC
Thanks Meter: 1,005
 
Donate to Me
More
Hrm ... didn't see this thread was made

may want to check out my update.
http://forum.xda-developers.com/show...&postcount=398
31st March 2010, 06:50 AM |#11  
Sheldonjace's Avatar
Senior Member
Flag Springfield, MO
Thanks Meter: 1
 
More
Quote:
Originally Posted by mohsinkhan47

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

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

I maybe completely off but here is why I support this theory:

G1's don't have a "BIOS" to be checked upon starting that determine where or what type of boot up to perform so you can quickly change the settings by pressing F2 to say "Boot Normal Boot first, then Fastboot, then Recovery, etc" like a computer can. What the OP is stating is that when the phone is bricked, it could be due to it being "Flagged" at trying to boot into recovery and not taking ANY other boot commands....even if the Recovery Image may have been corrupted (which if it did have a BIOS like a computer it would attempt to boot the next in line option you've set if previous option failed)...so this causes the phone to be rendered useless ie: Bricked.

SOOO thats why the last part of the original post says it would be nice to develop (if possible) a SPL that would not allow this flag to be set at Boot recovery thus helping avoid possible bricks. Since if it can't flag Boot Recovery, then if the image were corrupted it would at least accept other boot signals for Normal boot and FastBoot which in turn allow you to fix said failed image.

Does any of that make sense? its late and I feel like I'm rambling.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes