Re: [Openocd-development] cortex a8/a9 debug base

[Marek Vasut]

On Tuesday 22 March 2011 12:16:47 Øyvind Harboe wrote:
 On Tue, Mar 22, 2011 at 12:14 PM, Michael Schwingen
 
 rincew...@discworld.dascon.de wrote:
  Øyvind Harboe wrote:
  I'm wondering if it would be better to ditch the automatic fixup
  code and use parameters to target in config script.
  
  Default would be to use the automatic detection per ARM's
  specification.
  
  Since auto-detecting the broken devices seems to be problematic, I think
  that would be a good approach, because it has zero chance of breaking
  non-affected devices.
 
 Sold then...
 
 Patch anyone?
 
 Wasn't this what was proposed in the first place? :-)
 
 Autodetect of a few broken devices would have been sweet, but I suppose
 we couldn't get away with it this time...

I wanted to have an option for debug base in config file at the begining, but 
was 
pushed to make the auto-detect code ;-)

Sorry I didn't have further look at the code, work totaled me.

Cheers
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 1/2] cortex a9: merge cortex a9 and a8 code

[Marek Vasut]

On Tuesday 22 March 2011 01:08:03 Aaron Carroll wrote:
 On 22 March 2011 01:53, luca ellero lro...@gmail.com wrote:
  Unfortunately at the moment I have no cortex A8 boards to test it.
  Anyway I wonder where 0x8000 come from, since I can't find any docs
  in
 
 This came from poking the omap4430.  The ROM (on the two rev's I
 tested, anyway) is bogus, so I don't think there's a sensible way to
 determine the addresses are run-time.

OMAP4430 has broken debug base address too ? Oh jeez :)

 ___
 Openocd-development mailing list
 Openocd-development@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] AM3517 problems

[Marek Vasut]

On Thursday 30 December 2010 08:41:12 Øyvind Harboe wrote:
  oyv...@titan:~/workspace/openocd$ openocd -c interface ZY1000;
  zy1000_server 127.0.0.1;jtag_khz 50 -f board/am3517evm.cfg
  Open On-Chip Debugger 0.5.0-dev-00682-g0136977 (2010-12-30-08:23)
  Licensed under GNU GPL v2
  For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
  Warn : Adapter driver 'ZY1000' did not declare which transports it
  allows; assuming legacy JTAG-only
  Info : only one transport option; autoselect 'jtag'
  50 kHz
  10 kHz
  trst_only separate trst_push_pull
  jtag_speed 6000 = JTAG clk=10 kHz
  Info : clock speed 10 kHz
  Info : JTAG tap: am35x.jrc tap/device found: 0x0b7ae02f (mfg: 0x017,
  part: 0xb7ae, ver: 0x0)
  Info : JTAG tap: am35x.dap enabled
  Info : am35x.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
  
  These errors here, right ... need to investigate. Any pointers possibly ?
 
 Sorry no.
 
 Fire up the debugger on OpenOCD and see what turns up?
 
 Try an older version of OpenOCD to see if it is a regression?

This stuff was there ever since I believe. I might dig in later ... I hope it's 
still connected ? :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification

[Marek Vasut]

This patch fixes the issue where the OMAP CPU (and possibly others) was mistaken
for iMX51 and therefore had misadjusted debug base.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 src/target/arm_adi_v5.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 69a3ce7..7df0d4f 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -1013,10 +1013,11 @@ is_dap_cid_ok(uint32_t cid3, uint32_t cid2, uint32_t 
cid1, uint32_t cid0)
 struct broken_cpu {
uint32_tdbgbase;
uint32_tapid;
+   uint32_tidcode;
uint32_tcorrect_dbgbase;
char*model;
 } broken_cpus[] = {
-   { 0x8000, 0x04770002, 0x6000, imx51 },
+   { 0x8000, 0x04770002, 0x1ba00477, 0x6000, imx51 },
 };
 
 int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
@@ -1025,7 +1026,7 @@ int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
uint32_t apselold;
int retval;
unsigned int i;
-   uint32_t dbgbase, apid;
+   uint32_t dbgbase, apid, idcode;
 
/* AP address is in bits 31:24 of DP_SELECT */
if (apsel = 256)
@@ -1044,10 +1045,23 @@ int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
if (retval != ERROR_OK)
return retval;
 
+   /* Excavate the device ID code */
+   struct jtag_tap *tap = dap-jtag_info-tap;
+   while (tap != NULL) {
+   if (tap-hasidcode) {
+   idcode = tap-idcode;
+   break;
+   }
+   tap = tap-next_tap;
+   }
+   if (tap == NULL || !tap-hasidcode)
+   return ERROR_OK;
+
/* 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) {
+   broken_cpus[i].apid == apid 
+   broken_cpus[i].idcode == idcode) {
LOG_WARNING(Found broken CPU (%s), trying to fixup 
ROM Table location from 0x%08x to 0x%08x,
broken_cpus[i].model, dbgbase,
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification

[Marek Vasut]

On Thursday 30 December 2010 08:27:52 Øyvind Harboe wrote:
 Merged.
 
 Thanks!
 
 Took it for a spin on AM3517 and that target is no longer
 incorrectly identified as an imx51.
 
 
 That target still needs work though:
 
 oyv...@titan:~/workspace/openocd$ openocd -c interface ZY1000;
 zy1000_server 127.0.0.1;jtag_khz 50 -f board/am3517evm.cfg
 Open On-Chip Debugger 0.5.0-dev-00682-g0136977 (2010-12-30-08:23)
 Licensed under GNU GPL v2
 For bug reports, read
   http://openocd.berlios.de/doc/doxygen/bugs.html
 Warn : Adapter driver 'ZY1000' did not declare which transports it
 allows; assuming legacy JTAG-only
 Info : only one transport option; autoselect 'jtag'
 50 kHz
 10 kHz
 trst_only separate trst_push_pull
 jtag_speed 6000 = JTAG clk=10 kHz
 Info : clock speed 10 kHz
 Info : JTAG tap: am35x.jrc tap/device found: 0x0b7ae02f (mfg: 0x017,
 part: 0xb7ae, ver: 0x0)
 Info : JTAG tap: am35x.dap enabled
 Info : am35x.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

These errors here, right ... need to investigate. Any pointers possibly ?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [beagleboard] Flyswatter with XM

[Marek Vasut]

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: 0x (mfg: 0x000,
 part: 0x, 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

Re: [Openocd-development] [beagleboard] Flyswatter with XM

[Marek Vasut]

On Monday 13 December 2010 10:00:05 Jon Masters wrote:
 On Mon, 2010-12-13 at 09:45 +0100, Marek Vasut wrote:
  On Monday 13 December 2010 03:27:17 Jon Masters wrote:
   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.
 
 Sorry, you're right. I spent too long reading the OpenOCD source and
 seeing the IMX51 Freescale references in the broken_cpus array, and then
 it was late... Yea, I'm using the DM3730 TI processor in the
 BeagleBoard-xM here, which is being picked up by your logic in that loop
 incorrectly and a fixup is being applied that should not be applied.
 
 snip commented out code fixup
 
  This is bogus ... I'd prefer extending the detection to be able to
  identify imx51 in a more precise way.
 
 Sure. I was just applying a hack in my local git branch for running the
 BeagleBoard-xM here with my Flyswatter. That was neither a patch nor
 intended for use other than with the xM if someone else is using a
 release of OpenOCD since the beginning of November. I really agree with
 you that the correct fix is to better determine an IMX51 for fixup.
 
 FWIW, I got this wrong at first. I read the archives and assumed that
 the BeagleBoard was in need of some fixup, but actually it's fine. It's
 the logic intended to fixup the other part that is breaking Beagle.

Can you try checking how can that be fixed ? I believe it'd just be a matter of 
adding a few more identification information (check how the fixup loop detects 
the 
CPU, try extending it so it doesn't break beagle).
 
 Oh, and hey, thanks for the followup.
 
 Jon.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] iMX51 workaround

[Marek Vasut]

On Wednesday 01 December 2010 19:55:23 Øyvind Harboe wrote:
 On Wed, Dec 1, 2010 at 6:04 PM, Peter Stuge pe...@stuge.se wrote:
  Øyvind Harboe wrote:
  If iMX51 is broken and the current CortexA8 workaround code for it
  breaks other CPUs, then I think that the automatic workaround code
  for iMX51 has to be either fixed or removed.
  
  Do you know which commit it was added in?
 
 v0.4.0-570-g0649fb2
 
 Marek did a whole bunch of great work solving other long standing
 problems.

I don't mind testing patches for it. What's the breakage ? With what target / 
what are the symptoms etc?

Cheers
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Automatic detection of debugbase for cortex A8

[Marek Vasut]

On Tuesday 30 November 2010 08:16:31 Øyvind Harboe wrote:
  This patch breaks debugging on the DM37x.  It appears that the debug
  base and APID is not sufficient to identify problematic processors
  since the DM37x on the Beagleboard XM incorrectly passes the checks in
  arm_adi_v5.c:
  
 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;
 }
  
  Is there another way that these problematic CPUs can be identified?
 
 Anyone?

Ah I see it now ... I don't have DM37x based board, but I can try getting one. 
Otherwise, can someone (with DM37x) help me fixing this ?

Thanks in advance, Cheers
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] U Boot ethernet problem

[Marek Vasut]

On Wednesday 03 November 2010 14:59:55 Moshe Artzi wrote:
 Hi Marek,
 
 
 
 I finally running u boot on my PXA320 but,
 
 I don't know why but,
 
 
 
 When I'm sending ping from the u boot to the host it pings ok.
 
 But when I'm trying to ping from the host to the u boot it lost.
 
 That's why I'm not able to download an image to the u boot.

Because u-boot only starts the network chip for the time when it sends packets. 
It doesn't activelly wait for pings (the chip is off), that's why it doesn't 
react.

It's not the reason why you're not able to download the image. The fact it 
pings 
means the network chip works. What command do you use to download the image?
 
 
 
 Any ideas ?
 
 
 
 Thanks,
 
 
 
 Moshe Artzi
 
 Software engineer
 
 
 
 Niron systems
 
 Tel : 09-7407626
 
 Ex : 104
 
 Fax: 09-8651510
 
 Mobile : 050-3356312
 
 Email :  mailto:mosh...@niron-sys.com mosh...@niron-sys.com
 
 Site:  http://www.niron-sys.com/ www.niron-sys.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Failed to receiving data from debug handler after 1000 - using jtag-tiny with colibri PXA320

[Marek Vasut]

On Monday 01 November 2010 10:37:41 Moshe Artzi wrote:
 Hi marek,
 
 The u-boot is working for me (by nand the uboot image and not by the ram)
 with this config:
 
 Openocd.cfg
 *
 source [find interface/jtagkey-tiny.cfg]
 
 # Change the default telnet port...
 telnet_port 
 
 source [find board/colibri_pxa320.cfg]
 jtag_khz 2000
 reset_config none combined
 
 *
 
 The reset_config parameter in none value did the trick for me and let me
 probe the nand !
 
 I'm using:
 
 * Amontec Jtagkey-tiny
 * Toradex colibri pxa320
 * colibri evaluation board Rev 2.1
 * Open OCD 0.5.0
 
 Thank You very much for the support.
 
 Moshe Artzi.
 
 
 -Original Message-
 From: Marek Vasut [mailto:marek.va...@gmail.com]
 Sent: Monday, October 25, 2010 10:29 PM
 To: Moshe Artzi
 Cc: 'Takács Áron'; 'Gena Chap'; openpxa-us...@lists.sourceforge.net;
 openocd-development@lists.berlios.de; 'Øyvind Harboe' Subject: Re: Failed
 to receiving data from debug handler after 1000 - using jtag-tiny with
 colibri PXA320
 
 On Monday 25 October 2010 11:38:53 Moshe Artzi wrote:
  Hi Marek,
  
  Sorry for the interrupt but,
  I'm still can't make this thing work.
  
  After nand the image I get this error:
  Failed to receiving data from debug handler after 1000 attempts Command
  handler execution failed in procedure 'resume'
  
  From my understanding, this is timing issue between the PXA320 and the
  Jtag but, I can't find the parameter/s that can cause this problem.
  
  
  Here is command line session  print screen:
  
  Open On-Chip Debugger 0.5.0-dev-snapshot (2010-10-25-09:14)
  Licensed under GNU GPL v2
  For bug reports, read
  http://openocd.berlios.de/doc/doxygen/bugs.html
  Info : only one transport option; autoselect 'jtag'
  adapter_nsrst_delay: 260
  jtag_ntrst_delay: 250
  Info : colibri_pxa320.cpu: hardware has 2 breakpoints and 2 watchpoints
  adapter_nsrst_delay: 2000
  trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
  200 kHz
  Info : device: 4 2232C
  Info : deviceID: 67358712
  Info : SerialNumber: T1TA5HKBA
  Info : Description: Amontec JTAGkey A
  Info : clock speed 200 kHz
  Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg:
  0x009, part: 0xe642, ver: 0x7) Info : accepting 'telnet' connection from
  
  Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg:
  0x009, part: 0xe642, ver: 0x7) target state: halted
  target halted in ARM state due to debug-request, current mode: Supervisor
  cpsr: 0xf8d3 pc: 0x
  MMU: disabled, D-Cache: disabled, I-Cache: disabled
  (processor reset)
  1472 bytes written at address 0x5c04
  downloaded 1472 bytes in 0.094000s (15.293 KiB/s)
  Error: Failed to receiving data from debug handler after 1000 attempts
  Command handler execution failed
  in procedure 'resume'
  
  
  Here is telnet session print screen:
  
  Open On-Chip Debugger
  
   reset halt ;load_image iplntim.bin 0x5c04 ;resume 0x5c04
  
  JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009,
  part: 0xe642, ver: 0x7) target state: halted
  target halted in ARM state due to debug-request, current mode: Supervisor
  cpsr: 0xf8d3 pc: 0x
  MMU: disabled, D-Cache: disabled, I-Cache: disabled
  (processor reset)
  1472 bytes written at address 0x5c04
  downloaded 1472 bytes in 0.094000s (15.293 KiB/s)
  Failed to receiving data from debug handler after 1000 attempts
  Command handler execution failed
  in procedure 'resume'
  
  
  I'm getting frustrated !!! ;(
 
 Hey, sorry ... I really don't know how to help you. It looks like the core
 halted, but it won't start at the specified address.
 
 For me, it always helped to powerdown and power-up the board.
 
 Sorry once again
 
  Any assist will be blessed,
  
  Thanks,
  
  Moshe.

That's good to hear :)

I'll test it myself and then ask Oyvind to merge your patch into OpenOCD.

Cheers
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 1/5] ADIv5: Introduce function to detect ROM Table location

[Marek Vasut]

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
function, which will be called in case such CPU is detected.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 src/target/arm_adi_v5.c |   58 +++---
 src/target/arm_adi_v5.h |9 +++
 2 files changed, 38 insertions(+), 29 deletions(-)

diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 3414796..4c54308 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -906,7 +906,7 @@ extern const struct dap_ops jtag_dp_ops;
  */
 int ahbap_debugport_init(struct adiv5_dap *dap)
 {
-   uint32_t idreg, romaddr, dummy;
+   uint32_t dummy;
uint32_t ctrlstat;
int cnt = 0;
int retval;
@@ -985,26 +985,6 @@ int ahbap_debugport_init(struct adiv5_dap *dap)
if (retval != ERROR_OK)
return retval;
 
-   /*
-* REVISIT this isn't actually *initializing* anything in an AP,
-* and doesn't care if it's a MEM-AP at all (much less AHB-AP).
-* Should it?  If the ROM address is valid, is this the right
-* place to scan the table and do any topology detection?
-*/
-   retval = dap_queue_ap_read(dap, AP_REG_IDR, idreg);
-   if (retval != ERROR_OK)
-   return retval;
-   retval = dap_queue_ap_read(dap, AP_REG_BASE, romaddr);
-   if (retval != ERROR_OK)
-   return retval;
-
-   if ((retval = dap_run(dap)) != ERROR_OK)
-   return retval;
-
-   LOG_DEBUG(MEM-AP #% PRId32  ID Register 0x% PRIx32
-   , Debug ROM Address 0x% PRIx32,
-   dap-apsel, idreg, romaddr);
-
return ERROR_OK;
 }
 
