yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] ezterry:
Um.. that is not a good sign [unless your serial line is flaky].. since that indicates it started flashing.. sometimes it takes a little while but usually not that long.. and has nothing to do with the JTAG speed since its in ram (openocd ought to be shutdown while that is running)

I think you needed a better connection to your battery.. hope oemsbl/htcboot was flashed or skipped entirely before it crashed.. if it is just use fastboot when you get there to re-flash the radio.. if not.. well you my be unhappy when you try to enter blue light mode again..

Is it possible the processor was halted again for some reason?

can you enter oemsbl commands (and get a reply)
[G1 Android Development] Sirfearoth:
removed the camera button, from the phone, and tried it a few times after hitting the little tiny ass button a few times between power ups
[G1 Android Development] he3r0:
Its alive!!!!!

well apparently echo on my serial line not exactly worked well... because after i connected mobo to the regular usb, adb detected a device! (i had phone completely disassembled) after attaching screen to the mobo, there i go , recovery mode, quick reset and voila fastboot!

so that is mine happy tale from debricking my G1. (DeathSPL flashed over 1.0 radio) now im looking at Cyanogenmod animated x from Android 2.2...

Thank you everybody that make this thing possible. (and im a noob, of coz i didnt have to do it, but where is fun in that?)
[G1 Android Development] ezterry:
Glad to hear all ended well

(take it you ran the simplified process.. just flash 2.x radio if you had a 1.x radio when you flashed danger, when you booted the next time it properly entered recovery at last and cleared the boot mode that made your phone a brick)
[G1 Android Development] mippen:
Finally!

This morning I got a successful flash.

Now it's time to find a rom...

Should I use 32 A or B roms?

It's a 32B device but I now have the 3.22 radio..

And a really big thank you to all of you.
[G1 Android Development] ezterry:
Glad to hear,

While the 3.x radio is installed you need ebi1 ports (sometimes called 32a roms)

Otherwise see the installing CyanogenMod section of the jtag wiki.. it has the safe fastboot instructions for returning to the 2.x radio and let you install ebi0 (32b) roms.

May be easiest to install the ebi1 port of cm5.0.8 if you want to use the phone now and use the jtag page instructions to return to ebi0 at some other point in time when you wish to change roms..

just remember never flash a radio/spl via an update.zip unless you want to repeat the jtag operation.
[G1 Android Development] he3r0:
yes, though i did tried to do everything (from wiki, including hboot and all the mww commands),

and thank you again for your input.
[G1 Android Development] ezterry:
The last I've heard on this topics was:

http://ip208-100-42-21.static.xda-developers.com/showpost.php?p=5877951&postcount=286
[G1 Android Development] gerardt:
is it bricked

how you know if your phone is bricked mine will not switch on i have no power at all going to the phone
[G1 Android Development] he3r0:
if you plug your charger to the phone does charging LED turns red?

