yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] jubeh:
the way i had envisioned it was IPL (radio) having a list of boot locations for SPL. Remember that SPL is the one that listens to user-input boot modes. The radios that are not compatible with the death spl were released before this spl was released (remember, it was originally the sapphire spl). Since the dream and sapphire share radio chipsets, the dream was able to use sapphire spls once a radio capable of booting it (starting with 2.22.19.26I) and had that particular spl available in it's boot list, then the spl could be booted with the appropriate parameters. Since on earlier radios the SPL hadn't been created yet, it wasn't on the list of the spls allowed to boot.

I haven't studied spl/ipl much codewise, but my findings come from theoretical analysis of spls among other htc handsets (my idea originally came from trying to figure out a hex-hack to spls that allowed them to be booted by any radio, then we could toss an android spl into a winmo device and have it boot the linux kernel).

The boot modes mentioned are spl dependent, so if the ipl can't find an spl, then the only option is to get the ipl to find the spl and boot it.

The real question would then be, how is the ipl finding the spl, and is there something we can do with spls (again, as a hex-hack) so that the appropriate value is returned to ipl when trying to boot spl and to boot that spl?

---edit---

Further (this had occurred to me before but I just remembered), keep this in mind, all dream IPLS are capable of booting all Dream SPLs, regardless of board version (not to delve into t-mo dream and rogers dream, different radio, so for this purpose, different device). I'm pretty sure too that, had there been as many IPLs/SPLs for the sapphire, the same would have been true (and we'd have more death spls to try on the dream).

What that tells me is that whatever the IPLs of all radios are reading for in SPLs, it's present across stock/eng/hard SPLs. If that thing that is being read from or booted to in those SPLs can be copied over to the Death SPL, then we'd have a death SPL that's bootable by all radios. Doesn't fix any current bricks though >.<
[G1 Android Development] lbcoder:
When you went into broken recovery, you did so using the HOME-POWER boot-time signal rather than using the forced/stuck mode. Therefore your observations don't relate to the issue at hand.
[G1 Android Development] lbcoder:
Yes. Sortof. Except that you mistake what a BIOS is. You are assuming the BIOS to be the setup program, whereas the BIOS is actually the first bootloader, at about the same level as some of the stuff in the radio image. The SPL on the phone would be roughly equivalent to GRUB.

Now as it happens, the phone's firmware actually *does* share some interesting similarities with your computer's bios -- specifically, that it *does* allow for you to flag different conditions. The problem with it is that it lacks the convenient SETUP program that your computer has... Note that it ***DOES*** have a setup program still though -- BLUE LIGHT MODE!!! Only problem is that we don't know the "password" for blue light mode! So it is like having a blank hard disk, a bios configured to boot that blank hard disk, and a PASSWORD you don't know on the bios configurations!
[G1 Android Development] lbcoder:
That is actually the same way that I *used* to envision it.

Which has now been PROVEN incorrect. Or at least not applicable to the dream-bricks.

ezterry has conducted an experiment in the jtag thread based on this theory I have presented here. What he found is that a 1.x radio ***IS*** able to boot 1.33.2005 SPL SUCCESSFULLY!!!!

In other words, this theory I have presented has been confirmed through experimentation!

We don't know if this combination is suitable for actually booting a kernel, but we DO know that when flashing this combination in a manner where the recovery-boot flag is NOT set, that we ARE able to get into fastboot mode and flash the radio image! Meaning NOT BRICKED!!!! Despite a radio/SPL combination that was previously assumed to be a GUARANTEED brick!

Keeping in mind of course, that there is still a possibility of a radio/SPL mismatch brick, what I believe at this point is that EVERY 32A/B radio image can be installed in conjunction with EVERY 32A/B SPL withOUT any kind of risk of bricking!

As long as the boot-recovery flag is NOT SET!!!!
[G1 Android Development] lbcoder:
I wouldn't consider that weirdness to actually be a brick. At least not of the same caliber as the dream bricks where it won't respond to anything. Lets call something like that -- "borked".

Reason I wouldn't want to call it bricked is that it is still responding and doing *something*, despite the fact that what it does is failing.

In this case, you cite an authentication failure... suggesting that the 1.76.X SPL is *not an engineering SPL*. Use of a non-engineering SPL, I believe, will always leave you vulnerable to signatures and authentication errors.

I also have to believe that if the 1.76.X SPL *was* an engineering SPL, then it wouldn't worry about authentication.

