Recommended JTAG for i.MX53 QSB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Recommended JTAG for i.MX53 QSB

3,294 Views
alexz
Contributor I

Please share with your experience getting OpenOCD and JTAG to work. I haven't never tried that and I need to debug kernel.  I am planning to use Eclipse / GDB / OpenOCD.

Please send a link to the module that you have purchased (any price). At the moment I am a bit confused by 20-bit JTAG port on the board.  

Would the following work for that board ? 

http://www.spectrumdigital.com/product_info.php?&products_id=251

Thanks

Labels (1)
0 Kudos
11 Replies

1,669 Views
alexz
Contributor I

That's what I thought as well and made sure those are built into the kernel. When I type lsmod in KDB - I don't see anything, meaning that there are no external modules.

Also, I set CONFIG_DEBUG_RODATA to "n", I can debug some parts of the system, but not all of the required functionality.

Also, I do not understand why some crashes interrupt into KDB, but others don't.  I would have expected the kernel to stuck in kgdb_breakpoint when the kernel crashes so that I could attach and review the state. Let me know if someone knows how to achieve this.


David H. Lynch Jr. said:

i have not used KGDB before, and really don't know anyone who has. 

But I would presume that you can not set breakpoints in loadable modules, as the debugger can not possibly know the addresses and symbols for those. You may need to make sure any driver you are trying to debug is built in and not a module. 

There are cheap widgets on eBay to adapt to a variety of different JTAG Cable arrangements. 

0 Kudos

1,669 Views
dhlii
Contributor I

i have not used KGDB before, and really don't know anyone who has. 

But I would presume that you can not set breakpoints in loadable modules, as the debugger can not possibly know the addresses and symbols for those. You may need to make sure any driver you are trying to debug is built in and not a module. 

There are cheap widgets on eBay to adapt to a variety of different JTAG Cable arrangements. 

0 Kudos

1,669 Views
alexz
Contributor I

Got the patch for KGDB working although I had to make more changes to the system (2.6.35) in order to get it recognized. Now KGDB, SYSRQ and KDB seem to work, but aren't helpful as I can't set breakpoints in the required drivers due to unknown reasons.

The JTAG I refered in the topic has no 20-pin ARM standard connector - waiting for the previous version of the same adapter to try it out

0 Kudos

1,669 Views
dhlii
Contributor I


The patch you linked looks pretty trivial. 

I am sorry you are having problems that you think need a JTAG debugger. 

BTW, JTAG debugging once Linux has switched to virtual memory is a whole nother mess. You may need an expensive JTAG.  I would not know the specifics - as I mentioned I have never found the need to use JTAG or GDB kernel debugging with Linux. 

But each of us develops differently. I have friends that live inside the debugger - though none of them do linux kernel work. 

0 Kudos

1,669 Views
alexz
Contributor I

The patch is shared here - http://www.imxdev.org/wiki/index.php?title=Mxuart_patch

I haven't tried it yet.  But, I hope that debugging using JTAG is better then using serial, and in general saves time as opposed to printk or trace_printk

I think it was shared because of the high demand for it, but it took me some time to find it !!!  Probably, this was the case when you shared something :)

BTW, no support for DYNAMIC FTRACE in 2.6.35 kernel is also a big pain in my view.

David H. Lynch Jr. said:

If you really need KGDB, ... fix the API's as I recall they are fairly simple. the whole GDB remote handler is pretty trivial, but usually all that needs implimented is RX and TX functions. 

It would be my guess that neither Free scale nor anyone else has implemented them because there is no great demand for them.  Some time ago I implimented KGDB support for a board I was supporting - I know of no one that ever used it. 

0 Kudos

1,669 Views
alexz
Contributor I

There are issues that are hard reproducible when running something on many boards. When the kernel crashes, it is hard to understand where and what happened having only the traces up to that point and no ability to look into function trace with different setting etc. is painful.

David H. Lynch Jr. said:

I am with Alan;

I have been doing BSP's drivers, etc for more than a decade. I have never used a debugger for kernel development. 

Further unless you are trying to trap very early problems. there are debugging resources in the kernel - again that I have never had to use, that will allow you do GDB kernel debugging over serial or ethernet. 

Anything that has OpenOCD support should work - given a proper cable adapter, and sufficient effort.  

But there will be significant performance differences between different JTAG's

0 Kudos

1,669 Views
dhlii
Contributor I

If you really need KGDB, ... fix the API's as I recall they are fairly simple. the whole GDB remote handler is pretty trivial, but usually all that needs implimented is RX and TX functions. 

It would be my guess that neither Free scale nor anyone else has implemented them because there is no great demand for them.  Some time ago I implimented KGDB support for a board I was supporting - I know of no one that ever used it. 

0 Kudos

1,669 Views
AlanLevy
Contributor I

Actually I also discovered that you can't use KGDB or KDB with the Freescale Linux kernel either because Freescale haven't implemented certain APIs that these tools need (at least not in kernel version 2.6.35 or earlier). I've just stuck with printk :(

0 Kudos

1,669 Views
bikenomad
Contributor III

I got KGDB/KDB working on my 2.6.38 kernel (from Freescale) on the i.mx53.

I had to patch drivers/tty/serial/imx.c to add the polling routines that are used by KDB.

Here's my patch:

https://gist.github.com/4033368

You also have to enable several kernel configuration options; see Freescale's own app note at http://cache.freescale.com/files/32bit/doc/app_note/AN4553.pdf

This does seem like a patch they should include in their kernels...

0 Kudos

1,669 Views
dhlii
Contributor I

I am with Alan;

I have been doing BSP's drivers, etc for more than a decade. I have never used a debugger for kernel development. 

Further unless you are trying to trap very early problems. there are debugging resources in the kernel - again that I have never had to use, that will allow you do GDB kernel debugging over serial or ethernet. 

Anything that has OpenOCD support should work - given a proper cable adapter, and sufficient effort.  

But there will be significant performance differences between different JTAG's

0 Kudos

1,669 Views
AlanLevy
Contributor I

I've managed to get the Macraigor mpDemon and USB2Demon to talk to the JTAG interface using Macraigor's OCD commander, but both were so slow and unstable that I gave up on them and never got to the point of integrating it with Eclipse. Given the way that the JTAG behaved I suspect that there must be a hardware problem with the interface (we definitely had the right pinout on the connector and the correct JTAG chain configuration).

For what it's worth, I've never yet found a kernel problem I couldn't solve with strategic use of printk, albeit it takes longer than if I'd been able to use a debugger.

0 Kudos