if no -> check charger, try to connect your phone to the computer`s usb, to confirm that it is phone, not the charger. (if its phone -> FUBAR)

if it does turn red, left it till it turns green.

once you known you have charged battery, you can try to turn your phone on.

if it does turn on, but hangs on the boot screen, try one of the following:

1)turn the phone on while pressing a camera button.

2)turn the phone on while pressing a home.

if none of them give you any results -> its bricked

try the following:

Turn the phone on while pressing a track ball. -> if blue LED above the screen is on, there is hope...

again, check power source first. if it works, phone is probly FUBAR.
[G1 Android Development] drutort:
hmm i just got the g1 jtag adapter from http://www.fonefunshop.co.uk/cable_picker/94800_JTAG_Adapter_for_Google_G1_Dream.html

and im not sure if its 100% legit, as you will see in the pics, either I have no clue how to put it together or they are doing poor job and someone either messed up or all of the adapters from this place are cheap knockoffs

http://i32.tinypic.com/21mam8n.jpg

http://i28.tinypic.com/2rpw5dg.jpg

http://i30.tinypic.com/2j2ia7m.jpg

:mad:

you can compare to these pics on this site

http://www.gsm-technology.eu/index.php/en_US,details,id_pr,7183,menu_mode,categories.html

any help will be appreciated thx in advance

what im seeing is that the location/guide pins are wrong, and or too long on the other 2ndary support pcb, it seems that the location/guide pins should only be on the main pcb and not on this 2nd one as you cant mate and lock the boards

I can not do what is done in the other websites pics above, something is messed up, now i need to know how and what to do, im guessing some desoldering :rolleyes:
[G1 Android Development] scholbert:
Dream ARM9 debugger access

Hi hackers,

it's a bit sad that i seem to be the only one posting here :o

After some further experiments, i managed to get debugger access to ARM9 subsystem.

I used H-JTAG as a bridge to AXD-debugger.

All i had to do was adding the processor ID to the target ID list of H-JTAG (edit TargetInfo).

I assumed that the ARM9 inside MSM7201A is an ARM926EJ-S.

If there's anyone who knows better please post!

Anyway, afterwards i was able to connect to AXD-debugger and perform single step execution and everything else worked out very well :cool:

As you may see in the attached picture (it's just a screenshot and i had to zip it), the SPL code is mapped at 0x0 of internal memory.

So, i have to correct myself, H-JTAG is a valid tool to give access to the ARM9 core of HTC Dream.

Unfortunately this won't be the out of the box solution to recover bricked devices, i guess.

Apart from the tiny soldering points on the mainboard, deeper knowledge of all this debugging stuff maybe required to get it back from the dead.

At least some recovery code has to be put into memory and start up correctly.

It is also unknown how a total bricked device would behave, using this method.

Because of these issues, i don't think that's the way some of you are looking for!

What is recommended to make a brick recovery easier?

I think boundary scan mode would give us a better solution to reflash SPL or whatever you like.

The SJF code would be a good base to implement MSM support, i already got all parts i need to do so.

...but one thing is for sure, some soldering is required as well to use this tool ;)

Stay tuned!

scholbert
[G1 Android Development] th0br0:
Hello scholbert,

thanks for putting all this work into the project. I've been trying to revive my bricked G1 for the past 6 months :D

couldn't we at this point load up some working SPL into the ARM9 memory and boot the mobile from here on, possibly even booting into the rescue system and reflashing the Radio / SPL from there?
[G1 Android Development] scholbert:
Hi!

Yeah, basically code injection should work. Unfortunately there's not that much information about boot up sequence in detail.

Maybe it's possible to step into AMSS code (radio) and set a breakpoint somewhere. Then load a modified SPL to offset and go!

No easy task though :rolleyes:

P.S.: I'm on holiday for few days.

See ya,

scholbert
[G1 Android Development] ahijada:
I've had a bricked G1 for a couple months now. I've been following this thread from time to time and if anyone here wants a donor bricked G1 to experiment on, I've got one.

I know it sucks having a bricked G1.. if donating this brick will help you folks, then shoot me an email: akh1685@gmail.com
[G1 Android Development] Temar:
You should donate it to scholbert when he is back from his holiday. After all he does all the hard work and is the most promising guy to find a solution.
[G1 Android Development] ahijada:
Will do, thanks!
[G1 Android Development] BinaryDroid:
yea good to hear that H-JTAG is able to communicate, its what i've been learning on so far along with openocd! I've been playing around with an old router and old pda with known jtag points bricking and reflashing it, checking how data looks as it passes into the chip via logic analyzer probes( HP model FTW!) justt so i can start wrapping my head around the JTAG stuff, learning more every day. just stopped coming by hear once I killed my second G1. first was killed intentionally to trace the pins but after that mishap with my only working G1 I was kinda upset to be out of the game so to speak. i'm hoping someone can get a viable solution! I'm also still looking for a cheap mainboard bricked, liquid damaged, or whatever so long as its not crushed to buy. if anyone has one please PM me! i'd love to keep working on this!
[G1 Android Development] scholbert:
Hi,

i'm back in town.

Because BinaryDroid broke his device, it would be a good idea to donate the device to him ;)

Another thing to mention is cost of postage....

If there's some broken hardware in Europe, please let me know :rolleyes:

Regards,

scholbert
[G1 Android Development] G1Hope:
One more idea:

If we can get the booted linux kernel to give us a non-remapped dump of the memory map, we may be able to find the "blue LED" code that way. It does have a known string in it (the "invalid command" response) so we can search for it that way.

I just checked and my unit (running cyanogen) doesn't have /dev/mem, so the easy loser way to get it isn't there. Will have to hook into the kernel manually to get access to the physical memory map. Too lazy to do that now (moreover I've never tried to do that in userspace before since I've always had /dev/mem at my disposal on all the systems I've done this with).

Anyway just musing at this point.
[G1 Android Development] G1Hope:
Regarding the aforementioned idea of loading a patched SPL into memory and using that to reflash:

If we're LUCKY the developers of the SPL used PC-relative addressing throughout their code and we can just relocate the whole shebang and only change the radio code entry points.

However, given that the SPL apparently lives at 0x0, I have a sneaking suspicion that the developers might've gotten lazy and used absolute addressing in it. If this is the case, patching the SPL to be relocatable might turn into a serious chore (scanning for any and all address operands that refer to the SPL pages and replacing them with our relocated addresses). If this is the case it is probably more feasible to run the code in place and just break in the spots that it tries to jump to radio code.

In addition, it probably uses scratch space in memory and care needs to be taken to not relocate anything into the area that it tries to write to. The developers are probably sticking stuff into the top of RAM and then loading the bootloader which launches the linux kernel into the bottom, but they might be using some other arbitrary location. Somewhere in the middle of RAM is probably a safe spot to stick any hacked code.

ARM supports only 2 hardware breakpoints (vs. 4 for x86) so if there's a lot of jumps into the radio code, we'll need to have a smart breakpoint handler -- either running on the device or on the host we're debugging from. (I don't think anyone wants to sit there and manually send an instruction every time we halt execution). This may or may not be easier than patching the SPL to be relocatable, depending on how much absolute addressing the SPL uses internally.

Regarding a starting point for a JTAG-based reflash -- "blue LED" mode might be where we want to start execution since it may avoid calling the parts of the SPL that die, and then we won't have to deal with starting from a crashed SPL and whatever garbage it leaves behind in various registers, memory locations, etc.

Thanks for bearing with me and reading this folks. I realize I'm suggesting solutions more than actually implementing them, but I figure throwing out some ideas might help at least. =)

I really really hope I can resurrect my bricked Rogers Dream soon. (My T-mo G1 is happily running thankfully. XD )

If anyone can get a dump of the "blue LED" code, let me at it please so I can at least contribute a little by taking a gander at it. This is almost certainly in the IPL. Searching for "Invalid Command" (the default response in the "blue LED" mode) will probably locate the IPL's location. I'm seeing if I can find IPL images for other HTC devices -- I assume they probably have a similar codebase. I'll snurfle through one of those and see if I can find anything equivalent to what we see in "blue LED" mode.

-- EDIT --

Also in my case I think my radio flash worked and my SPL flash didn't, so I may or may not have the fastboot code in my SPL (depending on what Rogers shipped in it). For people like me who have a stock SPL, a relocatable SPL might be the only hope. =( Poo.
[G1 Android Development] :
Wow

Hey G1Hope!

These are quite impressive thoughts!

Just some simple question:

How to enter blue LED mode on a working device?

Is it reversible or will the device get bricked in this mode?

How about the message you mentioned?

Maybe i'm able to find out, where this code is located!

I started SPL disassembly some weeks ago, but i'm not finished because G1 bootcode is huge :o

The offset 0x0 of memory is from ARM9 point of view and seemed to be the SPL. Could be some mapping behind this :confused:

Please be aware that the boot up sequence on G1 (MSM7201A in general) is little different from older HTC devices.

There's no traditional IPL/SPL combination anymore.

First one after cold reset is OTP-PBL code inside the Qualcomm chip.

Next part of code involved is part of the radio ROM.

I need to gather some infos i once wrote down, please be a little patient...

... i'll be back :D

Cheers,

scholbert
[G1 Android Development] G1Hope:
Blue LED mode is entered on all devices, bricked or working, by holding the trackball button (i.e. push trackball in so it clicks), and while holding it press the power button.

The mode intializes a serial debugging interface, for which I do not have documentation for the command set (which is why having a dump of this portion of the firmware would be useful for reverse engineering). This interface stays live even on a bricked phone, although apparently a lot of functionality in this mode requires a working phone.

See this post:

r3nrut.com/?p=184

Even on a bricked phone, the command parser still works and knows to respond with "Invalid Command:". By searching for this string we should be able to find the command parser routine and (hopefully) find what sort of inbuilt functionality it might have.

I believe blue LED mode is equivalent to green LED mode on the Hero. As I understand it, in this mode the ARM9's firmware never actually gets to the point of initializing the ARM11's memory map (or running the ARM11 bootstrap, etc.). Since we're looking at the ARM9 core from the JTAG port, this would be the ideal situation for us to do a dump of the device's address space, as well as control the bootstrap routine.

Were you ever able to get at the ARM11 core? If not, it'll get more complicated as we have to do everything from the ARM9 side. Fortunately we should be able to execute the ARM11's firmware from the ARM9 core if we have to (although it might involve some ninja skillz).

Again, worst case the flash routine needs to be cribbed/reimplemented and the proper image just bruteforced in from the ARM9 core. =(

-- EDIT --

OK, I'm a grade A idiot. =) It's *ALL* in the radio.img. The whole shebang, the command interpreter, everything. I already have the dump. ^^ I just grabbed the radio.img from the HTC dev site and started groveling through it now. I suppose I should go pay for IDA Pro now =(

Looks like ARM9 starts the radio ROM (which controls more than just the RADIO, it controls the whole systems from the ground up), and then the radio rom sets up the ARM11 and fires up the SPL. My fault for not understanding this until now. Anyway just digging through it the command set for the radio ROM serial interface is INCREDIBLY extensive -- I wonder how much you can do with it? =)
[G1 Android Development] lbcoder:
I guess that my big question is what to do if it was completely blank...

Lets say for example, going to write a new radio image, blanks it, about to start writing, battery falls out. In this circumstance, there will be no blue-light mode at all since it is clearly contained within the radio image.

There is also the future moves in custom firmwares -- custom radio images, which could completely bork stuff.

Obviously, if blue-light mode is within the radio image, it can't be used for initial programming. So how is it initially programmed?

And here is another important question... where are device-specific codes stored, i.e. IMEI and radio/sim-lock? These aren't overwritten by rewriting the radio image, but must obviously be programmable (at least in the case of the radio/sim-lock), otherwise it wouldn't be possible to sim-unlock the device.
[G1 Android Development] G1Hope:
OK current working theory:

Blue LED mode (trackball + power) starts radio.img on ARM9, and does not attempt to launch SPL, so we don't have to deal with dead SPL.

*GOOD* news -- radio.img has flash routines in it, so conceivably we don't need the SPL. It's not fastboot (SPL does that feature) -- but it does appear to have the ability to r/w it.

Regarding a hosed radio.img flash -- you should still be able to flash it via code injection via JTAG. Dead radio.img is mostly a concern for a potential serial-port flash from blue LED mode (I'm really hoping this becomes a possibility so anyone can unbrick their device due to radio/SPL mismatch or SPL misflash).

IMEI, sim-lock, etc. all seems to live in places accessible from the radio firmware. It appears to have routines to deal with those things. The SPL *also* has routines to do this through the radio firmware. See this (Hero-related) thread for information on how to do it that way:

xdaforums.com/showthread.php?t=559806

The radio.img appears to be a stock Qualcomm firmware that HTC edited for their specific devices. It is not Android-specific (and in fact internally assumes that you're booting WinCE, not Linux!). Any HTC device using this processor will almost certainly use this same firmware, whether it ships with Android or WinCE/WinMobile. The radio.img has entries for a variety of hardware.

Regarding custom radio images -- we can do cool things with it, like custom splash screen, but I recommend that nobody work on this until we have a non-firmware-dependent JTAG flash solution, otherwise we'll be making a lot of bricks potentially.
[G1 Android Development] lbcoder:
Ok, so the plan here is that there are two concurrent and somewhat unrelated approaches being taken regarding unbricking the devices. Blue-light mode and JTAG. Ultimately it might be most appropriate to use JTAG for fixing borked radio, and blue-light mode for fixing borked SPL.

What do we know about the variances between the different radio firmwares? There is obviously a link between radio firmware version and compatibility with any particular SPL, but the way you talk, it is like the same radio image is used across all versions of all devices.... At what point do the radio versions differ and what do those differences actually mean?

So theoretically, we could make a universal sim-unlocker for all HTC devices by taking advantage of the radio firmware?

Again, so what differences appear between the various different versions and what do they mean?

No argument from here, which is why I asked in relation to these varying approaches to debrickifying.
[G1 Android Development] scholbert:
Hey guys,

these are very good information and thoughts about internal software parts.

Indeed we will need more information about the structure of NAND flash inside HTC Dream.

One of the most useful and less confusing part would be to collect some physical address offsets of the involved parts of code.

Whatever solution we may develop, we need to write some code snippets at certain offsets. So would be nice to get some things collected ;)

Of course we will need a proof of concept first, but i'd like to keep it little more simple.

The software package first published by r3nrut gives an idea how the JTAG setup on a virgin device is done at HTC.

They obviously use boundary scan mode to flash NAND memory. So it's the good old pin toggle method :D

Unfortunately this mode is not running stable at the moment.

I'm loosing connection to the host. Maybe it's because i did not tie PS_HOLD to VIO :o

Anyway the ID of the MSM chip changed to 0x0000000e, which is a sign that i succesfully entered another mode.

Another interesting attempt could be seen here:

http://www.omnia-repair.com/forum/topic/htc-dream-g1-jtag

Thanks goes out to kiiiiiid for pointing me at this forum entry!!

Cheers,

scholbert
[G1 Android Development] G1Hope:
Blue-light mode will also be useful for JTAG flashing I think because it lets you power on the unit with the least possible amount of stuff being executed.

What it boils down to is the ability to execute flash routines. JTAG lets us inject instructions to the CPU directly, regardless of what's running, but if we can do that via the radio firmware (or at least launch a built-in flash routine) we're also accomplishing our goal.

Without dumps of the actual execution of the problem, it's only speculation. My *guess* is that entry points (i.e. offsets) are hardcoded in the various revisions and that one is jumping into the other at the wrong location.

It could also be the radio firmware just flat out refusing to run the SPL for another reason. Booting into blue light and then telling the radio firmware to boot (there is a command for this -- I can see it, it actually has options to boot multiple SPLs!) SPL while we're seeing debug output could let us know more about what's happening.

I have a serial cable on order so I can mess with this myself.

All devices based on this processor/radio combo, possibly. The functionality is there in the code but I don't know the details of how it works.

Apparently lots of devices come stock with these features disabled (security enabled), and it takes a reflash of the firmware to enable the ability to do these things.

I'm not sure, but the internals of the radio ROM seem to be fairly generic. They are clearly using the same codebase for all the devices they have based on this CPU.

We should be able to debrick with JTAG regardless. It's just a matter of using a suitable flash routine -- worst case is finding the offsets for the flash device and injecting a purpose-built flash routine into RAM for the CPU to run.

As observed earlier, a solderless debrick of a dead-SPL device should be possible as long as there is a functioning radio ROM provided that it is not locked down. If it turns out that your brick has a locked down radio ROM, and we can't find an exploit/backdoor to get around it, you could be SOL without soldering up the JTAG interface.

This also raises the interesting possibility of flashing the radio ROM being the *first* thing we should do when rooting a device. Even if we brick the device via the SPL, if we can flash via radio rom then we are no longer truly bricked by dead SPL, provided we get that uncrippled radio rom in first.

Much more reverse engineering work is needed on this. I am waiting for my cable to arrive now. =)
[G1 Android Development] scholbert:
Hi G1Hope

Good point!

This would be the debugger method.

That's what QMAT does and most of the comercial debuggers like Lauterbach TRACE32, JTAG Technologies, XJTAG....

Solderless would be best, but i like to solder :p

Indeed this would be awesome, but reversing radio part is to much for me right now.... :o

BTW, thanks a lot for joining us G1Hope!!!

Regards,

scholbert