FORUMS
Remove All Ads from XDA

SUCCESS! De-Bricking Dreams - Complete JTAG Testpoints! UPDATE! 04/07/10

59 posts
Thanks Meter: 21
 
By BinaryDroid, Member on 27th November 2009, 11:26 PM
Post Reply Email Thread
20th April 2010, 12:54 PM |#501  
Member
Thanks Meter: 3
 
More
Hey All,

Apologies for putting some more Magic info in here, I know the JTAG points have been posted for the 32A, just took some pictures of my 32B and trying to confirm theyre the same - Couple of pictures below, same thing in both just not sure which is easier to view.

The red are the ones I'm assuming are the same as the 32A hardware however the green/blue I'm not sure which is the correct point? I think it's green given the proximity to the upper side of my picture when compared to the points outlined over here http://www.omnia-repair.com/forum/to...2a-jtag-pinout

The other question I have is trying to find a 2.6vref off the magic's internals.

I haven't looked yet as I'm waiting on the parts for the serial cable etc to arrive before taking it any further.

If anyone has any further info on the Magic I'd love to know

Thanks
Attached Thumbnails
Click image for larger version

Name:	P1000035.jpg
Views:	223
Size:	94.9 KB
ID:	312834   Click image for larger version

Name:	P1000038.jpg
Views:	184
Size:	86.6 KB
ID:	312835  
 
 
20th April 2010, 01:17 PM |#502  
Senior Member
Thanks Meter: 809
 
More
Hi sigo2oo9!
Quote:
Originally Posted by sigo2oo9

I think it's green given the proximity to the upper side of my picture when compared to the points outlined over here http://www.omnia-repair.com/forum/to...2a-jtag-pinout

Think you're right, the green one seems to be the RTCK signal.
Concerning Vref...
Personally i got no Magic board, so i'wont be able to measure anything..
Good luck for your research!

scholbert
20th April 2010, 01:19 PM |#503  
ezterry's Avatar
Retired Recognized Developer
Flag Asheville, NC
Thanks Meter: 1,005
 
Donate to Me
More
Quote:
Originally Posted by sigo2oo9

The red are the ones I'm assuming are the same as the 32A hardware however the green/blue I'm not sure which is the correct point? I think it's green given the proximity to the upper side of my picture when compared to the points outlined over here

The green one.. but you don't need to hook up either the green or blue its RTCK
Quote:
Originally Posted by gymmy

im still working on debricking the Magic with serial interface, have managered to be able to write to the NVRAM with a utility so i hope (fingers crossed) that ill be able to get a NVdump from phone that is operating so i can see if there are many differences between the 2 and look at changing these.

Does anyone have one ?

G.

..I'm not sure what you are asking exactly..

If you have raw access to ram.. just try to simulate my softload of the SPL:
http://forum.xda-developers.com/show...85&postcount=6

If you have raw access to flash load a SPL+Recovery compatible with your radio

SPL starts at: 0x02400000 (block 288) [hboot.img]
Recovery starts at: 0x26c0000 (block 310) [recovery.img]

2005 SPL:
Code:
Tidus:spl ezterry$ ../fastboot-mac oem listpartition
... INFO[radio] start block=0, size=287 (36736 KB)
INFO[hboot] start block=288, size=6 (768 KB)
INFO[misc] start block=294, size=2 (256 KB)
INFO[mfg] start block=296, size=2 (256 KB)
INFO[sp1] start block=298, size=6 (768 KB)
INFO[misc2] start block=304, size=3 (384 KB)
INFO[mfg2] start block=307, size=3 (384 KB)
INFO[recovery] start block=310, size=40 (5120 KB)
INFO[boot] start block=350, size=20 (2560 KB)
INFO[system] start block=370, size=720 (92160 KB)
INFO[cache] start block=1090, size=240 (30720 KB)
INFO[userdata] start block=1330, size=718 (91904 KB)
INFO[cpld] start block=0, size=0 (0 KB)
INFO[microp] start block=0, size=0 (0 KB)
OKAY
20th April 2010, 10:56 PM |#504  
Member
Thanks Meter: 0
 
More
Hi ezTerry,