@@ -1026,14 +1006,11 @@ is_dap_cid_ok(uint32_t cid3, uint32_t cid2, uint32_t 
cid1, uint32_t cid0)
 ((cid1  0x0f) == 0)  cid0 == 0x0d;
 }
 
-static int dap_info_command(struct command_context *cmd_ctx,
-   struct adiv5_dap *dap, int apsel)
+int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
+   uint32_t *dbgbase, uint32_t *apid)
 {
-   int retval;
-   uint32_t dbgbase, apid;
-   int romtable_present = 0;
-   uint8_t mem_ap;
uint32_t apselold;
+   int retval;
 
/* AP address is in bits 31:24 of DP_SELECT */
if (apsel = 256)
@@ -1041,16 +1018,39 @@ static int dap_info_command(struct command_context 
*cmd_ctx,
 
apselold = dap-apsel;
dap_ap_select(dap, apsel);
-   retval = dap_queue_ap_read(dap, AP_REG_BASE, dbgbase);
+
+   retval = dap_queue_ap_read(dap, AP_REG_BASE, dbgbase);
if (retval != ERROR_OK)
return retval;
-   retval = dap_queue_ap_read(dap, AP_REG_IDR, apid);
+   retval = dap_queue_ap_read(dap, AP_REG_IDR, apid);
if (retval != ERROR_OK)
return retval;
retval = dap_run(dap);
if (retval != ERROR_OK)
return retval;
 
+   /* Some CPUs are messed up, so fixup if needed. */
+   if (dap-debug_base_fixup != NULL)
+   dap-debug_base_fixup(dap, apsel, dbgbase, apid);
+
+   dap_ap_select(dap, apselold);
+
+   return ERROR_OK;
+}
+
+static int dap_info_command(struct command_context *cmd_ctx,
+   struct adiv5_dap *dap, int apsel)
+{
+   int retval;
+   uint32_t dbgbase, apid;
+   int romtable_present = 0;
+   uint8_t mem_ap;
+   uint32_t apselold;
+
+   retval = dap_get_debugbase(dap, apsel, dbgbase, apid);
+   if (retval != ERROR_OK)
+   return retval;
+
/* Now we read ROM table ID registers, ref. ARM IHI 0029B sec  */
mem_ap = ((apid0x1)  ((apid0x0F) != 0));
command_print(cmd_ctx, AP ID register 0x%8.8 PRIx32, apid);
diff --git a/src/target/arm_adi_v5.h b/src/target/arm_adi_v5.h
index 92469eb..c499755 100644
--- a/src/target/arm_adi_v5.h
+++ b/src/target/arm_adi_v5.h
@@ -179,6 +179,12 @@ struct adiv5_dap
/* Size of TAR autoincrement block, ARM ADI Specification requires at 
least 10 bits */
uint32_t tar_autoincr_block;
 
+   /**
+* In case the ROM Table location, reported by the DAP is incorrect,
+* call this function to issue a fixup at probe time.
+*/
+   void(*debug_base_fixup)(struct adiv5_dap *dap, int apsel,
+   uint32_t *dbgbase, uint32_t *apid);
 };
 
 /**
@@ -380,6 +386,9 @@ int mem_ap_write_buf_u32(struct adiv5_dap *swjdp,
 /* Initialisation of the debug system, power domains and registers */
 int ahbap_debugport_init(struct adiv5_dap *swjdp);
 
+/* Probe the AP for ROM Table location */
+int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
+   uint32_t *dbgbase, uint32_t *apid);
 
 struct

[Openocd-development] [PATCH 2/5] ADIv5: Implement function to lookup CoreSight component

[Marek Vasut]

This patch implements dap_lookup_cs_component(), which allows to lookup CS
component by it's identification.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 src/target/arm_adi_v5.c |   31 +++
 src/target/arm_adi_v5.h |4 
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 4c54308..8f41e36 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -1038,6 +1038,37 @@ int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
return ERROR_OK;
 }
 
+int dap_lookup_cs_component(struct adiv5_dap *dap, uint32_t apsel,
+   uint32_t dbgbase, uint8_t type, uint32_t *addr)
+{
+   uint32_t romentry, entry_offset = 0, component_base, devtype;
+   int retval;
+
+   do
+   {
+   retval = mem_ap_read_atomic_u32(dap, (dbgbase0xF000) |
+   entry_offset, romentry);
+   if (retval != ERROR_OK)
+   return retval;
+
+   component_base = (dbgbase  0xF000)
+   + (romentry  0xF000);
+
+   if (romentry  0x1) {
+   retval = mem_ap_read_atomic_u32(dap,
+   (component_base  0xf000) | 0xfcc,
+   devtype);
+   if ((devtype  0xff) == type) {
+   *addr = component_base;
+   return ERROR_OK;
+   }
+   }
+   entry_offset += 4;
+   } while (romentry  0);
+   return ERROR_FAIL;
+
+}
+
 static int dap_info_command(struct command_context *cmd_ctx,
struct adiv5_dap *dap, int apsel)
 {
diff --git a/src/target/arm_adi_v5.h b/src/target/arm_adi_v5.h
index c499755..5fb38cf 100644
--- a/src/target/arm_adi_v5.h
+++ b/src/target/arm_adi_v5.h
@@ -390,6 +390,10 @@ int ahbap_debugport_init(struct adiv5_dap *swjdp);
 int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
uint32_t *dbgbase, uint32_t *apid);
 
+/* Lookup CoreSight component */
+int dap_lookup_cs_component(struct adiv5_dap *dap, uint32_t apsel,
+   uint32_t dbgbase, uint8_t type, uint32_t *addr);
+
 struct target;
 
 /* Put debug link into SWD mode */
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 3/5] CortexA8: Implement debug base autodetection

[Marek Vasut]

Implement autodetection of debug base. Also, implement a function solving
various hardware quirks (like iMX51 ROM Table location bug).

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 src/target/cortex_a8.c |   28 +---
 1 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 8b4ced5..d090fe4 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -73,7 +73,6 @@ static int cortex_a8_get_ttb(struct target *target, uint32_t 
*result);
  */
 #define swjdp_memoryap 0
 #define swjdp_debugap 1
-#define OMAP3530_DEBUG_BASE 0x54011000
 
 /*
  * Cortex-A8 Basic debug access, very low level assumes state is saved
@@ -1702,6 +1701,19 @@ static int cortex_a8_handle_target_request(void *priv)
return ERROR_OK;
 }
 
+static const char *variant = NULL;
+
+void cortex_a8_debug_base_fixup(struct adiv5_dap *dap, int apsel,
+   uint32_t *dbgbase, uint32_t *apid)
+{
+   /* Various CPU-specific quirks */
+
+   /* iMX51 misreports ROM Table address */
+   if ((variant != NULL)  (strcmp(variant, imx51) == 0))
+   if (*dbgbase != 0x)
+   *dbgbase = 0x6000;
+}
+
 /*
  * Cortex-A8 target information and configuration
  */
@@ -1714,20 +1726,22 @@ static int cortex_a8_examine_first(struct target 
*target)
int i;
int retval = ERROR_OK;
uint32_t didr, ctypr, ttypr, cpuid;
-
-   /* stop assuming this is an OMAP! */
-   LOG_DEBUG(TODO - autoconfigure);
-
-   /* Here we shall insert a proper ROM Table scan */
-   armv7a-debug_base = OMAP3530_DEBUG_BASE;
+   uint32_t dbgbase, apid, base;
 
/* We do one extra read to ensure DAP is configured,
 * we call ahbap_debugport_init(swjdp) instead
 */
+   variant = target-variant;
+   swjdp-debug_base_fixup = cortex_a8_debug_base_fixup;
retval = ahbap_debugport_init(swjdp);
if (retval != ERROR_OK)
return retval;
 
+   cortex_a8_debug_base_fixup(swjdp, 0, dbgbase, apid);
+
+   dap_lookup_cs_component(swjdp, 0, dbgbase, 0x15, base);
+   armv7a-debug_base = base;
+
retval = mem_ap_read_atomic_u32(swjdp, armv7a-debug_base + 
CPUDBG_CPUID, cpuid);
if (retval != ERROR_OK)
return retval;
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 4/5] CortexA8: Introduce Freescale i.MX51 variant

[Marek Vasut]

This patch introduces support for Cortex A8 based Freescale i.MX51 CPU. This CPU
has the Debug Access Port located at a different address (0x60008000) than TI
OMAP3 series of CPUs.

i.MX51 configuration file based on OMAP3 configuration file and an email from
Alan Carvalho de Assis acas...@gmail.com.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 tcl/target/imx51.cfg |   52 ++
 1 files changed, 52 insertions(+), 0 deletions(-)
 create mode 100644 tcl/target/imx51.cfg

