Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
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
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
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
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
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
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 ID register 0x%8.8" PRIx32, apid);
diff --git a/src/target/arm_adi_v5.h b/src/target/arm_adi_v5.h
index 92469eb..27a2f2f 100644
--- a/src/target/arm_adi_v5.h
+++ b/src/target/arm_
Re: [Openocd-development] stellaris.cfg
On Fri, Oct 29, 2010 at 10:40 PM, Kevin Hester wrote:
> Hi Bill,
> I recently tried OpenOCD and encountered the same problem. The cause seemed
> a relatively recent checkin that was attempting to add swj support. I've
> been bad though and haven't made a patch or filed a bug report. My quick
> fix was to comment out the two lines in stellaris.cfg that were mentioning
> swj (an import and some sort of swj add operation)
I can confirm this.
mc...@ubuntu1010:~/Desktop/build/openocd/lm3s1968$ openocd -f
board/ek-lm3s1968.cfg
Open On-Chip Debugger 0.5.0-dev-00568-g70b1538 (2010-11-01-10:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
3000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_gates_jtag srst_open_drain
libusb couldn't open USB device /dev/bus/usb/002/007: Permission denied.
libusb requires write access to USB device nodes.
Segmentation fault
(This is bad, it should not segfault even if the permission is not set
up properly).
I then set up udev rules by using the "lazy" rule (changing the MODE from 0664
to 0666 for the libusb rule in /lib/udev/rules.d/50-udev-default.rules).
# libusb device nodes
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0666"
mc...@ubuntu1010:~/Desktop/build/openocd/lm3s1968$ openocd -f
board/ek-lm3s1968.cfg
Open On-Chip Debugger 0.5.0-dev-00568-g70b1538 (2010-11-01-10:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
3000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_gates_jtag srst_open_drain
Info : clock speed 3000 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x00ff (mfg:
0x07f, part: 0x, ver: 0x0)
Warn : JTAG tap: lm3s1968.cpu UNEXPECTED: 0x00ff (mfg:
0x07f, part: 0x, ver: 0x0)
Error: JTAG tap: lm3s1968.cpu expected 1 of 1: 0x0ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Error: lm3s1968.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0x6 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
^C
mc...@ubuntu1010:~/Desktop/build/openocd/lm3s1968$ gksudo gedit
/usr/local/share/openocd/scripts/target/stellaris.cfg
Commenting out the two lines with swj.
#source [find target/swj-dp.tcl]
...
#swj_newdap $_CHIPNAME cpu -irlen 4 -irmask 0xf \
# -expected-id $_CPUTAPID -ignore-version
After that, it works again.
mc...@ubuntu1010:~/Desktop/build/openocd/lm3s1968$ openocd -f
board/ek-lm3s1968.cfg
Open On-Chip Debugger 0.5.0-dev-00568-g70b1538 (2010-11-01-10:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
3000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_gates_jtag srst_open_drain
Info : clock speed 3000 kHz
Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints
^C
--
Xiaofan
___
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
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 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. 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
Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63
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
On Sunday 31 October 2010 10:49:54 David Brownell wrote:
> > #define swjdp_memoryap 0
> > #define swjdp_debugap 1
>
> For Cortex-A8 it's likely not SWJ-DP but
> instead JTAG-DP ... regardless it's best
> not to try exposing irrelevant details
> like that in naming conventions here...
>
> > +static const char *variant = NULL;
>
> "variant" is never changed but ...
>
> > ...
> > +
> > uint32_t *dbgbase, uint32_t *apid)
> > +{
> > +/* Various CPU-specific quirks */
> > +
> > +/* iMX51 misreports ROM Table address
>
> ... and surely that can be detected, and then
> handled in a better way.
>
> > */
> > +if ((variant != NULL) &&
> > (strcmp(variant, "imx51") == 0))
>
> ... here we assume ight might be ...
What I'd be more interested is
1) Is this approach to detection correct
2) Is the placement of the fixup function in adiv5_dap structure correct
3) Placing the "variant" into adiv5_dap would fix the above, but I don't like
the
idea ... so where to place it so it can be used from within the fixup function?
Cheers
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63
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. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ 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
Ø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? //Peter ___ 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
On Sun, Oct 31, 2010 at 5:53 PM, Peter Stuge wrote: > Øyvind Harboe wrote: >> OpenOCD master branch now uses Jim Tcl. >> >> This means you'll have to build Jim Tcl before building OpenOCD. > > 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. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ 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
Øyvind Harboe wrote: > OpenOCD master branch now uses Jim Tcl. > > This means you'll have to build Jim Tcl before building OpenOCD. Is there also an upstream for Jim Tcl to make distribution packages from? Or is Jim Tcl only ever statically linked with OpenOCD? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 core debug reset problem
Le 2010-10-30 04:20, Chris Jones a écrit : I'd like to work out whether the debug unit really does break, or whether there's just a misunderstanding about state between it and OpenOCD. Wouldn't pulling the boot pin and send the reset core work? I would suggest to use the IAR limited version with a small version of the code and try it out. You are limited at 32k with that version. You could also ask for a one month try out. With IAR you can use openocd or the manufacturer's code. It is not the default in IAR but there is an option to send the reset core command to the processor before attempting to load the code. What I found out was that if I had DMA enabled part of the code would be trashed on power up. Debug wouldn't work because it would crash. Once I put my bootloader the checksum would always fail and that is when I found out that one area of RAM was being wiped out, code common between the ADC DMA and RAM area used by the IAR reflashing program. After I enabled the reset core everything worked fine. I use the bootloader to reflash code in the field connecting on the OBD or other diagnostic port. I use J-Link. Michel Catudal -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 core debug reset problem
Le 2010-10-29 19:15, Andreas Fritiofson a écrit : On Fri, Oct 29, 2010 at 8:58 PM, Chris Jones wrote: Am I stuck? Or is there a way of finding out how the Cortex-M3 debug unit is wedged, if that's the case, and tickling it back to life? Would it reset differently if you play with the boot pin? One can also ponder why you need debug access to something molded in plastic... Wouldn't it be better to debug your application on a more lab-friendly setup? A production unit that is to be protected from the environment must be molded into something. We would never use plastic in most application but the end result would be the same. I do agree that molded in plastic is strange but what difference would it make as for software is concerned? Most designs nowadays require reflashing at one time or another. Most of us in the industry no long use mask rom. Why do you think that we would want simulated mask rom? It is a legitimate concern and probably needs to be answered but I think that STMicro is probably the best source for a response. -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD master now uses Jim Tcl 0.63
OpenOCD master branch now uses Jim Tcl. This means you'll have to build Jim Tcl before building OpenOCD. bootstrap prints the instructions: git submodule init git submodule update cd jimtcl ./configure --with-jim-ext=nvp make make install From the OpenOCD command line you can determine the version of Jim Tcl you're running by typing => > info version 0.63 (It used to be 0.53) -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ 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
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. It would be great if we could detect the one broken chip out there and simply add a workaround(with warning). I'd suppose such bugs would be much less common with more recent Cortex A8 chips. 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. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ 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
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. - Dave ___ 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
> #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 ...
___
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 wrote: > So it turns out (by reading Freescale iMX515 errata), ENGcm09395 to > be exact Please mention this within the fixup function. > But that being the case, I'd prefer to make an incremental patch on > top of the patches I submitted. Please don't, since some of the former patches were going in the wrong direction. I think the new patches look really good, but please fix them to apply on git master rather than your previous ones. Thanks! //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
