[G1 Android Development] G1Hope:
THANKS to all the great work for getting the JTAG port working! Also if it's now possible to bang the ARM and/or address space then we're almost to code injection stage.

At this point it sounds like we need a) a means of code injection, b) code to reflash the NAND.

Observations:

It's clear that code is executing before the hang at execution of SPL. (I assume SPL is running first and then uses the wrong entry point for the radio code and dies, although quite possibly vice-versa, but I doubt it, particularly since it was observed )

Ideas:

1) scholbert indicated that SPL is at 0x0. This is probably launching first. If it's NOT calling radio much (i.e. few entry points) it may be possible to halt execution at these calls (i.e. if we can set breakpoints), and inject single jump instructions to the correct entry point in the radio code. Dumping pages from a device flashed with a known radio image should let us find it easily enough. If we're REALLY lucky the SPL doesn't try to use the radio code much at all and we can just NOP when it tries to call it. With a live SPL we could then boot into the SPL-only mode (camera button + power) and flash via serial.

3) Failing both of these, we might be able to find an entry point in the SPL that we can jump directly to that goes into the flash routine and bypass all the radio bits entirely (however this might not work if there needs to be a serial initialization routine -- though we might be able to do a two-step process where we call serial init, break, jump to flash routine).

4) Injecting our own flash code should probably be the last resort (though we can probably crib it from the post-boot linux-based flash code we normally use).

5) VERY helpful would be booting the device in "blue LED" mode and watching the program counter register here to see where it lives. If we can dump THAT code we can figure out how "blue LED" mode works. We know it has a very rudimentary serial routine that accepts commands, so *something* is running. The fact that it runs at all (albeit without any known working commands on a bricked system) on a bricked unit is encouraging.

I have a very strong suspicion that "blue LED" mode is how the devices are programmed at the factory, or at bare minimum how they test/develop their low-level firmware. I imagine that, in development, they brick their devices all the time and need an easy way to fix it without having their unit torn apart. If we can find some very basic routines to do code injection from the "blue LED" mode we open up all sorts of possibilities. Those of us without the ability/time to do the physical hardware hacking will have a starting point to work on the problem. In addition, it opens up the possibility of a solderless unbrick.

Ideal process would be to boot to "blue LED" mode, and then from there jump to SPL flash routines as mentioned before.

The key to all this is to use what's already there as much as possible before reinventing the wheel and writing and injecting an entire flash routine.

Hopefully this is making sense. Unfortunately unless a "blue LED" mode solution that obviates the need for using the JTAG port is found, only the people who have the hardware setup to work on the JTAG port will be able to work on this. =(