Re: [Openocd-development] PXA270 problems
> I've failed to find link now, but reproduced patch and attached it to this > mail, > so I think you will remember this one. That one... It's in TODO file. Someone needs to step up to the plate and fix the automake files I don't know the install rules, etc. that need to be followed. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] allow faster armv4_5 run_algorithm() calls
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] ARM11 MCR and MRC coprocessor command docs
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] new lpc2xxx cfg files layout
Here, I agree with Duane, The end user want to debug/flash a device -> not a concept of multiple devices. You may auto-generate the files one time at the MAKE of openocd. Or you may have a separated script, generating this file one time and put these file to the trunk. Regards, Laurent http://www.amontec.com JTAGkey-2 : high-speed USB JTAG adapter / 30Mhz TCK / RTCK / support 1.3V to 5V @ 32ma output drive per IOs / on-board 4 leds for an easy use. > avid> Having a hundred or so chip-specific config files is > david> a messy concept... > > Yes, but that is exactly what is needed. > > If there are 100 chips - you need 100 files, with 100 names. > > Take the "openocd-developer-hat" off for a little bit and think about this. > > Configure files are something *END*USERS* mess with. > > Yes, from our end (the developer end) 100 files is a P.I.T.A, but it is > exactly what the *end*user* needs, or they at least need the *SIMPLE* > means to add the +1 more file they need. > > As an *end*user* if I saw a sequence of filenames that I recognized I > could examine a few of them - see the simple pattern and settings and > could probably follow that simple pattern successfully. By simple I > mean: perform lots of "set VARNAME VALUE" - then include/source a > common file. > Most developers would understand and modify a simple TCL statement like > this with great success: > > # This chip has 16K flash.. > set FLASH_SIZE 0x4000 > > But instead, using Freddies' approach - one has to (or is lead to > believe they must) read through the "complicated internals" file which > is where lots of magic is happening - magic that is to the benefit of > the maintainer who understands the complexities of the chip family, and > the scripts, and perhaps knows a little bit of TCL. > > Wearing a "naive new users hat" - I would see the big internal file > Freddie has and assume that I should "weave" my new chip into that file, > and become very confused. That is *NOT* something I think we want users > to do. > > Bottom line: > > 1) Freddies 'internal' file does too much, and does too much > magic about figuring things out. > > It is ok for the 3 of us to understand... > Remember: Our goal is the *end*user* > > 2) We don't need to create 100 files for 100 chips.. instead we > need to create a few of them - such that is very *CLEAR* > to a new user how to add 1 more. > > That's why we converted the configuration files into 3 "source" statements > > (1) the interface > (2) the board > (3) which includes a chip... > > In the past, there was just one configuration file users where weaving > their changes into other files. By splitting them up - it made it easier > to understand. > > SUGGESTION > > Freddie could create a simple textfile/database and generate 100 "chip > files" from a quasi-table of some sort... that only runs in "maintainer > mode". > > BETTER SOLUTION: > > In contrast, if the *SCRIPT* would examine the chip some how - and read > registers and/or other things it *could* configure it self auto > magically. For example ATMEL at91 series parts have some registers in > the DEBUG UART at a fixed address... > > I just don't think this better solution is that easy to implement. > > -Duane. > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA270 problems
>> Anyone got a PXA270 to donate so I can test? > > We can almost certainly get you a balloon board if it would help keep > Openocd-on-pxa270 in good fettle. Thanks! Please mail it to: Zylin AS att. Øyvind Harboe Auglendsdalen 78 4017 Stavanger Norway tel. +47 51 63 25 00 -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Beagleboard post reset event
On Wed, Sep 9, 2009 at 1:26 AM, David Brownell wrote: > On Tuesday 08 September 2009, Ųyvind Harboe wrote: >> There was a bug in waiting in the code that handled tap >> events when more than 2 event types were added > > I saw that and had a different fix, which handled one > additional case. > > But why was the call to the post-reset handler failing? I didn't see any failure here and your post didn't contain any output... -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] allow faster armv4_5 run_algorithm() calls
Optionally shave time off the armv4_5 run_algorithm() code: let
them terminate using software breakpoints, avoiding roundtrips
to manage hardware ones.
Enable this by using BKPT to terminate execution instead of "branch
to here" loops. Then pass zero as the exit address, except when
running on an ARMv4 core. ARM7TDMI, ARM9TDMI, and derived cores
now set a flag saying they're ARMv4.
Use that mechanism in arm_nandwrite(), for about 3% speedup on a
DaVinci ARM926 core; not huge, but it helps. Some other algorithms
could use this too (mostly flavors of flash operation).
---
src/flash/arm_nandio.c | 11 +++
src/target/arm7tdmi.c |1 +
src/target/arm9tdmi.c |1 +
src/target/armv4_5.c | 21 +
src/target/armv4_5.h |1 +
5 files changed, 27 insertions(+), 8 deletions(-)
--- a/src/flash/arm_nandio.c
+++ b/src/flash/arm_nandio.c
@@ -33,7 +33,6 @@
* For now this only supports ARMv4 and ARMv5 cores.
*
* Enhancements to target_run_algorithm() could enable:
- * - faster writes: on ARMv5+ don't setup/teardown hardware breakpoint
* - ARMv6 and ARMv7 cores in ARM mode
*
* Different code fragments could handle:
@@ -44,8 +43,10 @@ int arm_nandwrite(struct arm_nand_data *
{
target_t*target = nand->target;
armv4_5_algorithm_t algo;
+ armv4_5_common_t*armv4_5 = target->arch_info;
reg_param_t reg_params[3];
uint32_ttarget_buf;
+ uint32_texit = 0;
int retval;
/* Inputs:
@@ -112,11 +113,13 @@ int arm_nandwrite(struct arm_nand_data *
buf_set_u32(reg_params[1].value, 0, 32, target_buf);
buf_set_u32(reg_params[2].value, 0, 32, size);
+ /* armv4 must exit using a hardware breakpoint */
+ if (armv4_5->is_armv4)
+ exit = nand->copy_area->address + sizeof(code) - 4;
+
/* use alg to write data from work area to NAND chip */
retval = target_run_algorithm(target, 0, NULL, 3, reg_params,
- nand->copy_area->address,
- nand->copy_area->address + sizeof(code) - 4,
- 1000, &algo);
+ nand->copy_area->address, exit, 1000, &algo);
if (retval != ERROR_OK)
LOG_ERROR("error executing hosted NAND write");
--- a/src/target/arm7tdmi.c
+++ b/src/target/arm7tdmi.c
@@ -828,6 +828,7 @@ int arm7tdmi_target_create(struct target
arm7tdmi = calloc(1,sizeof(arm7tdmi_common_t));
arm7tdmi_init_arch_info(target, arm7tdmi, target->tap);
+ arm7tdmi->arm7_9_common.armv4_5_common.is_armv4 = true;
return ERROR_OK;
}
--- a/src/target/arm9tdmi.c
+++ b/src/target/arm9tdmi.c
@@ -956,6 +956,7 @@ int arm9tdmi_target_create(struct target
arm9tdmi_common_t *arm9tdmi = calloc(1,sizeof(arm9tdmi_common_t));
arm9tdmi_init_arch_info(target, arm9tdmi, target->tap);
+ arm9tdmi->arm7_9_common.armv4_5_common.is_armv4 = true;
return ERROR_OK;
}
--- a/src/target/armv4_5.c
+++ b/src/target/armv4_5.c
@@ -532,7 +532,10 @@ static int armv4_5_run_algorithm_complet
}
return ERROR_TARGET_TIMEOUT;
}
- if (buf_get_u32(armv4_5->core_cache->reg_list[15].value, 0, 32) !=
exit_point)
+
+ /* fast exit: ARMv5+ code can use BKPT */
+ if (exit_point && buf_get_u32(armv4_5->core_cache->reg_list[15].value,
+ 0, 32) != exit_point)
{
LOG_WARNING("target reentered debug state, but not at the
desired exit point: 0x%4.4" PRIx32 "",
buf_get_u32(armv4_5->core_cache->reg_list[15].value, 0,
32));
@@ -570,6 +573,13 @@ int armv4_5_run_algorithm_inner(struct t
if (armv4_5_mode_to_number(armv4_5->core_mode)==-1)
return ERROR_FAIL;
+ /* armv5 and later can terminate with BKPT instruction; less overhead */
+ if (!exit_point && armv4_5->is_armv4)
+ {
+ LOG_ERROR("ARMv4 target needs HW breakpoint location");
+ return ERROR_FAIL;
+ }
+
for (i = 0; i <= 16; i++)
{
if (!ARMV4_5_CORE_REG_MODE(armv4_5->core_cache,
armv4_5_algorithm_info->core_mode, i).valid)
@@ -626,9 +636,11 @@ int armv4_5_run_algorithm_inner(struct t
armv4_5->core_cache->reg_list[ARMV4_5_CPSR].valid = 1;
}
- if ((retval = breakpoint_add(target, exit_point, exit_breakpoint_size,
BKPT_HARD)) != ERROR_OK)
+ /* terminate using a hardware or (ARMv5+) software breakpoint */
+ if (exit_point && (retval = breakpoint_add(target, exit_point,
+ exit_breakpoint_size, BKPT_HARD)) != ERROR_OK)
{
- LOG_ERROR("can't add breakpoint to finish algorithm execution");
+ LOG_ERROR("can't add HW breakpoint to terminate algorithm");
return ERROR_TARGET
[Openocd-development] [patch] ARM11 MCR and MRC coprocessor command docs
Fix docs on ARM11 MCR and MRC coprocessor commands:
correct read-vs-write; and describe the params.
(ARM920 and ARM926 have cp15-specific commands; this
approach is more generic. MCR2, MRC2, MCRR, MCRR2,
MRRC, and MRRC2 instructions could also get exposed.)
---
doc/openocd.texi | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -5058,8 +5058,13 @@ Without arguments, the current settings
@subsection ARM11 specific commands
@cindex ARM11
-...@deffn Command {arm11 mcr} p1 p2 p3 p4 p5
-Read coprocessor register
+...@deffn Command {arm11 mcr} pX opc1 CRn CRm opc2 value
+Write @var{value} to a coprocessor @var{pX} register
+passing parameters @var{CRn},
+...@var{crm}, opcodes @var{opc1} and @var{opc2},
+and the MCR instruction.
+(The difference beween this and the MCR2 instruction is
+one bit in the encoding, effecively a fifth parameter.)
@end deffn
@deffn Command {arm11 memwrite burst} [value]
@@ -5074,8 +5079,13 @@ which is enabled by default.
If @var{value} is defined, first assigns that.
@end deffn
-...@deffn Command {arm11 mrc} p1 p2 p3 p4 p5 value
-Write coprocessor register
+...@deffn Command {arm11 mrc} pX opc1 CRn CRm opc2
+Read a coprocessor @var{pX} register passing parameters @var{CRn},
+...@var{crm}, opcodes @var{opc1} and @var{opc2},
+and the MRC instruction.
+(The difference beween this and the MRC2 instruction is
+one bit in the encoding, effecively a fifth parameter.)
+Displays the result.
@end deffn
@deffn Command {arm11 no_increment} [value]
Fix docs on ARM11 MCR and MRC coprocessor commands:
correct read-vs-write; and describe the params.
(ARM920 and ARM926 have cp15-specific commands; this
approach is more generic. MCR2, MRC2, MCRR, MCRR2,
MRRC, and MRRC2 instructions could also get exposed.)
---
doc/openocd.texi | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -5058,8 +5058,13 @@ Without arguments, the current settings
@subsection ARM11 specific commands
@cindex ARM11
-...@deffn Command {arm11 mcr} p1 p2 p3 p4 p5
-Read coprocessor register
+...@deffn Command {arm11 mcr} pX opc1 CRn CRm opc2 value
+Write @var{value} to a coprocessor @var{pX} register
+passing parameters @var{CRn},
+...@var{crm}, opcodes @var{opc1} and @var{opc2},
+and the MCR instruction.
+(The difference beween this and the MCR2 instruction is
+one bit in the encoding, effecively a fifth parameter.)
@end deffn
@deffn Command {arm11 memwrite burst} [value]
@@ -5074,8 +5079,13 @@ which is enabled by default.
If @var{value} is defined, first assigns that.
@end deffn
-...@deffn Command {arm11 mrc} p1 p2 p3 p4 p5 value
-Write coprocessor register
+...@deffn Command {arm11 mrc} pX opc1 CRn CRm opc2
+Read a coprocessor @var{pX} register passing parameters @var{CRn},
+...@var{crm}, opcodes @var{opc1} and @var{opc2},
+and the MRC instruction.
+(The difference beween this and the MRC2 instruction is
+one bit in the encoding, effecively a fifth parameter.)
+Displays the result.
@end deffn
@deffn Command {arm11 no_increment} [value]
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA270 problems
On Wed, Sep 9, 2009 at 12:25 AM, Øyvind Harboe wrote:
> On Tue, Sep 8, 2009 at 8:50 PM, Sergey Lapin wrote:
>> Hi, all!
>>
>> When working with PXA270 I see the following messages on reset.
>>
>> JTAG tap: pxa270.cpu tap/device found: 0x49265013 (mfg: 0x009, part:
>> 0x9265, ver: 0x4)
>> value captured during scan didn't pass the requested check:
>> captured: 0x00 check_value: 0x02 check_mask: 0x07
>> JTAG error while writing DCSR
>> value captured during scan didn't pass the requested check:
>> captured: 0x00 check_value: 0x01 check_mask: 0x7F
>> value captured during scan didn't pass the requested check:
>> captured: 0x00 check_value: 0x01 check_mask: 0x7F
>> Unimplemented instruction, could not simulate it.
>
> Anyone got a PXA270 to donate so I can test?
>
>> Working with CPU is very unstable.
>> I use Olimex ARM-USB-OCD, under Linux with libftdi.
>> I also use patch which fixes monitor loading, from Øyvind,
>
> Which patch is this?
>
I've failed to find link now, but reproduced patch and attached it to this mail,
so I think you will remember this one.
Index: src/helper/Makefile.am
===
--- src/helper/Makefile.am (revision 2678)
+++ src/helper/Makefile.am (working copy)
@@ -1,6 +1,7 @@
AM_CPPFLAGS = \
-I$(top_srcdir)/src/server \
-I$(top_srcdir)/src/target \
+ -DPKGLIBDIR=\"$(pkglibdir)\" \
-DPKGDATADIR=\"$(pkgdatadir)\"
METASOURCES = AUTO
Index: src/helper/options.c
===
--- src/helper/options.c (revision 2678)
+++ src/helper/options.c (working copy)
@@ -105,6 +105,7 @@
/// @todo Implement @c add_script_search_dir("${HOME}/.openocd").
add_script_search_dir(PKGDATADIR "/site");
add_script_search_dir(PKGDATADIR "/scripts");
+ add_script_search_dir(PKGLIBDIR);
#endif
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA270 problems
+++ Øyvind Harboe [2009-09-08 22:25 +0200]:
> On Tue, Sep 8, 2009 at 8:50 PM, Sergey Lapin wrote:
> > Hi, all!
> >
> > When working with PXA270 I see the following messages on reset.
> >
> > JTAG tap: pxa270.cpu tap/device found: 0x49265013 (mfg: 0x009, part:
> > 0x9265, ver: 0x4)
That is the correct value. Values we have observed so far are:
0x79265013 and 0x49265013 which I believe are now in openocd.
> > value captured during scan didn't pass the requested check:
> > captured: 0x00 check_value: 0x02 check_mask: 0x07
I see errors like this too and have never understood why the boundary
scan seems to work OK ('scan_chain'), but then other commands cause the
above errors.
> Anyone got a PXA270 to donate so I can test?
We can almost certainly get you a balloon board if it would help keep
Openocd-on-pxa270 in good fettle.
> > Working with CPU is very unstable.
> > I use Olimex ARM-USB-OCD, under Linux with libftdi.
Same here. We have found cpu and NOR flash uploading reliable - all
our problems are with CPLD loading and USB getting 'stuck'.
> > I also use patch which fixes monitor loading, from Øyvind,
>
> Which patch is this?
I wondered that too.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Beagleboard post reset event
On Tuesday 08 September 2009, Øyvind Harboe wrote: > There was a bug in waiting in the code that handled tap > events when more than 2 event types were added I saw that and had a different fix, which handled one additional case. But why was the call to the post-reset handler failing? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Freddie Chopin wrote: freddie> I still cannot agree on that. Which version is better: freddie> Your: duane> global CHIPNAME duane> set CHIPNAME lpc2103 duane> global FLASH_SIZE duane> set FLASH_SIZE ... duane> ... [snip] ... duane> source [find target/lpc2xxx_internals.tcl] freddie> or mine freddie> set CHIPNAME lpc2103 freddie> set CRYSTAL_FREQ 1200 freddie> set JTAG_FREQ 100 freddie> source [find target/lpc2xxx_internals.tcl] The *problem* use case is as follows: I have a chip that does not have a "cfg" file that i recognize. There is a CFG file for a chip _just_like_my_chip_ How and where do I find the information required to make it work? Assumptions: 1) I do not know or understand TCL - example: if statements look sort of weird. I reasonably understand rather basic "script like languages" 2) I have a data sheet for part X - and the matching X.cfg file It is basically identical to my chip - the size of the flash different. And there are a few more/less peripherals on chip. 3) I have a data sheet for the NEW part and need to create a .CFG file. I can understand a data sheet - that's what I do for work. I am a reasonably competent HW/SW embedded firmware engineer. Question: Using Method (A) or method (B) What single file or multiple files(plural) do I modify or create? If modifying - what parts of that file do I modify? If not modifying - what do I read to understand? Is it simple and clear? Are there any special rules I must follow? how would I discover it is "set FLASH_SIZE"? There is no mention of this in the CHIP configuration file. To answer your example issue questions... >> With your version the first thing the end user would notice is >> "what the hell is the variant?" I would expect some reasonable #comment in the configuration file. >> The same goes for RAM, user would enter 40kB for lpc2148, >> and that would not be right, as only 32k of those are on the >> local bus, the rest is for USB DMA. I would expect to find a reasonable comment in the CFG file that describes this scenario, for example: # ram size is 32K # extra 8K is for usb, not usable by OpenoCD set RAM_SIZE 0x8000 a reasonably competent engineer with a data sheet should understand that comment. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Beagleboard post reset event
On Monday 07 September 2009, Øyvind Harboe wrote: > 1. test that a robust post reset event can be written for Beagleboard > that handles the "100 clocks after reset" problems. With jtag configure $_CHIPNAME.jrc -event post-reset "runtest 100" when I "reset" at tcl I get "There are no enabled taps?" when that event handler runs. And sure enough the JRC got disabled; not clear how. But that only shows if a post-reset handler is installed... Odd! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Beagleboard post reset event
take #2...
There was a bug in waiting in the code that handled tap
events when more than 2 event types were added
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/flash/str9xpec.c
===
--- src/flash/str9xpec.c(revision 2672)
+++ src/flash/str9xpec.c(working copy)
@@ -1254,7 +1254,8 @@
return ERROR_FAIL;
/* exit turbo mode via RESET */
- str9xpec_set_instr(tap, ISC_NOOP, TAP_RESET);
+ str9xpec_set_instr(tap, ISC_NOOP, TAP_IDLE);
+ jtag_add_tlr();
jtag_execute_queue();
/* restore previous scan chain */
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 2672)
+++ src/jtag/jtag.h (working copy)
@@ -208,6 +208,7 @@
JTAG_TRST_ASSERTED,
JTAG_TAP_EVENT_ENABLE,
JTAG_TAP_EVENT_DISABLE,
+ JTAG_TAP_EVENT_POST_RESET,
};
struct jtag_tap_event_action_s
@@ -635,6 +636,9 @@
/// @returns the number of times the scan queue has been flushed
int jtag_get_flush_queue_count(void);
+/// Notify all TAP's about a TLR reset
+void jtag_notify_reset(void);
+
/* can be implemented by hw + sw */
extern int jtag_power_dropout(int* dropout);
Index: src/jtag/core.c
===
--- src/jtag/core.c (revision 2672)
+++ src/jtag/core.c (working copy)
@@ -62,6 +62,7 @@
{
[JTAG_TRST_ASSERTED] = "JTAG controller reset (TLR or TRST)",
[JTAG_TAP_EVENT_ENABLE] = "TAP enabled",
+ [JTAG_TAP_EVENT_POST_RESET] = "post reset",
[JTAG_TAP_EVENT_DISABLE] = "TAP disabled",
};
@@ -339,6 +340,8 @@
void jtag_add_ir_scan(int in_num_fields, scan_field_t *in_fields, tap_state_t
state)
{
+ assert(state != TAP_RESET);
+
if (jtag_verify && jtag_verify_capture_ir)
{
/* 8 x 32 bit id's is enough for all invocations */
@@ -361,6 +364,8 @@
void jtag_add_plain_ir_scan(int in_num_fields, const scan_field_t *in_fields,
tap_state_t state)
{
+ assert(state != TAP_RESET);
+
jtag_prelude(state);
int retval = interface_jtag_add_plain_ir_scan(
@@ -439,6 +444,8 @@
void jtag_add_dr_scan(int in_num_fields, const scan_field_t *in_fields,
tap_state_t state)
{
+ assert(state != TAP_RESET);
+
jtag_prelude(state);
int retval;
@@ -449,6 +456,8 @@
void jtag_add_plain_dr_scan(int in_num_fields, const scan_field_t *in_fields,
tap_state_t state)
{
+ assert(state != TAP_RESET);
+
jtag_prelude(state);
int retval;
@@ -460,6 +469,8 @@
int num_fields, const int* num_bits, const uint32_t* value,
tap_state_t end_state)
{
+ assert(end_state != TAP_RESET);
+
assert(end_state != TAP_INVALID);
cmd_queue_cur_state = end_state;
@@ -473,6 +484,9 @@
{
jtag_prelude(TAP_RESET);
jtag_set_error(interface_jtag_add_tlr());
+
+ jtag_notify_reset();
+
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
@@ -683,6 +697,8 @@
LOG_DEBUG("TRST line released");
if (jtag_ntrst_delay)
jtag_add_sleep(jtag_ntrst_delay * 1000);
+
+ jtag_notify_reset();
}
}
}
@@ -851,7 +867,8 @@
for (unsigned i = 0; i < JTAG_MAX_CHAIN_SIZE; i++)
buf_set_u32(idcode_buffer, i * 32, 32, 0x00FF);
- jtag_add_plain_dr_scan(1, &field, TAP_RESET);
+ jtag_add_plain_dr_scan(1, &field, TAP_DRPAUSE);
+ jtag_add_tlr();
return jtag_execute_queue();
}
@@ -1065,7 +1082,9 @@
field.in_value = ir_test;
- jtag_add_plain_ir_scan(1, &field, TAP_RESET);
+ jtag_add_plain_ir_scan(1, &field, TAP_IRPAUSE);
+ jtag_add_tlr();
+
int retval;
retval = jtag_execute_queue();
if (retval != ERROR_OK)
Index: src/jtag/tcl.c
===
--- src/jtag/tcl.c (revision 2672)
+++ src/jtag/tcl.c (working copy)
@@ -41,6 +41,7 @@
#endif
static const Jim_Nvp nvp_jtag_tap_event[] = {
+ { .value = JTAG_TAP_EVENT_POST_RESET, .name = "post-reset" },
{ .value = JTAG_TAP_EVENT_ENABLE, .name = "tap-enable" },
{ .value = JTAG_TAP_EVENT_DISABLE, .name = "tap-disable" },
@@ -374,7 +375,8 @@
* can't fail. That presumes later code
* will be verifying the scan chains ...
*/
- tap->enabled = (e == JTAG_TAP_EVENT_ENABLE);
+ if (e == JTAG_TAP_EVENT_ENABLE)
+
Re: [Openocd-development] PXA270 problems
On Tue, Sep 8, 2009 at 8:50 PM, Sergey Lapin wrote: > Hi, all! > > When working with PXA270 I see the following messages on reset. > > JTAG tap: pxa270.cpu tap/device found: 0x49265013 (mfg: 0x009, part: > 0x9265, ver: 0x4) > value captured during scan didn't pass the requested check: > captured: 0x00 check_value: 0x02 check_mask: 0x07 > JTAG error while writing DCSR > value captured during scan didn't pass the requested check: > captured: 0x00 check_value: 0x01 check_mask: 0x7F > value captured during scan didn't pass the requested check: > captured: 0x00 check_value: 0x01 check_mask: 0x7F > Unimplemented instruction, could not simulate it. Anyone got a PXA270 to donate so I can test? > Working with CPU is very unstable. > I use Olimex ARM-USB-OCD, under Linux with libftdi. > I also use patch which fixes monitor loading, from Øyvind, Which patch is this? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] PXA270 problems
Hi, all! When working with PXA270 I see the following messages on reset. JTAG tap: pxa270.cpu tap/device found: 0x49265013 (mfg: 0x009, part: 0x9265, ver: 0x4) value captured during scan didn't pass the requested check: captured: 0x00 check_value: 0x02 check_mask: 0x07 JTAG error while writing DCSR value captured during scan didn't pass the requested check: captured: 0x00 check_value: 0x01 check_mask: 0x7F value captured during scan didn't pass the requested check: captured: 0x00 check_value: 0x01 check_mask: 0x7F Unimplemented instruction, could not simulate it. Working with CPU is very unstable. I use Olimex ARM-USB-OCD, under Linux with libftdi. I also use patch which fixes monitor loading, from Øyvind, I can do basic commands like mww or mdw on SRAM, but loading images generally fail due to timeouts, which makes me reset hardware. Single SRAM writes, like mww 0x5C00 0xdeadbeef work perfectly. Config: set CPUTAPID 0x49265013 source [find interface/olimex-arm-usb-ocd.cfg] source [find target/pxa270.cfg] reset_config trst_and_srst separate jtag_nsrst_delay 2000 jtag_ntrst_delay 2000 flash bank cfi 0x 0x100 2 4 0 jtag_khz 8 All the best, S. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1, 2] More fixes for Thumb state debugging
No furter comments received. Commited. Best regards, Magnus Magnus Lundin wrote: > Here are two very small patches. > > The first one fixes the reporting of instruction state. > > The second one makes sure the processor stays in Thumb state when > restoring the PC. > > After this it is possible to single step Thumb code. > > Best regards, > Magnus > > > > > ___ > 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 current SVN regression on s3c6410
Øyvind Harboe schrieb: > Does anyone have an s3c6410 PCB out there they > could donate to us? I am currently working on a S3C6410 based board but I have only some samples here. I hope that we can go in production in october and that I can convince my boss to donate one. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Duane Ellis pisze: > As an *end*user* if I saw a sequence of filenames that I recognized I > could examine a few of them - see the simple pattern and settings and > could probably follow that simple pattern successfully. By simple I > mean: perform lots of "set VARNAME VALUE" - then include/source a > common file. > Most developers would understand and modify a simple TCL statement like > this with great success: > ># This chip has 16K flash.. >set FLASH_SIZE 0x4000 > > But instead, using Freddies' approach - one has to (or is lead to > believe they must) read through the "complicated internals" file which > is where lots of magic is happening - magic that is to the benefit of > the maintainer who understands the complexities of the chip family, and > the scripts, and perhaps knows a little bit of TCL. I still cannot agree on that. Which version is better: Your: > global CHIPNAME > set CHIPNAME lpc2103 > global FLASH_SIZE > set FLASH_SIZE ... > global RA_SIZE > set RAM_SIZE ... > global RESET_CONFIG > set RESET_CONFIG srst_and_trst > global VARIANT > set VARIANT lpc2000_v2 > global CRYSTAL_FREQ > set CRYSTAL_FREQ 1200 > global JTAG_FREQ > set JTAG_FREQ 100 > > source [find target/lpc2xxx_internals.tcl] or mine: > set CHIPNAME lpc2103 > set CRYSTAL_FREQ 1200 > set JTAG_FREQ 100 > > source [find target/lpc2xxx_internals.tcl] With your version the first thing the end user would notice is "what the hell is the variant?" and that does not matter to the end user which flashing algorithm OpenOCD uses. For LPC2xx8 he would enter: FLASH_SIZE 0x8, start the OpenOCD and be puzzled that this value is invalid, because you need to dig deep to find out, that the top 12k are occupied by bootloader. The same goes for RAM, user would enter 40kB for lpc2148, and that would not be right, as only 32k of those are on the local bus, the rest is for USB DMA. Sure - eventually all would figure that out. But that's easier to figure out just the name and the clock, not all the parameters. Using my version of the file you can do exatly the same as with your version, as ALL variables can be overriden. The bonus is that you do not need that "global sth" everywhere. You can use that script for a chip that is not implemented there withou any trouble. You suggest "taking the developer hat off", but it seems that your's is on all the time. End users do not mess with the config files - what for? 99% of the time they are good, so why change anything there? Anyway - what would you like to change? Beside JTAG_FREQ and CRYSTAL_FREQ all other parameters are useless for normal user. I also see no reason for the user to dig through the _internals.tcl file... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] C-code style & indent utility
Hello, all. Can anyone suggest what options should be passed to the "indent", to format the source code under the rules of formatting C-code ? Thank you. -- Regards, Alexei Babich, circuit design engineer, Rezonans plc., Chelyabinsk, Russia http://www.rez.ru Jabber ID: imp...@jabber.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