diff --git a/tcl/target/imx51.cfg b/tcl/target/imx51.cfg
new file mode 100644
index 000..35d8a2c
--- /dev/null
+++ b/tcl/target/imx51.cfg
@@ -0,0 +1,52 @@
+# Freescale i.MX51
+
+if { [info exists CHIPNAME] } {
+   set  _CHIPNAME $CHIPNAME
+} else {
+   set  _CHIPNAME imx51
+}
+
+# CoreSight Debug Access Port
+if { [info exists DAP_TAPID ] } {
+   set _DAP_TAPID $DAP_TAPID
+} else {
+   set _DAP_TAPID 0x1ba00477
+}
+
+jtag newtap $_CHIPNAME DAP -irlen 4 -ircapture 0x1 -irmask 0xf \
+-expected-id $_DAP_TAPID
+
+# SDMA / no IDCODE
+jtag newtap $_CHIPNAME SDMA -irlen 4 -ircapture 0x0 -irmask 0xf
+
+# SJC
+if { [info exists SJC_TAPID ] } {
+   set _SJC_TAPID SJC_TAPID
+} else {
+   set _SJC_TAPID 0x0190c01d
+}
+
+jtag newtap $_CHIPNAME SJC -irlen 5 -ircapture 0x1 -irmask 0x1f \
+-expected-id $_SJC_TAPID -ignore-version
+
+# GDB target:  Cortex-A8, using DAP
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.DAP \
+   -variant imx51
+
+# some TCK tycles are required to activate the DEBUG power domain
+jtag configure $_CHIPNAME.SJC -event post-reset runtest 100
+
+# have the DAP always be active
+jtag configure $_CHIPNAME.SJC -event setup jtag tapenable $_CHIPNAME.DAP
+
+proc imx51_dbginit {target} {
+ # General Cortex A8 debug initialisation
+ cortex_a8 dbginit
+}
+
+# Slow speed to be sure it will work
+jtag_rclk 1000
+$_TARGETNAME configure -event reset-start { jtag_rclk 1000 }
+
+$_TARGETNAME configure -event reset-assert-post imx51_dbginit $_TARGETNAME
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 5/5] Add EfikaMX smarttop board support

[Marek Vasut]

This patch finally adds support for i.MX51 based Genesi USA EfikaMX smarttop
board.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 tcl/board/efikamx.cfg |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)
 create mode 100644 tcl/board/efikamx.cfg

diff --git a/tcl/board/efikamx.cfg b/tcl/board/efikamx.cfg
new file mode 100644
index 000..f8ae25d
--- /dev/null
+++ b/tcl/board/efikamx.cfg
@@ -0,0 +1,9 @@
+# Genesi USA EfikaMX
+#  http://www.genesi-usa.com/products/efika
+
+# Fall back to 6MHz if RTCK is not supported
+jtag_rclk 6000
+
+source [find target/imx51.cfg]
+
+reset_config trst_only
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/5] CortexA8: Implement debug base autodetection

[Marek Vasut]

On Sunday 31 October 2010 10:49:54 David Brownell wrote:
   #define swjdp_memoryap 0
   #define swjdp_debugap 1
 
 For Cortex-A8 it's likely not SWJ-DP but
 instead JTAG-DP ... regardless it's best
 not to try exposing irrelevant details
 like that in naming conventions here...
 
  +static const char *variant = NULL;
 
 variant is never changed but ...
 
  ...
  +   
  uint32_t *dbgbase, uint32_t *apid)
  +{
  +/* Various CPU-specific quirks */
  +
  +/* iMX51 misreports ROM Table address
 
 ... and surely that can be detected, and then
 handled in a better way.
 
  */
  +if ((variant != NULL) 
  (strcmp(variant, imx51) == 0))
 
  ... here we assume ight might be ...

What I'd be more interested is 
1) Is this approach to detection correct
2) Is the placement of the fixup function in adiv5_dap structure correct
3) Placing the variant into adiv5_dap would fix the above, but I don't like 
the 
idea ... so where to place it so it can be used from within the fixup function?

Cheers
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63

[Marek Vasut]

On Sunday 31 October 2010 18:37:33 Øyvind Harboe wrote:
 On Sun, Oct 31, 2010 at 6:26 PM, Peter Stuge pe...@stuge.se wrote:
  Øyvind Harboe wrote:
   Is there also an upstream for Jim Tcl to make distribution packages
   from?
   
   Or is Jim Tcl only ever statically linked with OpenOCD?
  
  Statically linked, no change there.
  
  Ok. Has Jim Tcl ever been packaged independently? Is it our project
  as well?
 
 It's designed to be statically linked with applications, which means
 that packaging is not as important as for your typical module
 that is used in e.g. embedded Linux.
 
 It's not our project, but I'm a maintainer of Jim Tcl, but I hope to sit
 on the sideline now that Steve Bennet has stepped up. He knows
 a LOT more about Tcl than I do and has really cleaned up lots of
 stuff in Jim Tcl.

Well this is weird ... won't it be better compile both jimtcl and openocd with 
single ./configure and make, without needing to install that stuff separatelly ?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63

[Marek Vasut]

On Monday 01 November 2010 01:50:19 Peter Stuge wrote:
 Marek Vasut wrote:
  won't it be better compile both jimtcl and openocd with single
  ./configure and make, without needing to install that stuff
  separatelly ?
 
 It doesn't need to be installed, that's part of the point.

In my case, openocd chokes if I don't install it ... that's my point.
 
 Although I'm thinking about if it might make sense to package it
 anyway. I guess it's like a library.
 
 
 //Peter
 ___
 Openocd-development mailing list
 Openocd-development@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 1/5 v2] ADIv5: Introduce function to detect ROM Table location

[Marek Vasut]

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
---
v2: Auto-detect the broken CPUs, implement a table of broken CPUs

 src/target/arm_adi_v5.c |   79 +++---
 src/target/arm_adi_v5.h |4 ++-
 2 files changed, 56 insertions(+), 27 deletions(-)

diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 3414796..4950121 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -906,7 +906,7 @@ extern const struct dap_ops jtag_dp_ops;
  */
 int ahbap_debugport_init(struct adiv5_dap *dap)
 {
-   uint32_t idreg, romaddr, dummy;
+   uint32_t dummy;
uint32_t ctrlstat;
int cnt = 0;
int retval;
@@ -985,26 +985,6 @@ int ahbap_debugport_init(struct adiv5_dap *dap)
if (retval != ERROR_OK)
return retval;
 
-   /*
-* REVISIT this isn't actually *initializing* anything in an AP,
-* and doesn't care if it's a MEM-AP at all (much less AHB-AP).
-* Should it?  If the ROM address is valid, is this the right
-* place to scan the table and do any topology detection?
-*/
-   retval = dap_queue_ap_read(dap, AP_REG_IDR, idreg);
-   if (retval != ERROR_OK)
-   return retval;
-   retval = dap_queue_ap_read(dap, AP_REG_BASE, romaddr);
-   if (retval != ERROR_OK)
-   return retval;
-
-   if ((retval = dap_run(dap)) != ERROR_OK)
-   return retval;
-
-   LOG_DEBUG(MEM-AP #% PRId32  ID Register 0x% PRIx32
-   , Debug ROM Address 0x% PRIx32,
-   dap-apsel, idreg, romaddr);
-
return ERROR_OK;
 }
 
@@ -1026,14 +1006,22 @@ is_dap_cid_ok(uint32_t cid3, uint32_t cid2, uint32_t 
cid1, uint32_t cid0)
 ((cid1  0x0f) == 0)  cid0 == 0x0d;
 }
 
-static int dap_info_command(struct command_context *cmd_ctx,
-   struct adiv5_dap *dap, int apsel)
+struct broken_cpu {
+   uint32_tdbgbase;
+   uint32_tapid;
+   uint32_tcorrect_dbgbase;
+   char*model;
+} broken_cpus[] = {
+   { 0x8000, 0x04770002, 0x6000, imx51 },
+};
+
+int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
+   uint32_t *out_dbgbase, uint32_t *out_apid)
 {
+   uint32_t apselold;
int retval;
+   unsigned int i;
uint32_t dbgbase, apid;
-   int romtable_present = 0;
-   uint8_t mem_ap;
-   uint32_t apselold;
 
/* AP address is in bits 31:24 of DP_SELECT */
if (apsel = 256)
@@ -1041,6 +1029,7 @@ static int dap_info_command(struct command_context 
*cmd_ctx,
 
apselold = dap-apsel;
dap_ap_select(dap, apsel);
+
retval = dap_queue_ap_read(dap, AP_REG_BASE, dbgbase);
if (retval != ERROR_OK)
return retval;
@@ -1051,6 +1040,44 @@ static int dap_info_command(struct command_context 
*cmd_ctx,
if (retval != ERROR_OK)
return retval;
 
+   /* 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;
+   }
+
+   dap_ap_select(dap, apselold);
+
+   /* The asignment happens only here to prevent modification of these
+* values before they are certain. */
+   *out_dbgbase = dbgbase;
+   *out_apid = apid;
+
+   return ERROR_OK;
+}
+
+static int dap_info_command(struct command_context *cmd_ctx,
+   struct adiv5_dap *dap, int apsel)
+{
+   int retval;
+   uint32_t dbgbase, apid;
+   int romtable_present = 0;
+   uint8_t mem_ap;
+   uint32_t apselold;
+
+   retval = dap_get_debugbase(dap, apsel, dbgbase, apid);
+   if (retval != ERROR_OK)
+   return retval;
+
+   apselold = dap-apsel;
+   dap_ap_select(dap, apsel);
+
/* Now we read ROM table ID registers, ref. ARM IHI 0029B sec  */
mem_ap = ((apid0x1)  ((apid0x0F) != 0));
command_print(cmd_ctx, AP ID register 0x%8.8 PRIx32, apid);
diff --git a/src/target/arm_adi_v5.h b/src/target/arm_adi_v5.h
index 92469eb..27a2f2f 100644
--- a/src/target/arm_adi_v5.h
+++ b/src/target/arm_adi_v5.h

[Openocd-development] [PATCH 2/5 v2] ADIv5: Implement function to lookup CoreSight component

[Marek Vasut]

This patch implements dap_lookup_cs_component(), which allows to lookup CS
component by it's identification.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
v2: Save apsel and restore it on return

 src/target/arm_adi_v5.c |   41 +
 src/target/arm_adi_v5.h |4 
 2 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 4950121..295cb18 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -1062,6 +1062,47 @@ int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
return ERROR_OK;
 }
 
+int dap_lookup_cs_component(struct adiv5_dap *dap, int apsel,
+   uint32_t dbgbase, uint8_t type, uint32_t *addr)
+{
+   uint32_t apselold;
+   uint32_t romentry, entry_offset = 0, component_base, devtype;
+   int retval = ERROR_FAIL;
+
+   if (apsel = 256)
+   return ERROR_INVALID_ARGUMENTS;
+
+   apselold = dap-apsel;
+   dap_ap_select(dap, apsel);
+
+   do
+   {
+   retval = mem_ap_read_atomic_u32(dap, (dbgbase0xF000) |
+   entry_offset, romentry);
+   if (retval != ERROR_OK)
+   return retval;
+
+   component_base = (dbgbase  0xF000)
+   + (romentry  0xF000);
+
+   if (romentry  0x1) {
+   retval = mem_ap_read_atomic_u32(dap,
+   (component_base  0xf000) | 0xfcc,
+   devtype);
+   if ((devtype  0xff) == type) {
+   *addr = component_base;
+   retval = ERROR_OK;
+   break;
+   }
+   }
+   entry_offset += 4;
+   } while (romentry  0);
+
+   dap_ap_select(dap, apselold);
+
+   return retval;
+}
+
 static int dap_info_command(struct command_context *cmd_ctx,
struct adiv5_dap *dap, int apsel)
 {
diff --git a/src/target/arm_adi_v5.h b/src/target/arm_adi_v5.h
index 27a2f2f..6c1808a 100644
--- a/src/target/arm_adi_v5.h
+++ b/src/target/arm_adi_v5.h
@@ -383,6 +383,10 @@ int ahbap_debugport_init(struct adiv5_dap *swjdp);
 int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
uint32_t *dbgbase, uint32_t *apid);
 
+/* Lookup CoreSight component */
+int dap_lookup_cs_component(struct adiv5_dap *dap, int apsel,
+   uint32_t dbgbase, uint8_t type, uint32_t *addr);
+
 struct target;
 
 /* Put debug link into SWD mode */
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 3/5 v2] CortexA8: Implement debug base autodetection

[Marek Vasut]

Implement autodetection of debug base. Also, implement a function solving
various hardware quirks (like iMX51 ROM Table location bug).

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
v2: Handle error codes, remove the variant stuff and buggy hardware fixup
function

 src/target/cortex_a8.c |   19 ---
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 8b4ced5..3c80923 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -73,7 +73,6 @@ static int cortex_a8_get_ttb(struct target *target, uint32_t 
*result);
  */
 #define swjdp_memoryap 0
 #define swjdp_debugap 1
-#define OMAP3530_DEBUG_BASE 0x54011000
 
 /*
  * Cortex-A8 Basic debug access, very low level assumes state is saved
@@ -1714,12 +1713,7 @@ static int cortex_a8_examine_first(struct target *target)
int i;
int retval = ERROR_OK;
uint32_t didr, ctypr, ttypr, cpuid;
-
-   /* stop assuming this is an OMAP! */
-   LOG_DEBUG(TODO - autoconfigure);
-
-   /* Here we shall insert a proper ROM Table scan */
-   armv7a-debug_base = OMAP3530_DEBUG_BASE;
+   uint32_t dbgbase, apid;
 
/* We do one extra read to ensure DAP is configured,
 * we call ahbap_debugport_init(swjdp) instead
@@ -1728,6 +1722,17 @@ static int cortex_a8_examine_first(struct target *target)
if (retval != ERROR_OK)
return retval;
 
+   /* Get ROM Table base */
+   retval = dap_get_debugbase(swjdp, 1, dbgbase, apid);
+   if (retval != ERROR_OK)
+   return retval;
+
+   /* Lookup 0x15 -- Processor DAP */
+   retval = dap_lookup_cs_component(swjdp, 1, dbgbase, 0x15,
+   armv7a-debug_base);
+   if (retval != ERROR_OK)
+   return retval;
+
retval = mem_ap_read_atomic_u32(swjdp, armv7a-debug_base + 
CPUDBG_CPUID, cpuid);
if (retval != ERROR_OK)
return retval;
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 4/5 v2] CortexA8: Introduce Freescale i.MX51 variant

