Hi,
i found some pins on my mobile phone that mostlikely will be some jtag pins
(since i found serial already).
Now hard part is to find what pin is jtag and what not.
I am not seem to be able to find information how i can eliminate pins.
Does anyone of you have any tips or howto´s?
ps desoldering mt fpga cpu is not an option
thanks!
No-one?
Common guys (&girls) !
I remember it here as the forum to get such help or information!
I am sure plenty of you guys should have experiences with jtag´ing
mobile devices!
Maybe i did not post enough information;
it has an arm s3c6410 (pins are hidden under the fpga),
so i know it has jtag and serial debug (witch i found).
My device has +-22 pins around the simholder that are reachable and show some reading while testing voltages , a few of them should be jtag since there are no other testpins on the pcb..
So if any of you could point me to a howto or
explains how to find some important pin(s) i think i can manage it.
Flashed LEOIMG.nbh from RUU_Leo_HTC_WWE_1.43.405.1_Radio_Signed_15.26.50.07U_2.04.50_22_2_Ship trying to unbrick my HTC HD2
Now when I turn it on, I get no screen, no bootloader, etc.
USB does work, appears as "Qualcomm CDMA Technologies MSM"
I found some drivers and installed it as "Qualcomm Diagnostics Interface 3197"
I have an idea to fix this..
I extracted the SPL.nb from T-Mobile_HD2_MR_Software_2.13.531.1
if I or someone can find the right Application to flash the HD2 via the "Interface 3197"
Maybe a variation of QDLTool (The HD2 shows up as ready to flash but the images are for the Streak)
Any help is very much appreciated..
I have two HD2's, one functional and one not, ready to work hand and hand with someone via IM (Ex: GTalk or AIM) to find a solution to this problem!
Does anyone have any ideas? Please help.. Don't want a $500 paper weight
brandonsisco said:
Does anyone have any ideas? Please help.. Don't want a $500 paper weight
Click to expand...
Click to collapse
Sorry man but the only way to reserect a bricked HD2 is by using a JTAG and a RIFF BOX. Do a little scimming over the thread titles in this forum. You will find plenty of threads that descuss this and some of them have post by members that offer to fix a bricked HD2 as they have the JTAG and RIFF BOX. You can also check and see ic there is a cell pbone repair shop in your area, they are more and more of these poppieg up now, heck there is one in my area now. Either finding a member here or a repair shop is probably going to be your best option cause it is going to cost you well over $200 USD to get the JTAV and RIFF BOX. A member here or repair shop will only charge you a small fraction off that price. Also the procedure you have to do to reserect your HD2 recuires you to partially desassemble your pbone and this is not for just anybody.
I read your post yesterday .utility was hesatant in posting as I wanted to see if someone might had another idea to put with yours and the both of you come up with a way to do what is said to be impssible. Wich is reserecting a bricked HD2 by just using the mini USB port to run the needed software on it to be able to reinstall a ROM. But it seems that no one has any ideas to put with yours sorry man.
I have looked through the forum and I found other guys trying to fix it without disassembling.. If I have access to the qualcomm chip and it appears in qdltool, why can't we just reprogram it via usb?
brandonsisco said:
I have looked through the forum and I found other guys trying to fix it without disassembling.. If I have access to the qualcomm chip and it appears in qdltool, why can't we just reprogram it via usb?
Click to expand...
Click to collapse
To be completely honest with you I really don't know the technical answer to your question as I have hardly any knowledge of the inner workings of the HD2 hardware. But from what I can best come up with is when a HD2 gets bricked it does something to prevent comunication between the CPU (Qualcomm Snapdragon processor) and the NAND chip that holds the ROM software. Wich intern means that you can not gain access to the NAND chip via the USB to run whatever needed software to restore it. This is why the JTAG is needed as it can reastablish comunication between the CPU and the NAND chip. Now this is just a thought of mine and I have no data to back this up with. So I maybe way off base as to why you can not use the micro USB port to reserect a bricked HD2, like I said it is just a thought I have and nothing more.
You flashed a 51 radio to a tmous. If you manage to fix it without repair or jtag, you would be the first.
I've hit a wall in my quest to improve the Samsung Gravity Smart (SGH-T589). The kernel source that Samsung released for it doesn't quite work right (no wifi, broken touchscreen drivers). I'm trying to do something about it, but my test kernels hang before ADB is able to detect and connect to the phone.
The phone is powered by the Qualcomm MSM 7227 (S1 Snapdragon @800Mhz), which I understand is supposed to have a debug UART. How do I access it?
Reading the Google Nexus i9250 thread, I took a closer look at the system board. I've highlighted what I suspect is the JTAG header (see attachment).
However, I lack both the tools and expertise to determine if that is the header, and what the pinout is (most jtag pinouts I see pictures of online are in 2-column layout).
But, I might not need that. If I understand the discussion in the i9250 thread correctly, what I need is a combination of this miniUSB breakout kit, a 619Kohm resistor, and the FTDI Friend to use to connect the UART to my PC. I'm not quite sure where I go from there, but I expect that Windows will detect the serial port and give me something to connect to via SecureCRT or the like.
Is this correct? I'd kinda like to know before I spend any money on parts
Alternately, if anyone wants to take a crack at wiring up the JTAG port, I have a spare (broken) phone I can ship out. Screen doesn't work, but it still boots which will make it perfect for testing with!
Now, if you had bothered to SEARCH you'd have found THIS post in this thread with this picture!
I actually did come across that thread, however that particular post would not have come up in a search and you'll forgive me for missing a post in a 25-page thread However, I appreciate your help nonetheless.
Next question: I have 2 conflicting schematics for wiring an LPT JTAG cable. One shows TDO wired to pin 13, the other has it wired to pin 11. Which is correct? Or should I just try it both ways?
Try both. Shouldn't happen anything bad until you connect it to 12V or so.
I'm banging my head against a wall here, trying to figure things out but not finding clear instructions.
Is it true that, in order to perform JTAG, I need to use some kind of adapter (i.e. RiffBox), or can I connect it directly to the LPT port of my PC? If I can use my PC, what software do I use to read the debug output? I'm less concerned with recovering from hard brick than I am with getting the early debug output.
I'm thinking a hacked USB approach might be simpler and less expensive. My problem is lack of tools. If anyone else has made such a cable, could I buy it off you for a reasonable price?
Hello, i have a semi bricked Samsung Galaxy S5770 Mini/Pop/Next. It is a Qualcomm MSM7227 board. I have tryied the usb UART approach, but the only thing i can get from it is AST-POWERON, and it repeats (i think it bootloops)
I am trying to find UART on board, there are some little pads around the CPU.
Sent from my GT-I9003 using XDA
Ah my TDO is wired to pin 11. You don't need riffbox if you make a LPT JTAG adapter such as the Wiggler (low voltage variant 3.3V).
There are many softwares that can handle the wiggler, such as H-JTAG, openocd and urjtag.
I used "H-JTAG" and "NoICE for ARM" on windows. It's easy to setup H-JTAG for the wiggler and you don't have to do anything from the command line.
The msm7227 platform is multi-cpu (modem cpu, applications cpu).
With the JTAG port you saw, you can access the modem cpu, which is a ARM926ej-s.
Sent from my GT-I9003 using XDA
tanks for you
Another way, without looking for UART is just comparing what you've changed in kernel, revert it all and apply changes one by one until it stops booting again. You might also find/create some proper thread for that and ask for help. With original repo pulled from opensource.samsung and your changes applied on it commit by commit.
Rebellos said:
Another way, without looking for UART is just comparing what you've changed in kernel, revert it all and apply changes one by one until it stops booting again. You might also find/create some proper thread for that and ask for help. With original repo pulled from opensource.samsung and your changes applied on it commit by commit.
Click to expand...
Click to collapse
The issue here is that I'm trying to backport the MXT224 driver because the driver that's in the Samsung release is butchered beyond repair--the orientation is wrong, the resolution is wrong, the alignment is wrong.
My backported driver either fails to recognize the hardware (which is odd, because the init code uses the exact same kernel calls as the FUBAR driver for the I2C transfers), or locks up the boot process too early to get any useful debug output.
Anyway, I have the parts I need on order, all I need is for the orders to show up and a decent soldering iron and I should be in business.
Ah! The MXT224. I know this one pretty well, aswell as messup that Samsung does, configuring it in hundreds of different ways, with usually same result.
I think you don't need to port anything there. There's parameter table passed to MXT224 during init, that's probably only one thing you need to setup. You might want to reverse driver from some stock kernel, or adjust it experimentally, or simply request Samsung for proper parameter table.
There are many helping examples in various kernel arounds, sometimes it's called MXT224, and sometimes it's QT602240. This is in fact 100% same thing.
I'm not sure if any datasheet is publicily available. Though setup structures explaination should be enough, there it is:
https://bitbucket.org/gokhanmoral/s.../drivers/input/touchscreen/qt602240.h#cl-4848
For example flipping it would be changing "orient" byte in T9 structure. Probably all othere parameters you need to change are also in T9.
Thanks for the link. I managed to figure out the correct "orient" value by trial-and-error, but the screen alignment is screwed up. On a stock kernel, the top-left is 0,0. On a compiled kernel, top-left doesn't even register properly (none of the edges do). I've tried a few experimental things but nothing helped so far. I'll check out that link when I get home and hopefully find something useful.
You might also want to look into mach_aries.c and mach_herring.c files from I9000 and I9020 kernel sources. These shows pretty good how very similiar results can be done in pretty different set of T9 parameters.
I appreciate your input. I'm experimenting with different T9 values. I found a partial datasheet that shed a little light into some of the parameters.
I've managed to strip out the "piggy" (uncompressed vmlinux) from the stock kernel. Is there anything I can do with that to somehow find out what T9 parameters are used by the actual stock kernel (as opposed to what Samsung released)? I did some searching for kernel disassembly but didn't find anything that looked promising.
Can you upload it somewhere? I'd take a look into it.
Sure thing. I'll upload it tonight when I get home. Thanks!
Here it is, gzipped:
http://min.us/mrUKEtr7W
Thanks, one more request - could you also upload .map file generated during your kernel compilation? I don't remember what was the full name of it, AFAIR it's ~70meg textfile in kernel source root or arch/arm/bin dir. Not sure though.
Also, are sources for this kernel available on github somewhere? Downloading tarball but this will take few hours more. :\
Ty in advance.
Rebellos said:
Thanks, one more request - could you also upload .map file generated during your kernel compilation? I don't remember what was the full name of it, AFAIR it's ~70meg textfile in kernel source root or arch/arm/bin dir. Not sure though.
Also, are sources for this kernel available on github somewhere? Downloading tarball but this will take few hours more. :\
Ty in advance.
Click to expand...
Click to collapse
It's not on github at the moment. I'm just working from the kernel sources posted on opensource.samsung.com for the SGH-T589. I'll start an account tonight when I get home and upload what I have. I'll get the map file you're after uploaded too.
Hello!
I have an embedded device with an Infineon Aurix CPU, and it has what looks like "normal" 24xx/25xx (SPI?) flash memory. My flash reading clip fits on them perfectly (-: However, the numbers on it indicate that it's some unknown (to me) 27xx version of memory. Since this thing has an infineon chip, I'm kind of assuming the flash memory is some proprietary "pflash" (it was referred to as pflash at one point as well). I've tried looking at what infineon sells and while there's 24xx/25xx/29xx chips, I don't see anything with 27xx.
My question is has anyone seen flash memory chips like this? I think that they are protected against reading/writing/erasing/reflashing but would like to make sure there's not some 'simple' wiring tricks I can use to enable them to act like normal eeprom/flash chips.
Alternatively, anyone seen something that looks like flash/eeprom but is something else with a 27xx XXXX identifier on it?
Thanks in advance if anyone has any ideas