My first recommendation to everyone is that they ALWAYS use an engineering SPL (i.e. with UNLOCKED FASTBOOT). In fact, the FIRST thing I would recommend to ANYONE rooting their phone is that their first step be to flash a "compatible" engineering SPL -- by compatible, I mean if your stock SPL was 0.95.0000, then you first flash SPL 0.95.3000 by whatever means necessary -- if it gets jammed into boot-recovery using such a similar SPL, then it won't be a brick. Following that, one can change to ANY engineering SPL using FASTBOOT to again be guaranteed not to brick.

If there is no engineering SPL available that is similar enough to the stock SPL to guarantee that the recovery will be compatible, then all bets are off -- in that case, you could end up borked.
[G1 Android Development] lbcoder:
If you look at the top of the screen, you will find a "rate thread" tab.
[G1 Android Development] Sheldonjace:
Thank you kind sir for clearing that up for me!

I'm thrilled to hear this is confirmed to be true as well.
[G1 Android Development] r4d14n7:
Wow. Way to keep an open mind, both OP and ezterry. So any time we change radio or SPL versions you recommend doing so through fastboot instead of recovery zip flashes?
[G1 Android Development] lbcoder:
Unless you know FOR CERTAIN WITHOUT ANY DOUBT WHATSOEVER that the recovery image you currently have installed will work with the new radio or SPL that you are flashing, then ABSOLUTELY I suggest (1) sticking with fastboot, and (2) sticking with engineering SPLs (of whichever variety you prefer, be it 0.95.3000 or 1.33.2xxx).

The cases where you DO KNOW with absolute certainty that you will have no compatibility issues is when changing the SPL from a "consumer" version to ***ITS*** corresponding "engineering" version, i.e. from 0.95.0000->0.95.3000 or from 1.33.0005->1.33.2005.

You should ONLY use recovery IF you have this degree of certainty.

Note: 1) I would recommend that you ***NEVER*** write a radio image using recovery, (2) ONLY EVER update from consumer SPL to ITS corresponding engineering SPL using recovery.

If you are running (any radio) + (consumer SPL) and are ABLE to use recovery to update to (same radio) + (engineering SPL corresponding to consumer SPL), then you can be certain that it ***WILL*** work.

So the process for going from, for example, a current version tmobile firmware right through to 1.33.2005 SPL + whatever is this:

1) ROOT as normal (i.e. RC29NBH+telnet, install custom recovery image)

2) copy engineering SPL 0.95.3000 update.zip to sdcard, reboot recovery, write 0.95.3000 -- this is safe because you KNOW that the recovery is compatible/functional with 0.95.x000 since that's what you have and you are using recovery,

3) reboot in FASTBOOT mode,

4) fastboot flash the desired SPL and/or radio image.