[Marek Vasut]

This patch introduces support for Cortex A8 based Freescale i.MX51 CPU. This CPU
has the Debug Access Port located at a different address (0x60008000) than TI
OMAP3 series of CPUs.

i.MX51 configuration file based on OMAP3 configuration file and an email from
Alan Carvalho de Assis acas...@gmail.com.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
v2: Remove variant

 tcl/target/imx51.cfg |   51 ++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100644 tcl/target/imx51.cfg

diff --git a/tcl/target/imx51.cfg b/tcl/target/imx51.cfg
new file mode 100644
index 000..35d8a2c
--- /dev/null
+++ b/tcl/target/imx51.cfg
@@ -0,0 +1,51 @@
+# Freescale i.MX51
+
+if { [info exists CHIPNAME] } {
+   set  _CHIPNAME $CHIPNAME
+} else {
+   set  _CHIPNAME imx51
+}
+
+# CoreSight Debug Access Port
+if { [info exists DAP_TAPID ] } {
+   set _DAP_TAPID $DAP_TAPID
+} else {
+   set _DAP_TAPID 0x1ba00477
+}
+
+jtag newtap $_CHIPNAME DAP -irlen 4 -ircapture 0x1 -irmask 0xf \
+-expected-id $_DAP_TAPID
+
+# SDMA / no IDCODE
+jtag newtap $_CHIPNAME SDMA -irlen 4 -ircapture 0x0 -irmask 0xf
+
+# SJC
+if { [info exists SJC_TAPID ] } {
+   set _SJC_TAPID SJC_TAPID
+} else {
+   set _SJC_TAPID 0x0190c01d
+}
+
+jtag newtap $_CHIPNAME SJC -irlen 5 -ircapture 0x1 -irmask 0x1f \
+-expected-id $_SJC_TAPID -ignore-version
+
+# GDB target:  Cortex-A8, using DAP
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.DAP
+
+# some TCK tycles are required to activate the DEBUG power domain
+jtag configure $_CHIPNAME.SJC -event post-reset runtest 100
+
+# have the DAP always be active
+jtag configure $_CHIPNAME.SJC -event setup jtag tapenable $_CHIPNAME.DAP
+
+proc imx51_dbginit {target} {
+ # General Cortex A8 debug initialisation
+ cortex_a8 dbginit
+}
+
+# Slow speed to be sure it will work
+jtag_rclk 1000
+$_TARGETNAME configure -event reset-start { jtag_rclk 1000 }
+
+$_TARGETNAME configure -event reset-assert-post imx51_dbginit $_TARGETNAME
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 5/5 RESEND] Add EfikaMX smarttop board support

[Marek Vasut]

This patch finally adds support for i.MX51 based Genesi USA EfikaMX smarttop
board.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 tcl/board/efikamx.cfg |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)
 create mode 100644 tcl/board/efikamx.cfg

diff --git a/tcl/board/efikamx.cfg b/tcl/board/efikamx.cfg
new file mode 100644
index 000..f8ae25d
--- /dev/null
+++ b/tcl/board/efikamx.cfg
@@ -0,0 +1,9 @@
+# Genesi USA EfikaMX
+#  http://www.genesi-usa.com/products/efika
+
+# Fall back to 6MHz if RTCK is not supported
+jtag_rclk 6000
+
+source [find target/imx51.cfg]
+
+reset_config trst_only
-- 
1.7.2.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant

[Marek Vasut]

On Sunday 31 October 2010 13:16:43 Øyvind Harboe wrote:
 On Sun, Oct 31, 2010 at 10:59 AM, David Brownell davi...@pacbell.net wrote:
  I think caring about the variant should strongly
  be avoided.  Use the ROM table by default.  Only in
  the case of a broken ROM table should we (a) emit
  a message, then (b) work around the brokenness.
  Such working-around might care about variant, if wecan't
 
 come up with a simple heuristic fix.
 

Would you mind not dropping me from the CC ? Thanks

 It would be great if we could detect the one broken chip
 out there and simply add a workaround(with warning).

Implemented in V2, which should have just landed in the mailing list ... Peter, 
David, sorry for not CCing you, next time, you'll be there (well, I hope there 
will be no next time and that the patches are good :) ).
 
 I'd suppose such bugs would be much less common with
 more recent Cortex A8 chips.

I hope so as well
 
 Adding options is the last resort as it makes OpenOCD harder
 to use and gives it a more unfinished feeling. This is open source.
 If there is a chance that we might need to add support for a new
 CPU in the future, then we don't add some option in the hope that
 it can work around the next bug, we just add the workaround when
 and if that time comes.

So can you please check the V2s ? Thanks !
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant

[Marek Vasut]

On Saturday 30 October 2010 07:24:08 Marek Vasut wrote:
 On Friday 29 October 2010 09:37:36 Øyvind Harboe wrote:
   Oyvind sorry, I just can't find it ... could you tell me where it is
   please ?
  
  Start here:
  
  https://lists.berlios.de/pipermail/openocd-development/2010-September/016
  48 2.html
 
 Hey,
 
 I went through all of this stuff tonight ... and I came to a conclusion,
 that MEM-AP contains register called BASE whose top 20 bytes should
 contain the debug
 
 base address. From my observation, if I run:
  dap info 1
 
 AP ID register 0x04770002
 Type is MEM-AP APB
 AP BASE 0x8000
 ROM table in legacy format
 CID3 0x00, CID2 0x00, CID1 0x00, CID0 0x00
 MEMTYPE System memory not present. Dedicated debug bus.
 ROMTABLE[0x0] = 0x0
 End of ROM table
 
 I get no data. Though if I artificially adjust the dbgbase to 0x6000 in
 arm_adi_v5.c, I get the following stuff. So, is the processor just making
 fun of me and misreporting the debug base or did I just miss something?
 This is what I get after the adjustment
 
  dap info 1
 
 AP ID register 0x04770002
 Type is MEM-AP APB
 AP BASE 0x6000
 ROM table in legacy format
 CID3 0xb1, CID2 0x05, CID1 0x10, CID0 0x0d
 MEMTYPE System memory not present. Dedicated debug bus.


--SNIP--

So it turns out (by reading Freescale iMX515 errata), ENGcm09395 to be exact 
that the chip misreports the ROM Table address (it reports 0x8000_, but it 
should report 0x6000_). On the other hand, the contents of the ROM Table is 
then correct.

Oyvind, this technically makes the autodetection complementary to manual 
approach. There is a solution I see now -- implement the autodetection, which 
will work on most chips (modulo iMX515 ...) and add an option to manually 
specify the ROM Table base.

But that being the case, I'd prefer to make an incremental patch on top of the 
patches I submitted.

Cheers
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant

[Marek Vasut]

On Friday 29 October 2010 07:43:18 Peter Stuge wrote:
 Marek Vasut wrote:
  In this patch, I introduce the use of -variant parameter, so I can
  adjust the debug_base accordingly.
 
 This seems completely wrong to me. I think this logic should just
 stay in Tcl. So if anything, you would add a parameter for dap_base.


That's what I wanted to do, but I'm still starting to get familiar with OpenOCD 
again. Could you point me in a direction please? 
 
 //Peter
 ___
 Openocd-development mailing list
 Openocd-development@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant

[Marek Vasut]

On Friday 29 October 2010 08:18:46 Marek Vasut wrote:
  On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut
  
  marek.vasut.n...@gmail.com wrote:
On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut

marek.vasut.n...@gmail.com wrote:
  Shouldn't this be automatically detected?
 
 yes it should ... i'll send a patch on top of this one once I
 figure out how to do it. Is that good enough approach for you?
 Or shall we put these on hold until then?

I would definitely like the autodetect to go in first, then the
patches can be simplified.
   
   You've got a point here, but I really don't know how much time will
   that take, though I'll look into it probably even today. I'd
   appreciate any hints on this.
  
  Zach made some postings in the not to distant path to the list
  about this subject.
 
 thanks! i'll look once I arive at university ... I just left dorms and I'm
 going for a bus :b

Oyvind sorry, I just can't find it ... could you tell me where it is please ?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant

[Marek Vasut]

On Friday 29 October 2010 09:37:36 Øyvind Harboe wrote:
  Oyvind sorry, I just can't find it ... could you tell me where it is
  please ?
 
 Start here:
 
 https://lists.berlios.de/pipermail/openocd-development/2010-September/01648
 2.html

Hey,

I went through all of this stuff tonight ... and I came to a conclusion, that 
MEM-AP contains register called BASE whose top 20 bytes should contain the 
debug 
base address. From my observation, if I run:

 dap info 1
AP ID register 0x04770002
Type is MEM-AP APB
AP BASE 0x8000
ROM table in legacy format
CID3 0x00, CID2 0x00, CID1 0x00, CID0 0x00
MEMTYPE System memory not present. Dedicated debug bus.
ROMTABLE[0x0] = 0x0
End of ROM table

I get no data. Though if I artificially adjust the dbgbase to 0x6000 in 
arm_adi_v5.c, I get the following stuff. So, is the processor just making fun 
of 
me and misreporting the debug base or did I just miss something? This is what I 
get after the adjustment

 dap info 1
AP ID register 0x04770002
Type is MEM-AP APB
AP BASE 0x6000
ROM table in legacy format
CID3 0xb1, CID2 0x05, CID1 0x10, CID0 0x0d
MEMTYPE System memory not present. Dedicated debug bus.
ROMTABLE[0x0] = 0x1003
Component base address 0x60001000, start address 0x60001000
Component class is 0x9, CoreSight component
Type is 0x21, Trace Sink, Buffer
Peripheral ID[4..0] = hex 04 00 0b b9 07
Part is Coresight ETB (Trace Buffer)
ROMTABLE[0x4] = 0x2003
Component base address 0x60002000, start address 0x60002000
Component class is 0x9, CoreSight component
Type is 0x13, Trace Source, Processor
Peripheral ID[4..0] = hex 04 10 4b b9 21
Part is Cortex-A8 ETM (Embedded Trace)
ROMTABLE[0x8] = 0x3003
Component base address 0x60003000, start address 0x60003000
Component class is 0x9, CoreSight component
Type is 0x11, Trace Sink, Port
Peripheral ID[4..0] = hex 04 00 4b b9 12
Part is Coresight TPIU (Trace Port Interface Unit)
ROMTABLE[0xc] = 0x4003
Component base address 0x60004000, start address 0x60004000
Component class is 0x9, CoreSight component
Type is 0x14, Debug Control, Trigger Matrix
Peripheral ID[4..0] = hex 04 10 4b b9 22
Part is Cortex-A8 CTI (Cross Trigger)
ROMTABLE[0x10] = 0x5003
Component base address 0x60005000, start address 0x60005000
Component class is 0x9, CoreSight component
Type is 0x14, Debug Control, Trigger Matrix
Peripheral ID[4..0] = hex 04 00 0b b9 06
Part is Coresight CTI (Cross Trigger)
ROMTABLE[0x14] = 0x6003
Component base address 0x60006000, start address 0x60006000
Component class is 0x9, CoreSight component
Type is 0x14, Debug Control, Trigger Matrix
Peripheral ID[4..0] = hex 04 00 0b b9 06
Part is Coresight CTI (Cross Trigger)
ROMTABLE[0x18] = 0x7003
Component base address 0x60007000, start address 0x60007000
Component class is 0x9, CoreSight component
Type is 0x14, Debug Control, Trigger Matrix
Peripheral ID[4..0] = hex 04 00 0b b9 06
Part is Coresight CTI (Cross Trigger)
ROMTABLE[0x1c] = 0x8003
Component base address 0x60008000, start address 0x60008000
Component class is 0x9, CoreSight component
Type is 0x15, Debug Logic, Processor
Peripheral ID[4..0] = hex 04 10 4b bc 08
Part is Cortex-A8 Debug (Debug Unit)
ROMTABLE[0x20] = 0x0
End of ROM table
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 3/3] Add EfikaMX smarttop board support

[Marek Vasut]

This patch finally adds support for i.MX51 based Genesi USA EfikaMX smarttop
board.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 tcl/board/efikamx.cfg |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)
 create mode 100644 tcl/board/efikamx.cfg

