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  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] 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
> 
>  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] 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

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

[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 
---
 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] [beagleboard] Flyswatter with XM

[Marek Vasut]

On Monday 13 December 2010 10:12:57 Jon Masters wrote:
> On Mon, 2010-12-13 at 10:05 +0100, Marek Vasut wrote:
> > On Monday 13 December 2010 10:00:05 Jon Masters wrote:
> > > 
> > > 
> > > > 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).
> 
> Sure. I don't have time today, but when I get chance this week I will
> take a look at better distinguishing the parts (I have only several of
> the Beagles here, but not the offending Freescale part so can send you a
> patch to test when I get chance to look at it).

Yes, that'd be cool. I don't mind testing.

> 
> Jon.
___
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 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.
> 
> 
> 
> > 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] [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 
> 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 
> 
> 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
&

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] 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  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] 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 :   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] "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

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  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

[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 
---
 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

[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 .

Signed-off-by: Marek Vasut 
---
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 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 
---
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 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 
---
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, (dbgbase&0xF000) |
+   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 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 
---
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 = ((apid&0x1) && ((apid&0x0F) != 0));
command_print(cmd_ctx, "AP 

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

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  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] [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

[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 
---
 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

[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 .

Signed-off-by: Marek Vasut 
---
 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 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 
---
 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 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 
---
 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, (dbgbase&0xF000) |
+   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 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 
---
 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 = ((apid&0x1) && ((apid&0x0F) != 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 th

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 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

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
> > 
> >  wrote:
> > > > On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut
> > > > 
> > > >  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 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

[Openocd-development] [PATCH 2/3] 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 .

Signed-off-by: Marek Vasut 
---
 src/target/cortex_a8.c |7 -
 tcl/target/imx51.cfg   |   52 
 2 files changed, 57 insertions(+), 2 deletions(-)
 create mode 100644 tcl/target/imx51.cfg

diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 64b78bd..3fe9c4b 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -73,7 +73,8 @@ 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
+#define OMAP3530_DEBUG_BASE0x54011000
+#define IMX51_DEBUG_BASE   0x60008000
 
 /*
  * Cortex-A8 Basic debug access, very low level assumes state is saved
@@ -1719,7 +1720,9 @@ static int cortex_a8_examine_first(struct target *target)
LOG_DEBUG("TODO - autoconfigure");
 
/* Here we shall insert a proper ROM Table scan */
-   if (strcmp(target->variant, "amdm37x") == 0)
+   if (strcmp(target->variant, "imx51") == 0)
+   armv7a->debug_base = IMX51_DEBUG_BASE;
+   else 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;
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.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 
---
 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

[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 
---
 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

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\OpenOCD>openocd
> 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
> > 
> > >

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\OpenOCD>openocd.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.
> > 
> > 

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 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 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 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

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

[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 
---
 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 
+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

[Openocd-development] [PATCH] Add VPACLink interface definition

[Marek Vasut]

This patch adds definition file for the Voipac VPACLink JTAG adaptor. The
adaptor is combined JTAG/UART device.

Signed-off-by: Marek Vasut 
---
 tcl/interface/vpaclink.cfg |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)
 create mode 100644 tcl/interface/vpaclink.cfg

diff --git a/tcl/interface/vpaclink.cfg b/tcl/interface/vpaclink.cfg
new file mode 100644
index 000..a4795d3
--- /dev/null
+++ b/tcl/interface/vpaclink.cfg
@@ -0,0 +1,10 @@
+#
+# Voipac VPACLink
+#
+# http://voipac.com/27M-JTG-000
+#
+
+interface ft2232
+ft2232_device_desc "VPACLink A"
+ft2232_layout oocdlink
+ft2232_vid_pid 0x0403 0x6010
-- 
1.7.0

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

Re: [Openocd-development] build openocd for arm

[Marek Vasut]

Dne Ne 25. dubna 2010 14:09:18 Nico Coesel napsal(a):
> Yu,
> IMHO this has to do with the way arm_jtag.h is doing some obfusticated
> casts. IIRC I posted a patch to this list a couple of months ago. I ran
> into the same problem when compiling for MIPS.

True indeed. You can read 4 byte wide data on ARM using ldr/str instructions 
only from addresses aligned to 4 bytes (used for operations with uint32_t). 
Though, you can read 1 byte data using ldrb/strb instructions from unaligned 
addresses (used for operations with uint8_t). Moreover, there're ldrd/strd 
instructions which operate on addresses aligned to 8 bytes (used for operations 
with uint64_t).

Therefore upcasting the uint8_t which can sit at unaligned address to uint32_t 
which must be aligned causes the problem. And indeed, if you do that, you get 
very wild undefined results.

Cheers
> 
> Nico Coesel
> 
> -Oorspronkelijk bericht-
> Van: openocd-development-boun...@lists.berlios.de namens Yu Li
> Verzonden: za 4/24/10 15:44
> Aan: openocd-development@lists.berlios.de
> Onderwerp: [Openocd-development] build openocd for arm
> 
> hi,
> i want to build openocd that can run on arm9.
> i use,
> $ CC=arm-linux-gcc ./configure --prefix=/opt/arm-openocd
> --build=i686-pc-linux-gnu --host=arm-linux --target=arm-linux
> --enable-parport --enable-maintainer-mode
> $ make
> 
> but i got the error
> arm_jtag.h: 81: error: cast increases required alignment of target type.
>  even though i delete the -Werror option in Makefile, the error still
> holded.
> 
> someone help me please.
> 
> My enviroment
> gcc v4.3.2
> openocd v0.4.0
> Vmware kubuntu 9.04
___
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] Have the NAND erase function use the nand page command

[Marek Vasut]

Dne Pá 18. prosince 2009 06:11:23 Dean Glazeski napsal(a):
> Sorry, I took another look and saw what you were talking about and how to
> correct for it.  Here's another version that addresses that issue.
> 
> // Dean Glazeski
> 
> On Thu, Dec 17, 2009 at 10:56 PM, Dean Glazeski  wrote:
> > Oh, I didn't see that.  This patch can be ignored then.  It just looks so
> > similar :).
> >
> > // Dean Glazeski
> >
> > On Thu, Dec 17, 2009 at 10:29 PM, David Brownell wrote:
> >> On Tuesday 15 December 2009, Dean Glazeski wrote:
> >> > I noticed the NAND erase function was doing page command stuff, so I
> >>
> >> pulled
> >>
> >> > the redundant code out.  Patch is attached
> >>
> >> This doesn't look right.  Consider the 16 Gbit large page chip
> >> I happen to have on some boards here:
> >>
> >>  - read/write of 2KB page uses 5 byte addressing
> >>  - erase of 128KB block uses 3 byte addressping
> >>
> >> You're making both use the 5 byte addressing ... basically, if
> >> this is going to be shared, the erase commands shouldn't be
> >> writing column addresses, just row addresses.
> >>
> >> - Dave
> 

Why are you incrementing the timeout from 100 to 1000 in the nand_page_command 
? 
btw. please stop top-posting.
___
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 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 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 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 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 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

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 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 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: breakage

[Marek Vasut]

Dne So 12. prosince 2009 03:47:09 Zach Welch napsal(a):
> Thanks.  I broke it, but I just pushed a patch to fix this properly.

Sure, great ... thanks for fixing it, I need some sleep badly so I couldn't 
come 
with anything decent ;-)
> 
> On Sat, 2009-12-12 at 02:05 +0100, Marek Vasut wrote:
> > 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 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] NAND: add erase_page callback

[Marek Vasut]

Hi,

included is a patch that adds possibility to supply erase_page function in a 
driver, overriding the default behaviour of core.c
From 7fa880bfe5a541b1b5df520cf023268491d4ca2e Mon Sep 17 00:00:00 2001
From: Marek Vasut 
Date: Sat, 12 Dec 2009 00:39:54 +0100
Subject: [PATCH] NAND: Add erase_page callback

Signed-off-by: Marek Vasut 
---
 src/flash/nand/core.c   |   59 ++
 src/flash/nand/driver.h |3 ++
 2 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/src/flash/nand/core.c b/src/flash/nand/core.c
index d52cf5d..1ee2813 100644
--- a/src/flash/nand/core.c
+++ b/src/flash/nand/core.c
@@ -536,39 +536,46 @@ int nand_erase(struct nand_device *nand, int first_block, int last_block)
 
 	for (i = first_block; i <= last_block; i++)
 	{
-		/* Send erase setup command */
-		nand->controller->command(nand, NAND_CMD_ERASE1);
-
 		page = i * (nand->erase_size / nand->page_size);
 
-		/* Send page address */
-		if (nand->page_size <= 512)
+		if (nand->controller->erase_page)
 		{
-			/* row */
-			nand->controller->address(nand, page & 0xff);
-			nand->controller->address(nand, (page >> 8) & 0xff);
-
-			/* 3rd cycle only on devices with more than 32 MiB */
-			if (nand->address_cycles >= 4)
-nand->controller->address(nand, (page >> 16) & 0xff);
-
-			/* 4th cycle only on devices with more than 8 GiB */
-			if (nand->address_cycles >= 5)
-nand->controller->address(nand, (page >> 24) & 0xff);
+			nand->controller->erase_page(nand, page);
 		}
 		else
 		{
-			/* row */
-			nand->controller->address(nand, page & 0xff);
-			nand->controller->address(nand, (page >> 8) & 0xff);
+			/* Send erase setup command */
+			nand->controller->command(nand, NAND_CMD_ERASE1);
 
-			/* 3rd cycle only on devices with more than 128 MiB */
-			if (nand->address_cycles >= 5)
-nand->controller->address(nand, (page >> 16) & 0xff);
-		}
+			/* Send page address */
+			if (nand->page_size <= 512)
+			{
+/* row */
+nand->controller->address(nand, page & 0xff);
+nand->controller->address(nand, (page >> 8) & 0xff);
+
+/* 3rd cycle only on devices with more than 32 MiB */
+if (nand->address_cycles >= 4)
+	nand->controller->address(nand, (page >> 16) & 0xff);
 
-		/* Send erase confirm command */
-		nand->controller->command(nand, NAND_CMD_ERASE2);
+/* 4th cycle only on devices with more than 8 GiB */
+if (nand->address_cycles >= 5)
+	nand->controller->address(nand, (page >> 24) & 0xff);
+			}
+			else
+			{
+/* row */
+nand->controller->address(nand, page & 0xff);
+nand->controller->address(nand, (page >> 8) & 0xff);
+
+/* 3rd cycle only on devices with more than 128 MiB */
+if (nand->address_cycles >= 5)
+	nand->controller->address(nand, (page >> 16) & 0xff);
+			}
+
+			/* Send erase confirm command */
+			nand->controller->command(nand, NAND_CMD_ERASE2);
+		}
 
 		retval = nand->controller->nand_ready ?
 nand->controller->nand_ready(nand, 1000) :
diff --git a/src/flash/nand/driver.h b/src/flash/nand/driver.h
index fe73e90..402b2ba 100644
--- a/src/flash/nand/driver.h
+++ b/src/flash/nand/driver.h
@@ -75,6 +75,9 @@ struct nand_flash_controller
 	/** Read a page from the NAND device. */
 	int (*read_page)(struct nand_device *nand, uint32_t page, uint8_t *data, uint32_t data_size, uint8_t *oob, uint32_t oob_size);
 
+	/** Erase a page from the NAND device. */
+	int (*erase_page)(struct nand_device *nand, uint32_t page);
+
 	/** Check if the controller is ready for more instructions with timeout. */
 	int (*controller_ready)(struct nand_device *nand, int timeout);
 
-- 
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 
> 
Argh, the following patch doesn't have a stupid formating issue.
From cb7d451c8874c35f328b230ecaefd0454b40efcf Mon Sep 17 00:00:00 2001
From: Marek Vasut 
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

[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 
From 9c99c68059b213db828bcba73b512a980dc782d4 Mon Sep 17 00:00:00 2001
From: Marek Vasut 
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] 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 
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 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.  ;)
> 
Ok, here's an updated patch
From 2a2b0143bf8b359f6acabac633bc2607e9bd9de0 Mon Sep 17 00:00:00 2001
From: Marek Vasut 
Date: Sun, 29 Nov 2009 12:53:06 +0100
Subject: [PATCH 1/3] Add initial PXA3xx support

---
 src/target/xscale.c |   37 +++--
 src/target/xscale.h |7 +++
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/src/target/xscale.c b/src/target/xscale.c
index 49653a9..fdc269a 100644
--- a/src/target/xscale.c
+++ b/src/target/xscale.c
@@ -191,7 +191,8 @@ static int xscale_read_dcsr(struct target *target)
 	uint8_t field2_check_mask = 0x1;
 
 	jtag_set_end_state(TAP_DRPAUSE);
-	xscale_jtag_set_instr(target->tap, XSCALE_SELDCSR);
+	xscale_jtag_set_instr(target->tap,
+		XSCALE_SELDCSR << xscale->xscale_variant);
 
 	buf_set_u32(&field0, 1, 1, xscale->hold_rst);
 	buf_set_u32(&field0, 2, 1, xscale->external_debug_break);
@@ -256,6 +257,7 @@ static int xscale_receive(struct target *target, uint32_t *buffer, int num_words
 	if (num_words == 0)
 		return ERROR_INVALID_ARGUMENTS;
 
+	struct xscale_common *xscale = target_to_xscale(target);
 	int retval = ERROR_OK;
 	tap_state_t path[3];
 	struct scan_field fields[3];
@@ -289,7 +291,8 @@ static int xscale_receive(struct target *target, uint32_t *buffer, int num_words
 	fields[2].check_mask = &field2_check_mask;
 
 	jtag_set_end_state(TAP_IDLE);
-	xscale_jtag_set_instr(target->tap, XSCALE_DBGTX);
+	xscale_jtag_set_instr(target->tap,
+		XSCALE_DBGTX << xscale->xscale_variant);
 	jtag_add_runtest(1, jtag_get_end_state()); /* ensures that we're in the TAP_IDLE state as the above could be a no-op */
 
 	/* repeat until all words have been collected */
@@ -371,7 +374,8 @@ static int xscale_read_tx(struct target *target, int consume)
 
 	jtag_set_end_state(TAP_IDLE);
 
-	xscale_jtag_set_instr(target->tap, XSCALE_DBGTX);
+	xscale_jtag_set_instr(target->tap,
+		XSCALE_DBGTX << xscale->xscale_variant);
 
 	path[0] = TAP_DRSELECT;
 	path[1] = TAP_DRCAPTURE;
@@ -469,7 +473,8 @@ static int xscale_write_rx(struct target *target)
 
 	jtag_set_end_state(TAP_IDLE);
 
-	xscale_jtag_set_instr(target->tap, XSCALE_DBGRX);
+	xscale_jtag_set_instr(target->tap,
+		XSCALE_DBGRX << xscale->xscale_variant);
 
 	memset(&fields, 0, sizeof fields);
 
@@ -541,6 +546,7 @@ static int xscale_write_rx(struct target *target)
 /* send count elements of size byte to the debug handler */
 static int xscale_send(struct target *target, uint8_t *buffer, int count, int size)
 {
+	struct xscale_common *xscale = target_to_xscale(target);
 	uint32_t t[3];
 	int bits[3];
 	int retval;
@@ -548,7 +554,8 @@ static int xscale_send(struct target *target, uint8_t *buffer, int count, int si
 
 	jtag_set_end_state(TAP_IDLE);
 
-	xscale_jtag_set_instr(target->tap, XSCALE_DBGRX);
+	xscale_jtag_set_instr(target->tap,
+		XSCALE_DBGRX << xscale->xscale_variant);
 
 	bits[0]=3;
 	t[0]=0;
@@ -629,7 +636,8 @@ static int xscale_write_dcsr(struct target *target, int hold_rst, int ext_dbg_br
 		xscale->external_debug_break = ext_dbg_brk;
 
 	jtag_set_end_state(TAP_IDLE);
-	xscale_jtag_set_instr(target->tap, XSCALE_SELDCSR);
+	xscale_jtag_set_instr(target->tap,
+		XSCALE_SELDCSR << xscale->xscale_variant);
 
 	buf_set_u32(&field0, 1, 1, xscale->hold_rst);
 	buf_set_u32(&field0, 2, 1, xscale->external_debug_break);
@@ -683,6 +691,7 @@ static unsigned int parity (unsigned int v)
 
 static int xscale_load_ic(struct target *target, uint32_t va, uint32_t buffer[8])
 {
+	struct xscale_common *xscale = target_to_xscale(target);
 	uint8_t packet[4];
 	uint8_t cmd;
 	int word;
@@ -692,7 +701,8 @@ static int xscale_load_ic(struct target *target, uint32_t va, uint32_t buffer[8]
 
 	/* LDIC into IR */
 	jtag_set_end_state(TAP_IDLE);
-	xscale_jtag_set_instr(target->tap, XSCALE_LDIC);
+	xscale_jtag_set_instr(target->tap,
+		XSCALE_LDIC << xscale->xscale_variant);
 
 	/* CMD is b011 to load a cacheline into the Mini ICache.
 	 * Loading into the main ICache is deprecated, 

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

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

[Marek Vasut]

Hi,
attached (because of a buggy mailer not inline) is a patch that adds basic 
support for XScale/PXA3xx. Tested on PXA320 CPU.

Please consider applying. Thanks.

Signed-off-by: Marek Vasut 
From f4653c4af3c5fc093f9df69b7d0d16843c221d0d Mon Sep 17 00:00:00 2001
From: Marek Vasut 
Date: Sun, 29 Nov 2009 03:04:27 +0100
Subject: [PATCH] Add initial PXA3xx support

---
 src/target/xscale.c |   31 +--
 src/target/xscale.h |4 
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/src/target/xscale.c b/src/target/xscale.c
index 49653a9..5772284 100644
--- a/src/target/xscale.c
+++ b/src/target/xscale.c
@@ -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;
 
 /* This XScale "debug handler" is loaded into the processor's
  * mini-ICache, which is 2K of code writable only via JTAG.
@@ -191,7 +198,7 @@ static int xscale_read_dcsr(struct target *target)
 	uint8_t field2_check_mask = 0x1;
 
 	jtag_set_end_state(TAP_DRPAUSE);
-	xscale_jtag_set_instr(target->tap, XSCALE_SELDCSR);
+	xscale_jtag_set_instr(target->tap, XSCALE_SELDCSR << xscale_version);
 
 	buf_set_u32(&field0, 1, 1, xscale->hold_rst);
 	buf_set_u32(&field0, 2, 1, xscale->external_debug_break);
@@ -289,7 +296,7 @@ static int xscale_receive(struct target *target, uint32_t *buffer, int num_words
 	fields[2].check_mask = &field2_check_mask;
 
 	jtag_set_end_state(TAP_IDLE);
-	xscale_jtag_set_instr(target->tap, XSCALE_DBGTX);
+	xscale_jtag_set_instr(target->tap, XSCALE_DBGTX << xscale_version);
 	jtag_add_runtest(1, jtag_get_end_state()); /* ensures that we're in the TAP_IDLE state as the above could be a no-op */
 
 	/* repeat until all words have been collected */
@@ -371,7 +378,7 @@ static int xscale_read_tx(struct target *target, int consume)
 
 	jtag_set_end_state(TAP_IDLE);
 
-	xscale_jtag_set_instr(target->tap, XSCALE_DBGTX);
+	xscale_jtag_set_instr(target->tap, XSCALE_DBGTX << xscale_version);
 
 	path[0] = TAP_DRSELECT;
 	path[1] = TAP_DRCAPTURE;
@@ -469,7 +476,7 @@ static int xscale_write_rx(struct target *target)
 
 	jtag_set_end_state(TAP_IDLE);
 
-	xscale_jtag_set_instr(target->tap, XSCALE_DBGRX);
+	xscale_jtag_set_instr(target->tap, XSCALE_DBGRX << xscale_version);
 
 	memset(&fields, 0, sizeof fields);
 
@@ -548,7 +555,7 @@ static int xscale_send(struct target *target, uint8_t *buffer, int count, int si
 
 	jtag_set_end_state(TAP_IDLE);
 
-	xscale_jtag_set_instr(target->tap, XSCALE_DBGRX);
+	xscale_jtag_set_instr(target->tap, XSCALE_DBGRX << xscale_version);
 
 	bits[0]=3;
 	t[0]=0;
@@ -629,7 +636,7 @@ static int xscale_write_dcsr(struct target *target, int hold_rst, int ext_dbg_br
 		xscale->external_debug_break = ext_dbg_brk;
 
 	jtag_set_end_state(TAP_IDLE);
-	xscale_jtag_set_instr(target->tap, XSCALE_SELDCSR);
+	xscale_jtag_set_instr(target->tap, XSCALE_SELDCSR << xscale_version);
 
 	buf_set_u32(&field0, 1, 1, xscale->hold_rst);
 	buf_set_u32(&field0, 2, 1, xscale->external_debug_break);
@@ -692,7 +699,7 @@ static int xscale_load_ic(struct target *target, uint32_t va, uint32_t buffer[8]
 
 	/* LDIC into IR */
 	jtag_set_end_state(TAP_IDLE);
-	xscale_jtag_set_instr(target->tap, XSCALE_LDIC);
+	xscale_jtag_set_instr(target->tap, XSCALE_LDIC << xscale_version);
 
 	/* CMD is b011 to load a cacheline into the Mini ICache.
 	 * Loading into the main ICache is deprecated, and unused.
@@ -743,7 +750,7 @@ static int xscale_invalidate_ic_line(struct target *target, uint32_t va)
 	struct scan_field fields[2];
 
 	jtag_set_end_state(TAP_IDLE);
-	xscale_jtag_set_instr(target->tap, XSCALE_LDIC);
+	xscale_jtag_set_instr(target->tap, XSCALE_LDIC << xscale_version);
 
 	/* CMD for invalidate IC line b000, bits [6:4] b000 */
 	buf_set_u32(&cmd, 0, 6, 0x0);
@@ -1479,7 +1486,7 @@ static int xscale_assert_reset(struct target *target)
 	 * end up in T-L-R, which would reset JTAG
 	 */
 	jtag_set_end_state(TAP_IDLE);
-	xscale_jtag_set_instr(target->tap, XSCALE_SELDCSR);
+	xscale_jtag_set_instr(target->tap, XSCALE_SELDCSR << xscale_version);
 
 	/* set Hold reset, Halt mode and Trap Reset */
 	buf_set_u32(xscale->reg_cache->reg_list[XSCALE_DCSR].value, 30, 1, 0x1);
@@ -2882,6 +2889,7 @@ static int xscale_init_arch_info(struct target *target,
 	/* we don't really *need* variant info ... */
 	if (variant) {
 		int ir_length = 0;
+		xscale_version = XSCALE_IXP4XX_PXA2XX;	/* PXA2xx and IXP4xx */
 
 		if (strcm