On Monday 13 December 2010 03:27:17 Jon Masters wrote:
> On Wed, 2010-11-24 at 23:59 -0500, Jon Masters wrote:
> > Has anyone managed to get the TinCanTools Flyswatter working with the
> > XM? I did with the original Beagle, but upstream OCD does this with XM:
> >
> > [...@constitution openocd]$ sudo /usr/local/bin/openocd
> > -s /usr/local/lib/openocd
> > -f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
> > -f /usr/local/share/openocd/scripts/board/ti_beagleboard_xm.cfg
>
> The following is posted for the benefit of those using Google. It is a
> complete summary of this issue so I hope you find this mail first when
> you have the same problem and find my messages in the archives :)
>
> Antonio Borneo graciously provided me with an answer and I have finally
> had chance to followup with some testing! It works :) As Antonio notes,
> the problem is caused by some fixup logic that was added as part of some
> otherwise excellent patches from Marek Vasut. In the patch:
>
> commit 0649fb2f6c7e1bea138769ecc2ec8dc17ae98044
> Author: Marek Vasut <marek.va...@gmail.com>
> Date: Sun Oct 31 05:24:36 2010 +0100
>
> ADIv5: Introduce function to detect ROM Table location
>
> This patch adds function called "dap_detect_debug_base()", which
> should be called to get location of the ROM Table. By walking ROM
> Table, it's possible to discover the location of DAP.
>
> Sadly, some CPUs misreport this value, therefore I had to introduce
> an fixup table, which will be used in case such CPU is detected.
>
> Signed-off-by: Marek Vasut <marek.va...@gmail.com>
>
> Some logic is added to detect CPU cores that report an incorrect ARM DAP
> (Debug Access Port, exposed behind something called an ICEPick which
> sits on the JTAG chain and allows devices to come and go - I'm still
> figuring all of this out in the case of the Cortex parts). The problem
> is that the iMX51 actually *DOES* correctly report the location of its
> DAP and so does not need to be fixed up! As Antonio points out, the
> simple fix is to comment out the following loop in
> src/target/arm_adi_v5.c (reformatted for reading):
If it *DOES* report it correctly, why do they have erratum ENGcm09395 then ?
But
I assume you tested it on imx51 and it was reported correctly ?
Beagleboard isn't imx51 just fyi.
>
> #if 0 /* JCM - comment out this for the moment (for BeagleBoard-xM) */
>
> /* Some CPUs are messed up, so fixup if needed. */
> for (i = 0; i < sizeof(broken_cpus)/sizeof(struct broken_cpu); i++)
> if (broken_cpus[i].dbgbase == dbgbase &&
> broken_cpus[i].apid == apid) {
> LOG_WARNING("Found broken CPU (%s), trying to fixup "
> "ROM Table location from 0x%08x to 0x%08x",
> broken_cpus[i].model, dbgbase,
> broken_cpus[i].correct_dbgbase);
> dbgbase = broken_cpus[i].correct_dbgbase;
> break;
> }
> #endif
>
> (don't forget to comment out the "unsigned int i;" to avoid the gcc
> error that will be generated with the default flags used by OpenOCD).
This is bogus ... I'd prefer extending the detection to be able to identify
imx51 in a more precise way.
>
> This will prevent the DAP fixup logic from incorrectly being used. There
> is still no fix for this in OpenOCD master but I suspect some specific
> hack can be added to make that broken_cpus table more specific, or to
> have known-good models such as the one on BeagleBoard-xM be excluded.
>
> NOTE: It is important to physically reset the Flyswatter after you patch
> and re-install a working OpenOCD. Do not simply run it or you will see:
>
> [...@constitution ~]$ sudo /usr/local/bin/openocd
> -s /usr/local/lib/openocd
> -f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
> -f /usr/local/share/opocd/scripts/board/ti_beagleboard_xm.cfg
> Open On-Chip Debugger 0.5.0-dev-00651-gc6e0705-dirty (2010-12-12-19:44)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> 10 kHz
> Warn : dm37x.dsp: huge IR length 38
> trst_only separate trst_push_pull
> Info : clock speed 10 kHz
> Info : TAP dm37x.jrc does not have IDCODE
> Warn : JTAG tap: dm37x.jrc UNEXPECTED: 0x00000000 (mfg: 0x000,
> part: 0x0000, ver: 0x0)
> Error: JTAG tap: dm37x.jrc expected 1 of 1: 0x0b89102f (mfg: 0x017,
> part: 0xb891, ver: 0x0)
> Error: Trying to use configured scan chain anyway...
> Warn : Bypassing JTAG setup events due to errors
>
> Then the LED3 will also remain on and the Flyswatter won't work until
> you unplug and reset it. After doing that, with a modified OpenOCD
> otherwise based upon v0.4.0-651-gc6e0705 (today) with only the single
> loop commented out for a workaround, you should see:
>
> [...@constitution ~]$ sudo /usr/local/bin/openocd
> -s /usr/local/lib/openocd
> -f /usr/local/share/openocd/scripts/interface/flyswatter.cfg
> -f /usr/local/share/opocd/scripts/board/ti_beagleboard_xm.cfg
> Open On-Chip Debugger 0.5.0-dev-00651-gc6e0705-dirty (2010-12-12-19:44)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> 10 kHz
> Warn : dm37x.dsp: huge IR length 38
> trst_only separate trst_push_pull
> Info : clock speed 10 kHz
> Info : JTAG tap: dm37x.jrc tap/device found: 0x0b89102f (mfg: 0x017,
> part: 0xb891, ver: 0x0)
> Info : JTAG tap: dm37x.dap enabled
> Info : dm37x.cpu: hardware has 6 breakpoints, 2 watchpoints
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011150
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011150
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x540111c0
> Error: JTAG-DP STICKY ERROR
> Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x540111c0
>
> I still have a few problems with it. For example, I have to do a "reset
> halt" immediately in order to be able to halt the CPU, but after doing
> that I am able to read from the registers. I would love to know of other
> people's experiences as to what does and doesn't work at the moment,
> especially current opinions on the debugability of a Linux kernel.
>
> Jon.
Cheers
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