diff --git a/tcl/board/efikamx.cfg b/tcl/board/efikamx.cfg
new file mode 100644
index 000..f8ae25d
--- /dev/null
+++ b/tcl/board/efikamx.cfg
@@ -0,0 +1,9 @@
+# Genesi USA EfikaMX
+#  http://www.genesi-usa.com/products/efika
+
+# Fall back to 6MHz if RTCK is not supported
+jtag_rclk 6000
+
+source [find target/imx51.cfg]
+
+reset_config trst_only
-- 
1.7.1

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant

[Marek Vasut]

In this patch, I introduce the use of -variant parameter, so I can adjust the
debug_base accordingly.

So far, only the OMAP3530 and AM/DM37x CPUs, which utilize the Cortex A8 core
are supported by OpenOCD and both of these use the same Cortex A8 Debug Access
Port address (0x54011000).

There are other CPU manufacturers, who use different address for the Cortex A8
Debug Access Port though. As I was unable to figure out a way to detect the
address of DAP, this should at least work around the problem until there is a
proper solution.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 src/target/cortex_a8.c  |   11 ++-
 tcl/target/amdm37x.cfg  |3 ++-
 tcl/target/omap3530.cfg |3 ++-
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 8b4ced5..64b78bd 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -1719,7 +1719,16 @@ static int cortex_a8_examine_first(struct target *target)
LOG_DEBUG(TODO - autoconfigure);
 
/* Here we shall insert a proper ROM Table scan */
-   armv7a-debug_base = OMAP3530_DEBUG_BASE;
+   if (strcmp(target-variant, amdm37x) == 0)
+   armv7a-debug_base = OMAP3530_DEBUG_BASE;
+   else if (strcmp(target-variant, omap3530) == 0)
+   armv7a-debug_base = OMAP3530_DEBUG_BASE;
+   else {
+   LOG_DEBUG(Unknown CPU variant);
+   return ERROR_FAIL;
+   }
+
+   LOG_DEBUG(Using Cortex A8, %s variant, target-variant);
 