No i dont have direct access to memory yet, but i think there may be a way to turn S-ON to S-OFF from settings that are stored in NV-ram.

What i want to do is get a identical dump from a 32b S-OFF and compare the 2 .

There is a tool in the qsrp bin directory called RF_nvdump (i cant check this at the moment as im at work) when you run this u can get a dump of the RF NV settings. and there is also another tool which allows to dump the entire NVram which has a few security settings in, Issue is , is that to write to NVram it normally tries to restart the phone in download mode (which doesnt work as its in ARM11 Mode3) and fails But... RF NVdump can write to the phone when in AT Command mode which is great.

Hope this makes a little sense

G.
20th April 2010, 11:19 PM |#505  
ezterry's Avatar
Retired Recognized Developer
Flag Asheville, NC
Thanks Meter: 1,005
 
Donate to Me
More
Quote:
Originally Posted by gymmy

Hi ezTerry,

No i dont have direct access to memory yet, but i think there may be a way to turn S-ON to S-OFF from settings that are stored in NV-ram.

We don't know any one with a true S-OFF phone.. but I'm fairly sure that is a configuration in flash but I wish you luck.

The Eng SPL and either are hard coded to have S-OFF regardless of the radio/phone security flag; or have a fastboot option in the case of the Nexus and some Magic SPLs to override (but presumably not change) the radio/phone security flag [which is likely saved in MISC next to the boot mode]

I won't say there is no exploit on the AMSS command line that we can't exploit.. we just don't know it yet so its no simple task [I have a long list of things that if 1 byte was different we could use but no way of setting said bytes]
20th April 2010, 11:28 PM |#506  
jcarrz1's Avatar
Retired Recognized Developer
Thanks Meter: 1,437
 
More
Are these methods working reliably enough that any given g1 could be un-bricked? With enough knowledge of course.
21st April 2010, 01:15 AM |#507  
ezterry's Avatar
Retired Recognized Developer
Flag Asheville, NC
Thanks Meter: 1,005
 
Donate to Me
More
Quote:
Originally Posted by jcarrz1

Are these methods working reliably enough that any given g1 could be un-bricked? With enough knowledge of course.

any current g1/dream where blue light mode still works yes.. there may be some poking on the software side to make it succeed but it ought to work.

The trick I mention here ought to even help make the various software stacks behave the same at least until you get booted again; then you can flash your system of choice as usual.

In theory we may be able to restore some G1s where the blue light mode is not functional but this requires some more software to operate (the ORT solution already has such software.. but we have not found the time)

This is assuming of course you are not looking for a support agreement.. if you want that you will need to check out other G1 jtag solutions.
21st April 2010, 05:58 AM |#508  
Member
Thanks Meter: 0
 
More
Yeah i agree with you over the one byte toggle, just nop out the jump or call and it would be all sweet but alas i cant get access to ram without jtag at the moment..

You by chance dont know the format of the radata command do u ? i know this works on S-ON along with a few others, and S-ON i dont think is HARD coded, but is more a switch as the radio images still contain the other S-OFF commands so im sure there is some way to toggle this ...

So pretty much im working on turning S-ON to S-OFF and then going from there as soon as i get sick of it ill donate the phone to the jtag efforts, but i would be surprised if there isnt a serial solution.



Quote:
Originally Posted by ezterry

We don't know any one with a true S-OFF phone.. but I'm fairly sure that is a configuration in flash but I wish you luck.

The Eng SPL and either are hard coded to have S-OFF regardless of the radio/phone security flag; or have a fastboot option in the case of the Nexus and some Magic SPLs to override (but presumably not change) the radio/phone security flag [which is likely saved in MISC next to the boot mode]

I won't say there is no exploit on the AMSS command line that we can't exploit.. we just don't know it yet so its no simple task [I have a long list of things that if 1 byte was different we could use but no way of setting said bytes]

21st April 2010, 12:16 PM |#509  
ezterry's Avatar
Retired Recognized Developer
Flag Asheville, NC
Thanks Meter: 1,005
 
Donate to Me
More
Quote:
Originally Posted by gymmy

You by chance dont know the format of the radata command do u ?

yes..