Doing this, I personally guarantee to within 99.999999% that, barring unexpected errors, like power failure during write or other equipment failure, that this procedure will *definitely not brick* (to within 99.999999% certainty -- I leave myself 0.000001% uncertainty, so don't hold me accountable).
[G1 Android Development] st0kes:
This is the most useful thread I've seen on XDA for ages. Should be made a sticky or part of the wiki.

lbcoder thank you for taking the time to explain this.
[G1 Android Development] lbcoder:
You mean to research this. The explanation was simple once the pieces started falling into place. It was something that ezterry said that suddenly brought all the ducks into line, explaining everything -- all the oddities and loose ends that made the 1.33.2005 SPL just feel so... dirty. An experiment that I proposed to him, which he conducted, proved it. Heh, he even took a PICTURE of the boot screen showing the 1.x radio getting along happily with the 1.33.2005 SPL. :D
[G1 Android Development] Super Jamie:
Thank you SO MUCH. This is something I have suspected but have never been able to get a straight answer to.

This definitely needs to be more widely known, especially in the Magic forum where people seem to flash SPL and radio versions nilly willy then wonder why they need to change between the G and H Recoveries.

This forum needs rep, you guys deserve a million +1s.
[G1 Android Development] xaueious:
Hey it's looking like Cyanogenmod 5 for G1 will require Danger SPL.

Given the difficulty of some people using fastboot, can a update.zip with a modified update-script facilitate a safer SPL flash?

(not sure if write_raw_image PACKAGE:recovery.img RECOVERY: is valid. Should try it)

Something like:

If the update.zip contains a working radio/spl stack and a recovery image file, would this work? I'd make this myself but I don't have a jtag setup to try this on. But something like this should prevent any screwing up of flashing the stack.

This aims to format all the partitions, flashes radio, flashes SPL, and finally flashes recovery to both the recovery and boot partitions.

The other question to ask is if the hboot or the radio should be flashed first in this method.
[G1 Android Development] sturmeh:
I believe recovery can install SPL and Radio from a .zip however it goes to fastboot to do so.
[G1 Android Development] xaueious:
It can. I'm asking if these commands make sense.
[G1 Android Development] r4d14n7:
Re: CONFIRMED!! BRICK THEORY: Radio and SPL

this seems too risky to me... if you cant get fastboot to work, keep trying cause that sounds way safer.

edit: and just use firerat's script to install cyan5 if youre not comfortable with fastbooting dangerspl, i would say.

Sent from my HTC Dream G1 using the XDA mobile application powered by Tapatalk
[G1 Android Development] lbcoder:
I don't think that that's any different.

It won't write them right away, it'll boot to somewhere, write it, and then try to boot back into recovery, which may or may not work (i.e. may or may not brick).

As for "will require"... just delete some of his bloat and it'll fit just fine. I think its only off by about 4MB.
[G1 Android Development] noCOMPLY:
Hold down camera button while powering on, si?

ADP?
[G1 Android Development] themapleboy:
if you mean adb then no, fastboot is it's own script (if thats even the proper name for it) hold camera while booting> press send> start fastboot > flash radio.img

being a noob to this myself i see no difficulty in using fastboot to this end it is how i flashed my spl, radio and recovery (then again i am on a mac so it's just drag and drop into terminal :) )
[G1 Android Development] :
Amazing, lbcoder. You've never once proved to me to be a dumb one, in any shape or form.

Hey, mods, can we get the rating button to go up from 5 to 10 just for this? :P

Now time to see what this new CM is all about...
[G1 Android Development] noCOMPLY:
Actually, I meant CMD technically. Can fastboot ID the device, but flashing the hboot.img isn't working. I posted a seperate thread about it here

xdaforums.com/showthread.php?p=6344107#post6344107

if anyone can help out.
[G1 Android Development] jubeh:
For most users, removing /system/xbin should do the trick. Just toss a busybox in /system/bin (and for extra credit, add the links for the busybox tools not already provided by toolbox). It still doesn't trim all the unnecessary stuff, but it helps.

My own build (based on AOSP and my own work, not cm's github) fits Gapps, a working full AOSP build (except for video and 3D, but I just might steal them from cm, but I'd rather figure out how to fix it myself), /dalvik-cache on /cache, compcache, and even /tts (so that it doesn't have to be downloaded from market) and it fits on regular SPL.

CM is bloated, and I dare say my builds are faster, even if most people consider them to be too "vanilla".
[G1 Android Development] Afirejar:
So if I understand this correctly, flashing through fastboot allows DeathSPL on a G1 with the original stock radio without bricking the device?

I ask, because there are a small number of G1 around that won't take radio flashes due to some kind of bug.
[G1 Android Development] ezterry:
It will not brick the device if you do it that way.. but I haven't yet been able to boot the device beyond the SPL w/ the 1x radio + 2005 SPL.. been meaning to have another look on the jtaged phone.

The radio flash is also best done by fastboot as well (However note if the radio is not correctly signed it just seems to hang forever; odd as I know the radio command the SPL is calling returns an error)
[G1 Android Development] lbcoder:
fastboot has two parts:

-the firmware interface -- basically an executable program that runs on the phone.

-the binary executable that runs on our computer.

Neither is a script.

You can identify a script if you open it in a text editor -- if you can READ it and it is also executable, it is a script. If it is executable and consists of weird characters that you can't decypher, then it is a binary executable.
[G1 Android Development] themapleboy:
interesting thanks ibcoder i'm still learning, but you made it sound simple enough for a layman like me to understand :).
[G1 Android Development] lbcoder:
Everybody has their brainfart moments.

And a few free passes ;)
[G1 Android Development] Afirejar:
Thanks! :)
[G1 Android Development] ezterry:
So did an experiment (go jtaged phone go)

flashed a 2x radio update.zip followed by the danger spl update.zip without restarting in between.

The second failed because it could not save the operation. The reason for this is a flash of the SPL or RADIO is actually done via the SPL not recovery; What happens is recovery sets a special boot mode; then when you next boot the phone it flashes the image (stored in /cache)

I only tried since I have seen some odd sequencing of boot commands in the SPL before now.

It is likely possible to make an update.zip that flashes a 2x radio + a init.d script.. that then flashes danger SPL and removes its self.. but that may run into other issues..

(now since death SPL failed and the radio succeeded this did not cause a brick.. but if you flash the death SPL.. then go oh crap i need to flash a radio you are SOL.. I obviously was ready to softboot an SPL via jtag if it failed but others are less likely to be prepared for such things)
[G1 Android Development] www.cepdukkani.net:
ok this is what i all have. now i can normally boot with RC29. i can connect to Tri color screen. i have root permissions. but i cant enter recovery mode. i cant use fastboot.

any solutions for this problem ?
[G1 Android Development] CheungTiFan:
http://www.androidin.net/bbs/thread-14519-1-1.html

This post also proved that the only issue is the compatibility of recovery

一次刷机按照这里的置顶教程一步步来的。 不要说啥没有重启，。。第一部机器砖了。 第二部也是按照教程，只是把ADB 那个TESTKEY 的IMAGE 换成recovery。

That is:

The first flash is under what told in topmost post. Bricked.

The second G1 is also flashed under what told in topmost post.

The only difference is that the second G1 is using another recovery image while the first is using recovery image with "testkey" printed on.
[G1 Android Development] G1rome:
good stuff
[G1 Android Development] cal3thousand:
If you can get the 3 color screen and you have root, you can load your own recovery image. then type reboot recovery in the terminal to get there.

... is that your problem or am i missing something?
[G1 Android Development] lbcoder:
It is the whole "reboot recovery" flag that is dangerous and should NEVER be used. It is responsible for ALL -- meaning 100% of radio/spl bricks.

The ONLY SAFE WAY to enter recovery is by holding the HOME button during a normal boot. Doing this ensures that the boot-recovery flag is NOT SET.
[G1 Android Development] Brut.all:
So even if we use simple "adb reboot recovery", we risk bricking if recovery is broken? If so ClockworkMod/ROM Manager is a very, very bad idea.

Obvious solution is to clear "boot recovery" flag right after reading it. But is it possible to hack IPL/SPL to do that?
[G1 Android Development] lbcoder:
Yep.

ezterry mentioned that he might be looking into this, but I haven't heard anything about it in a while.
[G1 Android Development] toeshot:
I would that this would apply only when you are updating the SPL or the Radio. I have always reboot recovery to wipe, flash, push out .apk's, and other things and never experienced any problems.
[G1 Android Development] Brut.all:
Because if you don't touch recovery partition, then it is very unlikely that it will suddenly broke. This is the difference between theory and practice ;-)
[G1 Android Development] lbcoder:
Exactly. In theory, an electrical glitch caused by a strong magnetic field can corrupt any flash at any moment causing a total brick. That doesn't mean that it is going to happen, or even that it is particularly LIKELY to happen.

What I suggest regarding the reboot-recovery is this:

EVERY TIME you change ANY of radio, SPL, or recovery, TEST recovery using hold-home to make sure that recovery WORKS ***BEFORE*** ever setting the boot-recovery flag. If you do this, you can be reasonably certain that you will have a functioning recovery partition, which makes it *EXTREMELY* unlikely that you will get a brick by doing this.
[G1 Android Development] www.cepdukkani.net:
hi again.

adb reboot recovery opens tri-color screen

home + power opens tri-color screen too

any other ideas ?
[G1 Android Development] scholbert:
If you get tri-colour screen and your device is a HTC Dream you still got stock SPL, in other words no fastboot support with this bootloader.

Seems that your recovery image got corrupt or was deleted.

The device fails to load recovery image and falls back to bootmode.

I would recommend to read the sticky posts and the Q&A in the G1 subforum to get a better understanding of this stuff in general.

We go off-topic....

Regards,

scholbert
[G1 Android Development] www.cepdukkani.net:
dear scholbert;

i am not a noob i have another g1 works perfect. but when i want to install recovery over telnet, it has errors btw flashrec gives error too. EUI0 is my device. i have errors too.

flash_image recovery recovery.img

ERROR :

mtd: erase failure at 0x003e0000 (Input/output error)

mtd: erase failure at 0x003e0000 (Input/output error)

mtd: skipping write block at 0x003e0000
[G1 Android Development] Daneshm90:
Recovery over telnet ???? Why arent you doing

fastboot flash recovery ____________

or

fastboot boot _________________
[G1 Android Development] www.cepdukkani.net:
daneshm90:

fastboot: not found
[G1 Android Development] mrono:
So am i able to update from a 1.x SPL if i follow the instructions
[G1 Android Development] Aaron!:
How do you flash a radio via fastboot?

I tried extracting the radio.img into the /tools folder, and the following:

fastboot flash radio.img

fastboot flash radio radio.img

I'm stumped

EDIT: I went ahead and flashed the radio with the recovery.

Now, I'm trying to figure out how to flash the signed-spl via fastboot ... can't find it anywhere.
[G1 Android Development] kwanbis:
I think i found it, and post it above.
[G1 Android Development] pistolazzi:
"fastboot flash hboot hboot.img" doesn't work on some dreams, also on mine:

writing 'hboot'... FAILED (remote: partition does not exist)

My configuration:

radio: 2_22_23_02

spl: Engineering 0.95.3000

recovery: Amon_RA 1.6.2

rom: cyanogenmod 4.2.15.1

It seems that hboot partition doesn't exists...

Is there a solution?

I don't want to flash danger-spl through recovery... :-(
[G1 Android Development] lbcoder:
You think that that's more newbie friendly?

Even an experienced engineer would shudder at the insanity you typed out.

Cyanogen recommends doing something that can brick your phone. IGNORE IT ALL!!!

The above 5 steps are unrelated/irrelevant.

You are taking TWO DIFFERENT AND COMPLETELY UNRELATED THINGS AND MASHING THEM TOGETHER.

Ignore ***EVERYTHING*** you read from cyanogen.

A DREAM IS A DREAM.

NO!!!!

The above 7 steps CAN EASILY BRICK YOUR PHONE!!!

Why? Unless there is something to gain, don't even bother.

Note: Right now I'm using a cyanogen rom -- 507t5, on SPL 0.95.3000. Didn't change it because there's NO REASON to change it.

There ***IS NO DIFFERENCE BETWEEN "PVT" and "DVT"***. Ignore it. Doesn't matter in the least.

NO. The RADIO itself is NOT RESPONSIBLE for bricks.

I suggest that if you don't want to screw everything up, DON'T USE WINDOZE.

This chunk of barf is totally off the topic of this thread. This thread is about the SPL. Go find yourself a RADIO thread if you want to talk about radios.

ABSOLUTELY NOT!!!!

Your "instructions" are first off NOT YOURS -- you read them from somewhere else, SECOND, what you have written here DOES NOT write the spl using fastboot -- it writes the SPL using RECOVERY.

This is EXTREMELY DANGEROUS and should NEVER be attempted!!!!

Interesting that you suggest this line here, but nowhere else!

When you change to an SPL with an incompatible partition layout, it destroys all the data anyways.

I would always limit fastboot reboots to STANDARD reboots. You hold the HOME button to boot into recovery, you hold the CAMERA button to boot into fastboot. USE THOSE.
[G1 Android Development] pistolazzi:
Sorry for the off-topic: how to install cm5 on dream without danger-spl? Is it possible?

I've tryed to update spl with:

fastboot flash hboot hboot.img

but it doesn't work:

writing 'hboot'... FAILED (remote: partition does not exist)

lbcoder, can you help me, please?
[G1 Android Development] scholbert:
Hi!

Seems there's still a lot of confusion about the different boot modes and/or functionality of the firmware and tools.

I'm sure you are not a noob...

Anyway, flash_image is a tool used in the linux console mode of your Android system or in recovery console mode.

Fastboot is a tool running on your host computer, while the Dream device is in fastboot mode (special bootloader mode only available on the engineering booloaders).

I'm sorry, but i felt like i had to point this out again...

AFAIK, calling fastboot flash hboot hboot.img does not work with 0.95.3000 bootloader.

Though it is an engineering bootloader the flash option for this partition is blocked and/or not a valid option.

How about this procedure:

- download spl-signed.zip (HBOOT-1.33.2005)

- maybe necessary to rename it to update.zip

- flastboot update update.zip

Not sure if this will work or brick your device as well.

We need this to be confirmed by the other cracks out there.

So, please correct me if this is wrong or missleading.

If this leds to further confusion i will definitely edit this post :o.

Kind regards,

scholbert
[G1 Android Development] kwanbis:
So you are saying, instead of:

do:

Obviously i do not know the answer.
[G1 Android Development] kwanbis:
2 things to try here.

First one, if you had your G1 connected to your PC, disconnect, reboot it, and try again. That fixed it on one of the G1s.

But in another G1, i could not get it to work with cm-recovery-1.4.img OR recovery-RA-dream-v1.X.X.img, not even on FASTBOOT mode.

In the end, the solution was to flash a SMALLER (in size) recovery image.

The first image that worked, was one from JFv1.43, but it is very old and limited.

In the end, it worked with recovery-clockwork-1.8.1.4-dream.img, which is HALF the size than the others (2.6 vs 4.6).