/* We do one extra read to ensure DAP is configured,
 * we call ahbap_debugport_init(swjdp) instead
diff --git a/tcl/target/amdm37x.cfg b/tcl/target/amdm37x.cfg
index ab18681..3776435 100644
--- a/tcl/target/amdm37x.cfg
+++ b/tcl/target/amdm37x.cfg
@@ -142,7 +142,8 @@ jtag configure $_CHIPNAME.jrc -event setup jtag tapenable 
$_CHIPNAME.dap
 
 # Create the CPU target to be used with GDB:  Cortex-A8, using DAP
 set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
+target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap \
+   -variant amdm37x
 
 # The DM37x has 64K of SRAM starting at address 0x4020_.  Allow the first
 # 16K to be used as a scratchpad for OpenOCD.
diff --git a/tcl/target/omap3530.cfg b/tcl/target/omap3530.cfg
index ba130a9..e7b598f 100644
--- a/tcl/target/omap3530.cfg
+++ b/tcl/target/omap3530.cfg
@@ -36,7 +36,8 @@ jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 
0x3f \
 
 # GDB target:  Cortex-A8, using DAP
 set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
+target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap \
+   -variant omap3530
 
 # SRAM: 64K at 0x4020.; use the first 16K
 $_TARGETNAME configure -work-area-phys 0x4020 -work-area-size 0x4000
-- 
1.7.1

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Failed to receiving data from debug handler after 1000 - using jtag-tiny with colibri PXA320

[Marek Vasut]

On Monday 25 October 2010 11:38:53 Moshe Artzi wrote:
 Hi Marek,
 
 Sorry for the interrupt but,
 I'm still can't make this thing work.
 
 After nand the image I get this error:
 Failed to receiving data from debug handler after 1000 attempts Command
 handler execution failed in procedure 'resume'
 
 From my understanding, this is timing issue between the PXA320 and the Jtag
 but, I can't find the parameter/s that can cause this problem.
 
 
 Here is command line session  print screen:
 
 Open On-Chip Debugger 0.5.0-dev-snapshot (2010-10-25-09:14)
 Licensed under GNU GPL v2
 For bug reports, read
 http://openocd.berlios.de/doc/doxygen/bugs.html
 Info : only one transport option; autoselect 'jtag'
 adapter_nsrst_delay: 260
 jtag_ntrst_delay: 250
 Info : colibri_pxa320.cpu: hardware has 2 breakpoints and 2 watchpoints
 adapter_nsrst_delay: 2000
 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
 200 kHz
 Info : device: 4 2232C
 Info : deviceID: 67358712
 Info : SerialNumber: T1TA5HKBA
 Info : Description: Amontec JTAGkey A
 Info : clock speed 200 kHz
 Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg:
 0x009, part: 0xe642, ver: 0x7) Info : accepting 'telnet' connection from
 
 Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg:
 0x009, part: 0xe642, ver: 0x7) target state: halted
 target halted in ARM state due to debug-request, current mode: Supervisor
 cpsr: 0xf8d3 pc: 0x
 MMU: disabled, D-Cache: disabled, I-Cache: disabled
 (processor reset)
 1472 bytes written at address 0x5c04
 downloaded 1472 bytes in 0.094000s (15.293 KiB/s)
 Error: Failed to receiving data from debug handler after 1000 attempts
 Command handler execution failed
 in procedure 'resume'
 
 
 Here is telnet session print screen:
 
 Open On-Chip Debugger
 
  reset halt ;load_image iplntim.bin 0x5c04 ;resume 0x5c04
 
 JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009,
 part: 0xe642, ver: 0x7) target state: halted
 target halted in ARM state due to debug-request, current mode: Supervisor
 cpsr: 0xf8d3 pc: 0x
 MMU: disabled, D-Cache: disabled, I-Cache: disabled
 (processor reset)
 1472 bytes written at address 0x5c04
 downloaded 1472 bytes in 0.094000s (15.293 KiB/s)
 Failed to receiving data from debug handler after 1000 attempts
 Command handler execution failed
 in procedure 'resume'
 
 
 I'm getting frustrated !!! ;(

Hey, sorry ... I really don't know how to help you. It looks like the core 
halted, but it won't start at the specified address.

For me, it always helped to powerdown and power-up the board.

Sorry once again
 
 Any assist will be blessed,
 
 Thanks,
 
 Moshe.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD on colibri PXA 320 With Amontec tiny JTAG issue

[Marek Vasut]

Dne Čt 21. října 2010 11:46:46 Moshe Artzi napsal(a):
 Hi,
 
 After trying every possible option, using the last OpenOCD version and
 applied all the OpenOCD patches I got to this situation:
 
 **This is the commandLine:
 
 C:\Program Files\OpenOCDopenocd
 Open On-Chip Debugger 0.5.0-dev-snapshot (2010-10-21-10:24)
 Licensed under GNU GPL v2
 For bug reports, read
 http://openocd.berlios.de/doc/doxygen/bugs.html
 Info : only one transport option; autoselect 'jtag'
 adapter_nsrst_delay: 260
 jtag_ntrst_delay: 250
 Info : colibri_pxa320.cpu: hardware has 2 breakpoints and 2 watchpoints
 adapter_nsrst_delay: 800
 trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
 adapter_nsrst_assert_width: 40
 adapter_nsrst_delay: 1500
 2000 kHz
 Info : device: 4 2232C
 Info : deviceID: 67358712
 Info : SerialNumber: T1TA5HKBA
 Info : Description: Amontec JTAGkey A
 Info : clock speed 2000 kHz
 Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg:
 0x009, part: 0xe642, ver: 0x7)
 
 
 **This is the telnet:
 
 Open On-Chip Debugger
 
  nand list
 
 #0: not probed
 
  nand probe 0
 
 TIMEOUT waiting for NDSR mask 0100 ; NDSR = 0001
 
 TIMEOUT waiting for NDSR mask 0100 ; NDSR = 0001
 
 TIMEOUT waiting for NDSR mask 0002 ; NDSR = 0001
 
 unknown NAND flash device found, manufacturer id: 0xff device id: 0xe7
 Command handler execution failed
 in procedure 'nand'
 
 
 Can't find what is wrong with this nand memory!!!
 In the command line it recognized but when I'm trying to probe it fails
 because of TIMEOUTS.

I told you the NAND driver is buggy and that you should really use uboot to 
reflash. Any fixes for this nand driver are welcome though.

Cheers
 
 Any assist will be welcome.
 
 Thanks,
 
 Moshe.
 
 -Original Message-
 From: Moshe Artzi [mailto:mosh...@niron-sys.com]
 Sent: Thursday, October 21, 2010 9:51 AM
 To: 'Marek Vasut'
 Cc: 'Takács Áron'; 'Gena Chap'; 'openpxa-us...@lists.sourceforge.net';
 'openocd-development@lists.berlios.de'; 'Øyvind Harboe' Subject: RE:
 OpenOCD on colibri PXA 320 With Amontec tiny JTAG issue
 
 
 Thank you for your reply,
 
 I will give it a try and will let you know how is going.
 
 Thank you,
 
 Moshe.
 
 -Original Message-
 From: Marek Vasut [mailto:marek.va...@gmail.com]
 Sent: Wednesday, October 20, 2010 6:49 PM
 To: Moshe Artzi
 Cc: 'Takács Áron'; 'Gena Chap'; openpxa-us...@lists.sourceforge.net;
 openocd-development@lists.berlios.de; Øyvind Harboe Subject: Re: OpenOCD
 on colibri PXA 320 With Amontec tiny JTAG issue
 
 Dne St 20. října 2010 18:41:47 Moshe Artzi napsal(a):
  Hehehehe,
  
  Yepp, I compiled it in Cygwin for WIN32  ;)
  
  Thank you very much for your reply,
  
  It's OpenOCD Ver 0.4.0 (the last release I found (,
  I hope I'm not missing something on the way,
  There are only 3 PXA320 patches for OpenOCD am I right?
  
  I just can't find the correct NAND driver for this NAND (SAMSUNG
  K9K8G08U0B) chip.
 
 It doesn't matter which chip you use, you have to use the pxa3xx_nand
 driver. The chip is more or less autodetected.
 
 Here's the git repo for openocd
 git://openocd.git.sourceforge.net/gitroot/openocd/openocd
 
  Thanks,
  Moshe.
  
  -Original Message-
  From: Marek Vasut [mailto:marek.va...@gmail.com]
  Sent: Wednesday, October 20, 2010 6:26 PM
  To: Moshe Artzi
  Cc: 'Takács Áron'; 'Gena Chap'; openpxa-us...@lists.sourceforge.net
  Subject: Re: OpenOCD on colibri PXA 320 With Amontec tiny JTAG issue
  
  Dne St 20. října 2010 16:39:00 Moshe Artzi napsal(a):
   Hi there again,
   
   I'm facing an issue when I'm trying to nand the u-boot image to the
   colibri's PXA320,
   
   I applied the PXA 320 patches for openocd,
  
   But when I'm connecting to the target using the Jtag I get this message:
  Hi, you should use newer version of OpenOCD . Either way though, the NAND
  driver is a bit broken (someone should really fix it). You also need to
  add the driver into the configuration file.
  
  Btw. you compiled OpenOCD on windows ? yikes
  
   C:\Program Files\OpenOCDopenocd.exe
   Open On-Chip Debugger 0.4.0 (2010-10-20-14:49)
   Licensed under GNU GPL v2
   For bug reports, read
   
   http://openocd.berlios.de/doc/doxygen/bugs.html
   
   jtag_nsrst_delay: 260
   jtag_ntrst_delay: 250
   Info : colibri_pxa320.cpu: hardware has 2 breakpoints and 2 watchpoints
   jtag_nsrst_delay: 800
   trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
   Error: No valid NAND flash driver found (pxa3xx)
   
   Available NAND flash controller drivers:
 nonce
 davinci
 lpc3180
 orion
 s3c2410
 s3c2412
 s3c2440
 s3c2443
 s3c6400
 imx31
 at91sam9
   
   Info : device: 4 2232C
   Info : deviceID: 67358712
   Info : SerialNumber: T1TA5HKBA
   Info : Description: Amontec JTAGkey A
   Info : clock speed 6000 kHz
   Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg

Re: [Openocd-development] OpenOCD on colibri PXA 320 With Amontec tiny JTAG issue

[Marek Vasut]

Dne St 20. října 2010 18:41:47 Moshe Artzi napsal(a):
 Hehehehe,
 
 Yepp, I compiled it in Cygwin for WIN32  ;)
 
 Thank you very much for your reply,
 
 It's OpenOCD Ver 0.4.0 (the last release I found (,
 I hope I'm not missing something on the way,
 There are only 3 PXA320 patches for OpenOCD am I right?
 
 I just can't find the correct NAND driver for this NAND (SAMSUNG
 K9K8G08U0B) chip.

It doesn't matter which chip you use, you have to use the pxa3xx_nand driver. 
The chip is more or less autodetected.

Here's the git repo for openocd 
git://openocd.git.sourceforge.net/gitroot/openocd/openocd
 
 Thanks,
 Moshe.
 
 -Original Message-
 From: Marek Vasut [mailto:marek.va...@gmail.com]
 Sent: Wednesday, October 20, 2010 6:26 PM
 To: Moshe Artzi
 Cc: 'Takács Áron'; 'Gena Chap'; openpxa-us...@lists.sourceforge.net
 Subject: Re: OpenOCD on colibri PXA 320 With Amontec tiny JTAG issue
 
 Dne St 20. října 2010 16:39:00 Moshe Artzi napsal(a):
  Hi there again,
  
  I'm facing an issue when I'm trying to nand the u-boot image to the
  colibri's PXA320,
  
  I applied the PXA 320 patches for openocd,
 
  But when I'm connecting to the target using the Jtag I get this message:
 Hi, you should use newer version of OpenOCD . Either way though, the NAND
 driver is a bit broken (someone should really fix it). You also need to
 add the driver into the configuration file.
 
 Btw. you compiled OpenOCD on windows ? yikes
 
  C:\Program Files\OpenOCDopenocd.exe
  Open On-Chip Debugger 0.4.0 (2010-10-20-14:49)
  Licensed under GNU GPL v2
  For bug reports, read
  
  http://openocd.berlios.de/doc/doxygen/bugs.html
  
  jtag_nsrst_delay: 260
  jtag_ntrst_delay: 250
  Info : colibri_pxa320.cpu: hardware has 2 breakpoints and 2 watchpoints
  jtag_nsrst_delay: 800
  trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
  Error: No valid NAND flash driver found (pxa3xx)
  
  Available NAND flash controller drivers:
nonce
davinci
lpc3180
orion
s3c2410
s3c2412
s3c2440
s3c2443
s3c6400
imx31
at91sam9
  
  Info : device: 4 2232C
  Info : deviceID: 67358712
  Info : SerialNumber: T1TA5HKBA
  Info : Description: Amontec JTAGkey A
  Info : clock speed 6000 kHz
  Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg:
  0x009, part: 0xe642, ver: 0x7)
  
  My openocd.cfg file is:
  
  source [find interface/jtagkey-tiny.cfg]
  source [find target/colibri_pxa320.cfg]
  
  Any help will be appreciated,
  
  Thanks,
  
  Moshe Artzi
  Software engineer
  
  Niron systems
  Tel : 09-7407626
  Ex : 104
  Fax: 09-8651510
  Mobile : 050-3356312
  Email : mosh...@niron-sys.com
  Site: www.niron-sys.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] U-Boot on PXA 320

[Marek Vasut]

Dne St 15. září 2010 13:28:56 Moshe Artzi napsal(a):
 Thanks for your fast reply,
 
 I invoked those commands and on both commands I get the same error message.
 
 Copy paste from the telnet console:
  reset halt; load_image iplntim.bin 0x5c04; resume 0x5c04
 
 JTAG tap: pxa3xx.cpu tap/device found: 0x6e642013 (mfg: 0x009, part:
 0xe642, ver: 0x6) BUG: can't assert SRST
 target state: halted
 target halted in ARM state due to debug-request, current mode: Supervisor
 cpsr: 0x08d3 pc: 0x
 MMU: disabled, D-Cache: disabled, I-Cache: disabled
 (processor reset)
 1472 bytes written at address 0x5c04
 downloaded 1472 bytes in 0.015625s (92.000 kb/s)
 Failed to receiving data from debug handler after 1000 attempts
 Command handler execution failed
 in procedure 'resume' called at file command.c, line 650
 called at file command.c, line 361
 
  reset halt; load_image u-boot.bin 0x5c04;resume 0x5c04
 
 JTAG tap: pxa3xx.cpu tap/device found: 0x6e642013 (mfg: 0x009, part:
 0xe642, ver: 0x6) BUG: can't assert SRST
 target state: halted
 target halted in ARM state due to debug-request, current mode: Supervisor
 cpsr: 0x88d3 pc: 0x
 MMU: disabled, D-Cache: disabled, I-Cache: disabled
 (processor reset)
 205620 bytes written at address 0x5c04
 downloaded 205620 bytes in 1.00s (200.801 kb/s)
 Failed to receiving data from debug handler after 1000 attempts
 Command handler execution failed
 in procedure 'resume' called at file command.c, line 650
 called at file command.c, line 361
 

There was something similar on OpenOCD mailing list, CCing.

Check Re: [Openocd-development] PXA question in their mailing list archive.

btw. I have this weird hack applied on my openocd, but it's certainly incorrect 
:) It helped me with some issues some time ago:

diff --git a/src/target/xscale.c b/src/target/xscale.c
index 7cdff21..45e5b9a 100644
--- a/src/target/xscale.c
+++ b/src/target/xscale.c
@@ -759,6 +759,7 @@ static int xscale_update_vectors(struct target *target)
}
else
{
+   continue;
retval = target_read_u32(target, 0x + 4*i, 
xscale-high_vectors[i]);
if (retval == ERROR_TARGET_TIMEOUT)
return retval;
@@ -778,6 +779,7 @@ static int xscale_update_vectors(struct target *target)
}
else
{
+   continue;
retval = target_read_u32(target, 0x0 + 4*i, xscale-
low_vectors[i]);
if (retval == ERROR_TARGET_TIMEOUT)
return retval;

 
 Seems like the download process failed
 any ideas what can cause this failure ?
 
 Thanks,
 Moshe.
 
 -Original Message-
 From: Marek Vasut [mailto:marek.va...@gmail.com]
 Sent: Wednesday, September 15, 2010 12:34 PM
 To: Moshe Artzi
 Cc: Gena Chap; openpxa-us...@lists.sourceforge.net
 Subject: Re: U-Boot on PXA 320
 
 Dne St 15. září 2010 12:18:58 Moshe Artzi napsal(a):
  Hi Marek, thank you for your reply,
  
  I decided to go with the OpenOCD solution you suggested me,
  I got OpenOCD working and I'm able to communicate with the flash memory
  and cpu using the jtag by telnet.
  
  But now the command  nand list is not working so I can't perform the
  probe command in order to nand (flash) The PXA 320 Memory with the
  iplntim.bin and u-boot.bin,
 
 Well, load iplntim.bin into SRAM and execute it. (reset halt ; load_image
 iplntim.bin 0x5c04 ; resume 0x5c04).
 
 Then load uboot the same way (reset halt; load_image uboot.bin 0x5c04;
 resume 0x5c04).
 
 Between these two steps, you must not power-cycle the board. Once done,
 uboot should appear on the screen. Then you can reflash using uboot.
 
 To download the files faster, run this in openocd right after uboot is
 running:
 
 halt; load_image iplntim.bin 0xa000 ; load_image 0xa002 ; resume
 
 And then in uboot:
 
 nand scrub ; nand erase 0x0 0x6 ; nand write 0xa000 0x0 0x6
 
 Should work.
 
 Also please keep CC so people wont go asking me this question again and
 again
 
  Are there any steps I have to perform before invoking the nand list
  command?
  
  Any help will be appreciated,
  
  Thanks a lot,
  
  Moshe.
  
  -Original Message-
  From: Marek Vasut [mailto:marek.va...@gmail.com]
  Sent: Tuesday, September 14, 2010 10:47 AM
  To: Moshe Artzi
  Cc: Gena Chap; openpxa-us...@lists.sourceforge.net
  Subject: Re: U-Boot on PXA 320
  
  Dne Út 14. září 2010 10:24:45 Moshe Artzi napsal(a):
   Hi Marek,
  
  Hi,
  
   I'm Moshe - S/W engineer
   
   
   
   I'm using Toradex Colibri PXA 320 CPU on Colibri Evaluation Board Rev
   .2.1.
   
   
   
   I'm trying to run the U-Boot version,
   
   After I'm flash the Memory with the files iplntim.bin(in address
   0x) and u-boot.bin(in address 0x0002),
   
   according to the ReadMe file, the U-Boot

Re: [Openocd-development] PXA question

[Marek Vasut]

Dne Po 6. září 2010 08:50:09 Takács Áron napsal(a):
 Hello,

Hi, keep the CC please
 
 thanks for the answers of Wookey and Marek!
 You are right, marek, there are buffers on the board. I have tried to
 increase the reset delays (jtag_nsrst_delay, jtag_ntrst_delay 250) and
 also the timeout value in xscale.c:409 and :499, but the situation
 remained the same.
 Any ideas what to try now? Thank you!

You use colibri board, right? Either try a different JTAG adapter or connect 
yours directly to the CPU card (there's that white strap connecting the JTAG on 
the card to the board ... you can use that to tap directly on the CPU JTAG 
pins).

Cheers
 
 Áron
 
 2010-09-03 21:44 keltezéssel, Marek Vasut írta:
  Dne Pá 3. září 2010 16:46:59 Wookey napsal(a):
  +++ Takács Áron [2010-09-03 16:15 +0200]:
  Hi,
  
  I want to use openocd to reflash PXA270 board (Colibri by Toradex). I
  am using JTAGKey-Tiny interface (by Amontec). I can connect the board
  but I always get the error message:
  'time out writing RX register'. Here is the output for 'reset' and
  
  'flash info 0':
  We've used openocd with amontec jtagkey-tiny and pxa270 (balloonboard)
  successfully for some time now. It works since 0.3.1 and is also fine
  with 0.4. You might find it useful to compare your config with ours:
  http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd
  
  we have at least one extra pxa CPUID which should be upstreamed:
  http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd/target/
  pxa 270updated.cfg
  
  but that's not going to make any difference, assuming you are seeing
  the device.
  
  The rest of the config looks OK to me, but I only checked quickly
  
  It might be the colibri board buffer logic that causes trouble. There are
  additional buffers on the baseboard.
  
  I use a custom FT2232 based dongle compatible with amontec jtagkey, but I
  heard people had trouble with original amontec dongles and colibri
  boards.
  
  reset
  
  JTAG tap: pxa270.cpu tap/device found: 0x79265013 (mfg: 0x009, part:
  0x9265, ver: 0x7)
  Failed to receiving data from debug handler after 1000 attempts
  time out writing RX register
  
  
  # set jtag_nsrst_delay to the delay introduced by your reset circuit
  # the rest of the needed delays are built into the openocd program
  jtag_nsrst_delay 260
  # set the jtag_ntrst_delay to the delay introduced by a reset circuit
  # the rest of the needed delays are built into the openocd program
  jtag_ntrst_delay 250
  
  Try upping these numbers? I know that Marvell parts have different
  timing to Intel parts in reset. Bit of a long short but worth a try.
  
  
  Wookey
  
  ___
  Openocd-development mailing list
  Openocd-development@lists.berlios.de
  https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] PXA question

[Marek Vasut]

Dne Po 6. září 2010 08:59:21 Takács Áron napsal(a):
 Thanky you, Marek!
 Yes I use a Colibri board. Bypassing the buffers needs some HW hacking
 but I'll try it. Thank you!
 
Keep the DAMNED CC !!

You don't need any hardware hacking, you can just connect the jtag to the CPU 
card directly, check the Toradex datasheets and schematics for more details.
 Áron
 
 2010-09-06 08:53 keltezéssel, Marek Vasut írta:
  Dne Po 6. září 2010 08:50:09 Takács Áron napsal(a):
  Hello,
  
  Hi, keep the CC please
  
  thanks for the answers of Wookey and Marek!
  You are right, marek, there are buffers on the board. I have tried to
  increase the reset delays (jtag_nsrst_delay, jtag_ntrst_delay 250) and
  also the timeout value in xscale.c:409 and :499, but the situation
  remained the same.
  Any ideas what to try now? Thank you!
  
  You use colibri board, right? Either try a different JTAG adapter or
  connect yours directly to the CPU card (there's that white strap
  connecting the JTAG on the card to the board ... you can use that to tap
  directly on the CPU JTAG pins).
  
  Cheers
  
  Áron
  
  2010-09-03 21:44 keltezéssel, Marek Vasut írta:
  Dne Pá 3. září 2010 16:46:59 Wookey napsal(a):
  +++ Takács Áron [2010-09-03 16:15 +0200]:
  Hi,
  
  I want to use openocd to reflash PXA270 board (Colibri by Toradex). I
  am using JTAGKey-Tiny interface (by Amontec). I can connect the board
  but I always get the error message:
  'time out writing RX register'. Here is the output for 'reset' and
  
  'flash info 0':
  We've used openocd with amontec jtagkey-tiny and pxa270 (balloonboard)
  successfully for some time now. It works since 0.3.1 and is also fine
  with 0.4. You might find it useful to compare your config with ours:
  http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd
  
  we have at least one extra pxa CPUID which should be upstreamed:
  http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd/targe
  t/ pxa 270updated.cfg
  
  but that's not going to make any difference, assuming you are seeing
  the device.
  
  The rest of the config looks OK to me, but I only checked quickly
  
  It might be the colibri board buffer logic that causes trouble. There
  are additional buffers on the baseboard.
  
  I use a custom FT2232 based dongle compatible with amontec jtagkey, but
  I heard people had trouble with original amontec dongles and colibri
  boards.
  
reset
  
  JTAG tap: pxa270.cpu tap/device found: 0x79265013 (mfg: 0x009, part:
  0x9265, ver: 0x7)
  Failed to receiving data from debug handler after 1000 attempts
  time out writing RX register
  
  
  # set jtag_nsrst_delay to the delay introduced by your reset circuit
  # the rest of the needed delays are built into the openocd program
  jtag_nsrst_delay 260
  # set the jtag_ntrst_delay to the delay introduced by a reset circuit
  # the rest of the needed delays are built into the openocd program
  jtag_ntrst_delay 250
  
  Try upping these numbers? I know that Marvell parts have different
  timing to Intel parts in reset. Bit of a long short but worth a try.
  
  
  Wookey
  
  ___
  Openocd-development mailing list
  Openocd-development@lists.berlios.de
  https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] PXA question

[Marek Vasut]

Dne Pá 3. září 2010 16:46:59 Wookey napsal(a):
 +++ Takács Áron [2010-09-03 16:15 +0200]:
  Hi,
  
  I want to use openocd to reflash PXA270 board (Colibri by Toradex). I am
  using JTAGKey-Tiny interface (by Amontec). I can connect the board but I
  always get the error message:
  'time out writing RX register'. Here is the output for 'reset' and
 
  'flash info 0':
 We've used openocd with amontec jtagkey-tiny and pxa270 (balloonboard)
 successfully for some time now. It works since 0.3.1 and is also fine
 with 0.4. You might find it useful to compare your config with ours:
 http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd
 
 we have at least one extra pxa CPUID which should be upstreamed:
 http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd/target/pxa
 270updated.cfg
 
 but that's not going to make any difference, assuming you are seeing
 the device.
 
 The rest of the config looks OK to me, but I only checked quickly

It might be the colibri board buffer logic that causes trouble. There are 
additional buffers on the baseboard.

I use a custom FT2232 based dongle compatible with amontec jtagkey, but I heard 
people had trouble with original amontec dongles and colibri boards.
 
reset
  
  JTAG tap: pxa270.cpu tap/device found: 0x79265013 (mfg: 0x009, part:
  0x9265, ver: 0x7)
  Failed to receiving data from debug handler after 1000 attempts
  time out writing RX register
  
  
  # set jtag_nsrst_delay to the delay introduced by your reset circuit
  # the rest of the needed delays are built into the openocd program
  jtag_nsrst_delay 260
  # set the jtag_ntrst_delay to the delay introduced by a reset circuit
  # the rest of the needed delays are built into the openocd program
  jtag_ntrst_delay 250
 
 Try upping these numbers? I know that Marvell parts have different
 timing to Intel parts in reset. Bit of a long short but worth a try.
 
 
 Wookey
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] ULink

[Marek Vasut]

Dne Po 30. srpna 2010 22:23:25 gla...@hotmail.de napsal(a):
 Hi guy's
 
 I was thinking about to get the segger jlink or the ulink2. But since I
 only found the cfg File for JLink I was wondering wheter uLink2 is
 supported or not.
 
 thx

Hi, what chipset is used in it?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] ./configure --enable-maintainer-mode LIBS=-lfoo-1.0 not working?

[Marek Vasut]

Dne St 2. června 2010 18:35:40 Martin Zenzes napsal(a):
 Hi,
 
 when I do
 
 ./configure LDFLAGS=-L/opt/libftdi-1.0 LIBS=-lftdi-1.0
 --enable-maintainer-mode
 
 with recent git (d944a0b) , I'm getting an error:
 
 configure: error: C compiler cannot create executables
 
 after removing the -1.0 part of LIBS, everything is fine, but openocd
 selects the wrong version of the ftdi-library.
 
 I can compile openOCD with my custom libftdi-version by replacing
 LIBS and LDFLAGS using sed in every Makefile after a normal run
 of ./configure.
 
 This seems to be a bug in configure?

Or maybe a bug in your autotools ?
 
 Greetings
 Martin
 
 ___
 Openocd-development mailing list
 Openocd-development@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD

[Marek Vasut]

Dne Po 31. května 2010 09:49:18 Mars Steeve napsal(a):
 Hi Marek,
 
 I finally received my JTAG KEY Tiny and successfully compiled OpenOCD 0.4.0
 with your patches.
 
 Unfortunately, I'm unable to flash or debug my board (colibri pxa320), the
 CPU is never halted.
 
 I post the result of reset halt.
 
 $ openocd -f interface/jtagkey-tiny.cfg -f board/colibri_pxa320.cfg
 
  reset halt
 
 JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009,
 part: 0xe642, ver: 0x7) Bad value '00' captured during DR or IR scan:
  check_value: 0x02
  check_mask: 0x07
 JTAG error while writing DCSR
 Bad value '00' captured during DR or IR scan:
  check_value: 0x02
  check_mask: 0x06
 JTAG error while reading TX
 error while polling TX register, reset CPU
 target state: halted
 target halted in ARM state due to target-not-halted, current mode: User
 cpsr: 0x pc: 0x
 MMU: disabled, D-Cache: disabled, I-Cache: disabled
 
 Thanks for your help!

I saw this with my vpaclink on Zylonite PXA320. By using the homemade JTAGkey, 
it worked. I assume there's a problem with not enough drive strength on some 
JTAG adapters. Maybe try adding a buffer past the adapter.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD

[Marek Vasut]

Dne Po 31. května 2010 16:19:23 Mars Steeve napsal(a):
 I don't think that it's an electrical problem, the jtagkey works fine with
 ColibriLoader software, except that it cannot upload more than 128KB
 (unable to flash an entire u-boot with flash support).
 
 I saw this with my vpaclink on Zylonite PXA320. By using the homemade
 JTAGkey, it worked. I assume there's a problem with not enough drive
 strength on some JTAG adapters. Maybe try adding a buffer past the
 adapter.

(just a note, please stop top-posting, post under the text you reply to)

Anyway ... Then we probably have an OpenOCD bug here. Maybe you can try 
tinkering with the jtag_nsrst_delay or reset_config stuff ?

I CCed more involved people.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] Add Voipac PXA270 module support

[Marek Vasut]

This patch adds support for the Voipac PXA270 module. Including NOR flash.

Signed-off-by: Marek Vasut marek.va...@gmail.com
---
 tcl/board/voipac.cfg |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)
 create mode 100644 tcl/board/voipac.cfg

diff --git a/tcl/board/voipac.cfg b/tcl/board/voipac.cfg
new file mode 100644
index 000..c59277e
--- /dev/null
+++ b/tcl/board/voipac.cfg
@@ -0,0 +1,12 @@
+# Config for Voipac PXA270/PXA270M module.
+
+set CHIPNAME voipac
+source [find target/pxa270.cfg]
+
+# The board supports separate reset lines
+# Override this in the interface config for parallel dongles
+reset_config trst_and_srst separate
+
+# flash bank driver base size chip_width bus_width
+flash bank $_CHIPNAME.flash0 cfi 0x 0x200 2 2 $_TARGETNAME
+flash bank $_CHIPNAME.flash1 cfi 0x0200 0x200 2 2 $_TARGETNAME
-- 
1.7.0

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] PXA270: can read/write the core registers, but can't read memory and registers of the devices on chip

[Marek Vasut]

Dne Pá 16. dubna 2010 09:45:09 Kaius Häggblom napsal(a):
 The JTAGkey-tiny dongle and board work OK, I have now successfully used
 the ColibriLoader software to download images to the board.
 
 ~kaius

Hey, 
firstly, please stop top-posting (aka post below the email you are replying to 
or into it if you have comments to specific stuff).
 
 Kaius Häggblom wrote:
  The attached trace was produced by starting program:
  ./src/openocd -s tcl -f board/colibri_pxa320.cfg -f nterface/jtagkey.cfg
  
   -d 3 -l openocd.lo
  
  ... and issuing following commands through telnet client:
reg
reset halt
reg cpsr 0xd3
reset halt
  
  Exactly as in original post with this issue on PXA270, writing and
  reading regs work OK, but anything else fails.
  
  ~kaius
  
  yvind Harboe wrote:
  I would strongly encourage someone who's familiar with these patches
  to repost them to this list so we can work on getting the changes
  merged.
  
  Should be in that projects and OpenOCD's interest...
  
  

Ok, about this issue, I noticed weird stuff:

My JTAGKey clone (FT2232 based with 74HC125 buffer and therefore 5V IO) works 
with:
PXA320 Toradex Colibri board -- the board moreover has an internal buffer logic 
between the JTAG pins and the CPU
PXA310 Marvell Littleton board -- the board has the JTAG pins connected 
directly 
to the CPU
PXA270 Voipac board -- Directly connected too

And it doesn't work with the same problems on PXA270 ZipitZ2 board. The only 
difference here from the Voipac board is the missing nSRST pin. Interestingly 
though, urJTAG works with this board with the same JTAG dongle.

So it puzzles me whether it's a hardware or software issue.

Cheers!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Have the NAND erase function use the nand page command

[Marek Vasut]

Dne Pá 18. prosince 2009 16:02:35 Dean Glazeski napsal(a):
 The increase happens because the NAND erase function was using 1000 for a
 timeout so I just increased the general timeout to that amount.  I don't
 think it should be a big deal because the timeout shouldn't happen
  normally.
 
 By the way, what is top-posting and how do I stop?
 
 // Dean Glazeski

Top-posting -- writing reply at the top of the mail that you're replying to. 
It's not a good practice and in many mailing lists, they'll not like it. So 
just 
stick the reply under it -- it's easier to read/follow -- I guess you get the 
point.

Anyway, about the timeout, you're probably right it shouldn't matter.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne Po 14. prosince 2009 21:55:25 David Brownell napsal(a):
 On Monday 14 December 2009, Marek Vasut wrote:
  Dne Po 14. prosince 2009 02:46:26 David Brownell napsal(a):
   On Sunday 13 December 2009, Marek Vasut wrote:
I'd send followup patch that'd clean that mess up altogether ... it's
cleaner and much easier to track back in git log.
  
   Go for it then.  :)
 
  Merge the erase patch then. :)
 
 Not till I see that followup patch ... ;)
 
Actually btw. what's your idea here? I kind-of lost track ...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne Po 14. prosince 2009 02:46:26 David Brownell napsal(a):
 On Sunday 13 December 2009, Marek Vasut wrote:
  I'd send followup patch that'd clean that mess up altogether ... it's
  cleaner and much easier to track back in git log.
 
 Go for it then.  :)
 
Merge the erase patch then. :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne Po 14. prosince 2009 21:55:25 David Brownell napsal(a):
 On Monday 14 December 2009, Marek Vasut wrote:
  Dne Po 14. prosince 2009 02:46:26 David Brownell napsal(a):
   On Sunday 13 December 2009, Marek Vasut wrote:
I'd send followup patch that'd clean that mess up altogether ... it's
cleaner and much easier to track back in git log.
  
   Go for it then.  :)
 
  Merge the erase patch then. :)
 
 Not till I see that followup patch ... ;)
 
You won't till I see this one in git ... ;)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne Ne 13. prosince 2009 06:36:47 David Brownell napsal(a):
 On Saturday 12 December 2009, Marek Vasut wrote:
   Also, can you restructure it so that you don't just add a bit
   if (there's a custom erase_page) { ... }?  That's the sort
   of thing which is easier to just require.
 
  Require? Why? No other driver probably needs it/will find it useful.
 
 To streamline and simplify the primary code paths.  It's better to
 
   ptr-op(...)
 
 than to
 
   if (ptr-op)
   ptr-op(...);
   else
   inlined default version ptr-op();
 
 Admittedly this is one of the ways the current source is less
 clean than it should be.  But that's not a reason to perpetuate
 such practices.
 
 - Dave
 
   Either provide the
   current logic in a separate routine that gets patched into the
   ops vector of any driver that doesn't have it, or ...
 
We can do so in one go in a separate patch if you want to do this kind of 
cleanup. That'd be cleaner solution.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne Ne 13. prosince 2009 21:06:32 David Brownell napsal(a):
 On Sunday 13 December 2009, Marek Vasut wrote:
 Either provide the
 current logic in a separate routine that gets patched into the
 ops vector of any driver that doesn't have it, or ...
 
  We can do so in one go in a separate patch if you want to do this kind of
  cleanup. That'd be cleaner solution.
 
 I won't be picky about how many patches it takes, but I'm
 not keen on merging this new feature *and* worsening that
 if (ptr-op) ...  mess.

Not my loss ...
 
 However, if you were to submit a followup to $PATCH that
 just addressed that point for this feature, I'd likely
 combine the two in one commit.  :)
 
I'd send followup patch that'd clean that mess up altogether ... it's cleaner 
and much easier to track back in git log.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne So 12. prosince 2009 00:41:48 Marek Vasut napsal(a):
 Hi,
 
 included is a patch that adds possibility to supply erase_page function in
  a driver, overriding the default behaviour of core.c
 
Hi, any updates ? Thanks
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne So 12. prosince 2009 22:39:43 David Brownell napsal(a):
 On Saturday 12 December 2009, Marek Vasut wrote:
  Dne So 12. prosince 2009 00:41:48 Marek Vasut napsal(a):
   included is a patch that adds possibility to supply erase_page function
   in a driver, overriding the default behaviour of core.c
 
  Hi, any updates ? Thanks
 
 I was wondering why to merge something that doesn't have any
 users ... :)

I have pxa3xx nand driver ready that will need this, preparing ground to deploy 
it.
 
 And was also curious what's wrong with the standard erase_page.
 Is this something that would be needed to support OneNAND, for
 example?

I need the whole page address when writing the command, not supplied in 
8bit/16bit values.
 
 - Dave
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne Ne 13. prosince 2009 03:25:07 David Brownell napsal(a):
 On Saturday 12 December 2009, Marek Vasut wrote:
   I was wondering why to merge something that doesn't have any
   users ... :)
 
  I have pxa3xx nand driver ready that will need this, preparing ground to
  deploy it.
 
 Mmkay...
 
   And was also curious what's wrong with the standard erase_page.
   Is this something that would be needed to support OneNAND, for
   example?
 
  I need the whole page address when writing the command, not supplied in
  8bit/16bit values.
 
 That information should be in the patch comment.
 
 Also, can you restructure it so that you don't just add a bit
 if (there's a custom erase_page) { ... }?  That's the sort
 of thing which is easier to just require.

Require? Why? No other driver probably needs it/will find it useful.
 Either provide the
 current logic in a separate routine that gets patched into the
 ops vector of any driver that doesn't have it, or (probably
 better) just export that routine and update all the NAND drivers
 to provide it.  (Better because we actually want to see all the
 driver structs be static const someday:  read-only.)
 
 That'll be easier to review too.
 
 
 - Dave
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne Ne 13. prosince 2009 05:21:36 Dean Glazeski napsal(a):
  Also, can you restructure it so that you don't just add a bit
  if (there's a custom erase_page) { ... }?  That's the sort
  of thing which is easier to just require.
 
 So, does this mean we restructure the entire NAND core to get rid of if
 (nand-function) {nand-function()} blocks for just about every read and
 write command?  Look at nand_read_page and nand_write_page.  They have that
 sort of logic.

Not only those ...
 
 // Dean Glazeski
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] NAND: breakage

[Marek Vasut]

Hi,

looks like the NAND isn't registered at all. I use the following (incorrect) 
patch to work it around FTTB.

diff --git a/src/flash/nand/tcl.c b/src/flash/nand/tcl.c
index e69882b..15426e9 100644
--- a/src/flash/nand/tcl.c
+++ b/src/flash/nand/tcl.c
@@ -580,6 +580,13 @@ static COMMAND_HELPER(create_nand_device, const char 
*bank_name,
return ERROR_OK;
}

+   if (nand_devices) {
+   struct nand_device *p = nand_devices;
+   while (p  p-next) p = p-next;
+   p-next = c;
+   } else
+   nand_devices = c;
+
return ERROR_OK;
 }
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] Supply 11-bit BYPASS instruction for PXA3xx

[Marek Vasut]

Hi, patch is attached, please consider applying. The pxa3xx uses different 
BYPASS instruction (0x7ff) than pxa2xx and ixp4xx, which use 0x7f.

Signed-off-by: Marek Vasut marek.va...@gmail.com
From 9c99c68059b213db828bcba73b512a980dc782d4 Mon Sep 17 00:00:00 2001
From: Marek Vasut marek.va...@gmail.com
Date: Tue, 1 Dec 2009 01:15:21 +0100
Subject: [PATCH] Supply 11-bit BYPASS instruction for PXA3xx

---
 src/target/xscale.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/src/target/xscale.c b/src/target/xscale.c
index fdc269a..636e208 100644
--- a/src/target/xscale.c
+++ b/src/target/xscale.c
@@ -1500,7 +1500,11 @@ static int xscale_assert_reset(struct target *target)
 	xscale_write_dcsr(target, 1, 0);
 
 	/* select BYPASS, because having DCSR selected caused problems on the PXA27x */
