Is TIN FlysWatter2 a better tool for debugging the kernel driver in BBB.Can some one please post thier experience?
-Rp
Hi,
If you really want to work with Linux JTAG debugging you need to have a JTAG debugger and debugging software that is really Linux aware. There aren't many available that really support both kernel and app debugging at the same time for Linux using JTAG connectivity.
You may want to check out Peter Griffin's GDB and Linux Kernel Awareness slides from Embedded Linux Conference Europe 2015:
http://events.linuxfoundation.org/sites/events/files/slides/ELC-E%20Linux%20Awareness.pdf
If you want to save your time and do your work today I recommend paying a bit more than that and go for even for entry level Lauterbach's Power Debug debugger. Their software (Trace32) is not pretty for today's standards but has bunch of features that makes your life easier. There is slight learning curve for the tool but once that is done it gets your work done. Price is thou 4 number figure (in euros/dollars -- lower half).
If you are looking for ARM DS-5 -- it has also some features and a bit shinier user interface (in some places) but currently lacks in some features that are found in Trace32 -- perhaps biggest is co-debugging over JTAG for Kernel and Applications at the same time, next missing feature is general flexibility I suppose. This same story matches quite a lot of debugging software currently available. DS-5's system profiler is something that might be interest for some.
If you want to play around with open source alternatives -- especially then check the presentation above.
Also note that BBB has TI's Compact JTAG connector -- so get matching adapter and solder the socket.
TI has done some work with their Code Composer Studio and then there are some low cost JTAG debuggers that are compatible with the tool -- you are locked to TI's ecosystem but that might also be something to consider. It also exposes some "homemade" features of TI processors. Haven't used the tool for Linux kernel debugging but there might be someone here with experience with the tool for that purpose.
And if someone has other kind of experiences in here I would love to hear 
both OSS and commercial solutions are in interest.
Thanks,
Vesa Jääskeläinen
I completely agree with Vesa comments and I believe Lauterbach is the gold standard when it comes to Kernel Aware debugging. It is a difficult tool to learn but it is very powerful and has everything you need to get the job done. I have learned a lot just using the T32.
Several years ago, I worked with the CCSV4 developers at TI and they did manage to get a decent kernel aware debugger working, but they dropped those features in CCSV5 because they wanted to stay closer to the Eclipse base environment so that upgrades to newer Eclipse releases was easier. Their plan was to add Linux Kernel aware debugging, but later decided that there wasn’t enough interest to justify the investment. As of CCSV6, they still don’t have Linux kernel ware debugging. From what they told me, I was one of the few users who was asking for Linux Kernel aware debugging. At that time, I made the switch to Lauterbach and have never looked back.
I also use BDI2000/BDI3000 from Abatron and PEEDi from Ronetix which act as a gdbserver so any GDB compatible debug app can be used for debugging. While they do have some kernel aware debugging capabilities, they are no ware as comprehensive as Lauterbach.
Regarding FlySwatter2, you are better off purchasing a Blackhawk USB200 which cost less than $100 and it works fine with CCSV6. FlySwatter requires a lot of work on your behalf to make it work.
Regards,
John
Hi,
An experience:
I can debug the linux kernel with both openocd + TIAO/flyswatter2/… or the TI dongles like blackhawk with CCS.
Note, one very tricky thing: Recent linux kernels mess with the jtag during boot on the bbb. You need a kernel patch -just- to be able to debug:
diff arch/arm/mach-omap2/omap_hwmod_33xx_data.c
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 6b406ca…8cb0b85 100644
— a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -223,6 +223,7 @@ static struct omap_hwmod am33xx_debugss_hwmod = {
.class = &am33xx_debugss_hwmod_class,
.clkdm_name = “l3_aon_clkdm”,
.main_clk = “trace_clk_div_ck”,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),/Added this line/
.prcm = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
Well, you won’t be able to do much. For example, as you single step, the kernel can switch tasks and then you will be stepping through an unrelated thread. No way to switch back to your original thread, so you will have to set breakpoints in the source and hope to get back to your original code. Second, you cannot debug Kernel Modules because you don’t know the address of the module. There are several other limitations, but you get my point when the debugger isn’t kernel aware.
TI use to have some limited kernel awareness in CCS4, but removed that functionality in CCSV5 because they wanted to stay as close to the Eclipse releases so heavy customization was out. I know the TI CCS developers and they explained that I was one of the only developers asking for kernel awareness. Perhaps if more developers asked for this feature, they might add it back in.
Regards,
John