radata [start address of radio.img in physical memory] [length of radio.img]
it validates radio.img's checksums and signatures.. well unless we poke another word in memory..

Its validations will trigger a memory read from the address specified which in turn triggers an exception handler for a memory read.. in older versions [pre-android phones] entered DLMODE to upload info to the phone and change bits in memory.. this also seems blocked to us..
22nd April 2010, 04:38 AM |#510  
Member
Thanks Meter: 0
 
More
Cool another SUCCESS magic 32a debricked using jtag
Hi all,
finally I was able to debrick my magic 32A using jtag and ezterry's method

so here is a detailed list of what I did:
  1. with a needle i carefully removed some glue on jtag pins
  2. I soldered the wires to the board according to the site posted some time ago by 3izz (http://www.omnia-repair.com/forum/to...2a-jtag-pinout)
    Since I used Olimex ARM-USB-OCD which works by default to 6MHz I didn't attached the rtck pin. Pins are really closed one to another and I had some problems loosing also a little capacitors near TDO (I'm not a solder freak)
    I've used the LM317 voltage regulator scheme posted by ezterry (http://i43.tinypic.com/124k7sk.png) and a usb cable to grab 5v to obtain vref=2.6V
  3. Installed on my ubuntu 9.10 openOCD 0.4.0 with libftdi support enabled
  4. Attached the serial cable and entered blue light mode (trackball+power)
  5. Now to let openocd to detect target I had to connect also the serial +5v voltage, if not I had a "FAILED: all ones" error by openocd. After openocd started i removed the +5v connection because with it attached I can't write to serial console (maybe is only a problem of mine and not general)
    So I connected with two terminals to serial console and to openocd via telnet
.

then the list of commands I used to restore spl+recovery. On my phone there was installed the radio version 3.22.20.17 so this offset works with this radio for sure, for other radio versions see ezterry posts

in openocd:
Code:
[email protected]:~/workspace/Prova$ telnet 127.0.0.1 4444
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Open On-Chip Debugger
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x0090d1fc
MMU: disabled, D-Cache: disabled, I-Cache: disabled

>mww 0x9038f0 0xea000013
> bp 0x902b30 0x4
breakpoint set at 0x00902b30
> resume
mww 0x9038f0 0xea000013 is to bypass CID restriction and gain access to other oeamsbl commands

bp 0x902b30 0x4 sets a breakpoint to cego command in oemsbl

then in serial console ( typing "?" now returned a list of supported commands)
typed cego to load and start spl manually

again in openocd
Code:

target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00902b30
MMU: disabled, D-Cache: disabled, I-Cache: disabled

> rbp 0x902b30
> mww 0x00000c0c 0x98000c4c
> resume
rbp 0x902b30 remove bp setted before
mww 0x00000c0c 0x98000c4c force spl to enter fastboot mode. This commands work only for some spl like 2005SPL, for others the offset table could change as saied before by ezterry.

Then I disconnected serial and connected usb, the screen showed fastboot message so I used fastboot to flash spl 1.33.2009e (compatible with my radio) and recovery recovery-RA-sapphire-v1.6.2H

The method used by ezterry to load via jtag a new spl at 0x0 didn't worked for me. After cego resume the screen was still black and the phone was still in oemsbl (I was able to type other commands)

That's all
I post some pictures like wires and final results


Cheers,
bart99
Attached Thumbnails
Click image for larger version

Name:	DSC01335.jpg
Views:	2356
Size:	33.7 KB
ID:	313820   Click image for larger version

Name:	DSC01342.jpg
Views:	2504
Size:	49.1 KB
ID:	313821   Click image for larger version

Name:	DSC01348.jpg
Views:	4906
Size:	40.9 KB
ID:	313822   Click image for larger version

Name:	hboot.jpg
Views:	1986
Size:	19.2 KB
ID:	313823  
22nd April 2010, 04:49 AM |#511  
Member
Thanks Meter: 0
 
More
great work mate !

I see that spark fun are doing jtag arm devices for about 50$USD so might grab one of them and sort it out on my phone also.

Anyhow great work, i really should sort out my 32b, but i bought a nexus1 in the mean time.

G
Post Reply Subscribe to Thread

Tags
jtag

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

Advanced Search
Display Modes