-	xscale_jtag_set_instr(target-tap, 0x7f);
+	if (xscale-xscale_variant == XSCALE_IXP4XX_PXA2XX)
+		xscale_jtag_set_instr(target-tap, 0x7f);
+	else	/* pxa3xx has 11-bit bypass instruction */
+	xscale_jtag_set_instr(target-tap, 0x7ff);
+
 	jtag_execute_queue();
 
 	/* assert reset */
-- 
1.6.5

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Supply 11-bit BYPASS instruction for PXA3xx

[Marek Vasut]

Dne Út 1. prosince 2009 01:17:57 Marek Vasut napsal(a):
 Hi, patch is attached, please consider applying. The pxa3xx uses different
 BYPASS instruction (0x7ff) than pxa2xx and ixp4xx, which use 0x7f.
 
 Signed-off-by: Marek Vasut marek.va...@gmail.com
 
Argh, the following patch doesn't have a stupid formating issue.
From cb7d451c8874c35f328b230ecaefd0454b40efcf Mon Sep 17 00:00:00 2001
From: Marek Vasut marek.va...@gmail.com
Date: Tue, 1 Dec 2009 01:15:21 +0100
Subject: [PATCH] Supply 11-bit BYPASS instruction for PXA3xx

---
 src/target/xscale.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/src/target/xscale.c b/src/target/xscale.c
index fdc269a..35039fb 100644
--- a/src/target/xscale.c
+++ b/src/target/xscale.c
@@ -1500,7 +1500,11 @@ static int xscale_assert_reset(struct target *target)
 	xscale_write_dcsr(target, 1, 0);
 
 	/* select BYPASS, because having DCSR selected caused problems on the PXA27x */
-	xscale_jtag_set_instr(target-tap, 0x7f);
+	if (xscale-xscale_variant == XSCALE_IXP4XX_PXA2XX)
+		xscale_jtag_set_instr(target-tap, 0x7f);
+	else	/* pxa3xx has 11-bit bypass instruction */
+		xscale_jtag_set_instr(target-tap, 0x7ff);
+
 	jtag_execute_queue();
 
 	/* assert reset */
-- 
1.6.5

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Add initial PXA3xx support (config file)

[Marek Vasut]

Dne Ne 29. listopadu 2009 06:10:57 David Brownell napsal(a):
 On Saturday 28 November 2009, Marek Vasut wrote:
+static int xscale_version = XSCALE_IXP4XX_PXA2XX;
  
   Please put this in the instance-specific struct ... this approach
   obviously breaks on a board with both a PXA2xx and a PXA3xx.
 
  Have you ever seen such a mutant ? Come on ...
 
 Bad design is bad design.  This is trivial to fix, and preventing
 such bugs from appearing in the first place is better than trying
 to troubleshoot them in the field later on.
 
  btw. where should I look for that instance-specific struct ?
 
 Did you look at xscale.h?  That's where I'd start.  There
 turns out to be a struct xscale_common, go figure.  ;)
 
Btw. attached here is a config file for the pxa3xx, maybe also apply.
From 418e0a9ce6bfd5e388d4dc115866ac9b5111e81a Mon Sep 17 00:00:00 2001
From: Marek Vasut marek.va...@gmail.com
Date: Sun, 29 Nov 2009 12:54:41 +0100
Subject: [PATCH 2/3] Add initial PXA3xx configuration file

---
 tcl/target/pxa3xx.cfg |   84 +
 1 files changed, 84 insertions(+), 0 deletions(-)
 create mode 100644 tcl/target/pxa3xx.cfg

diff --git a/tcl/target/pxa3xx.cfg b/tcl/target/pxa3xx.cfg
new file mode 100644
index 000..cb74c44
--- /dev/null
+++ b/tcl/target/pxa3xx.cfg
@@ -0,0 +1,84 @@
+#Marvell PXA3xx Script
+
+if { [info exists CHIPNAME] } {
+   set  _CHIPNAME $CHIPNAME
+} else {
+   set  _CHIPNAME pxa3xx
+}
+
+if { [info exists ENDIAN] } {
+   set  _ENDIAN $ENDIAN
+} else {
+   set  _ENDIAN little
+}
+
+# IDs for all of the PXA3xx
+if { [info exists CPUTAPID_PXA30X_A0 ] } {
+   set _CPUTAPID_PXA30X_A0 $CPUTAPID_PXA30X_A0
+} else {
+   set _CPUTAPID_PXA30X_A0 0x0E648013
+}
+if { [info exists CPUTAPID_PXA30X_A1 ] } {
+   set _CPUTAPID_PXA30X_A1 $CPUTAPID_PXA30X_A1
+} else {
+   set _CPUTAPID_PXA30X_A1 0x1E648013
+}
+if { [info exists CPUTAPID_PXA31X_A0 ] } {
+   set _CPUTAPID_PXA31X_A0 $CPUTAPID_PXA31X_A0
+} else {
+   set _CPUTAPID_PXA31X_A0 0x0E649013
+}
+if { [info exists CPUTAPID_PXA31X_A1 ] } {
+   set _CPUTAPID_PXA31X_A1 $CPUTAPID_PXA31X_A1
+} else {
+   set _CPUTAPID_PXA31X_A1 0x1E649013
+}
+if { [info exists CPUTAPID_PXA31X_A2 ] } {
+   set _CPUTAPID_PXA31X_A2 $CPUTAPID_PXA31X_A2
+} else {
+   set _CPUTAPID_PXA31X_A2 0x2E649013
+}
+if { [info exists CPUTAPID_PXA31X_B0 ] } {
+   set _CPUTAPID_PXA31X_B0 $CPUTAPID_PXA31X_B0
+} else {
+   set _CPUTAPID_PXA31X_B0 0x3E649013
+}
+if { [info exists CPUTAPID_PXA32X_B1 ] } {
+   set _CPUTAPID_PXA32X_B1 $CPUTAPID_PXA32X_B1
+} else {
+   set _CPUTAPID_PXA32X_B1 0x5E642013
+}
+if { [info exists CPUTAPID_PXA32X_B2 ] } {
+   set _CPUTAPID_PXA32X_B2 $CPUTAPID_PXA32X_B2
+} else {
+   set _CPUTAPID_PXA32X_B2 0x6E642013
+}
+if { [info exists CPUTAPID_PXA32X_C0 ] } {
+   set _CPUTAPID_PXA32X_C0 $CPUTAPID_PXA32X_C0
+} else {
+   set _CPUTAPID_PXA32X_C0 0x7E642013
+}
+
+# set jtag_nsrst_delay to the delay introduced by your reset circuit
+# the rest of the needed delays are built into the openocd program
+jtag_nsrst_delay 260
+# set the jtag_ntrst_delay to the delay introduced by a reset circuit
+# the rest of the needed delays are built into the openocd program
+jtag_ntrst_delay 250
+
+set _TARGETNAME $_CHIPNAME.cpu
+jtag newtap $_CHIPNAME cpu -irlen 11 -ircapture 0x1 -irmask 0x7f \
+	-expected-id $_CPUTAPID_PXA30X_A0 \
+	-expected-id $_CPUTAPID_PXA30X_A1 \
+	-expected-id $_CPUTAPID_PXA31X_A0 \
+	-expected-id $_CPUTAPID_PXA31X_A1 \
+	-expected-id $_CPUTAPID_PXA31X_A2 \
+	-expected-id $_CPUTAPID_PXA31X_B0 \
+	-expected-id $_CPUTAPID_PXA32X_B1 \
+	-expected-id $_CPUTAPID_PXA32X_B2 \
+	-expected-id $_CPUTAPID_PXA32X_C0
+
+target create $_TARGETNAME xscale -endian $_ENDIAN -chain-position $_TARGETNAME -variant pxa3xx
+# maps to PXA internal RAM. If you are using a PXA255
+# you must initialize SDRAM or leave this option off
+$_TARGETNAME configure -work-area-phys 0x5c03 -work-area-size 0x1 -work-area-backup 0
-- 
1.6.5

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] Add initial PXA3xx support

[Marek Vasut]

Dne Ne 29. listopadu 2009 05:21:20 David Brownell napsal(a):
 On Saturday 28 November 2009, Marek Vasut wrote:
  @@ -70,6 +70,13 @@ static int xscale_set_watchpoint(struct target *,
  struct watchpoint *); static int xscale_unset_breakpoint(struct target *,
  struct breakpoint *); static int xscale_read_trace(struct target *);
 
  +/* This variable determines which CPU we are connecting to.
  + *
  + * Possible values are:
  + *   0 - For PXA2xx and IXP4xx (default).
  + *   4 - For PXA3xx, which has JTAG Instructions shifted by four to
  left. + */
  +static int xscale_version = XSCALE_IXP4XX_PXA2XX;
 
 Please put this in the instance-specific struct ... this approach
 obviously breaks on a board with both a PXA2xx and a PXA3xx.

Have you ever seen such a mutant ? Come on ...

btw. where should I look for that instance-specific struct ?
 
 
 Other than that, it looks OK ... and I'll likely merge it after the
 tree starts working well enough for me that I can re-test two other
 XScale patches that are queued ahead of it.
 
 - Dave
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development