[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] [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
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] 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
[Openocd-development] tcl event bug fixes
Committed.
- Fix bug-in-waiting when adding more than one TAP event type
- Infinite loop bugfix when running tap configure a second time
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/tcl.c
===
--- src/jtag/tcl.c (revision 2652)
+++ src/jtag/tcl.c (working copy)
@@ -141,9 +141,11 @@
}
if (goi-isconfigure) {
+ bool replace = true;
if (jteap == NULL) {
/* create new */
jteap = calloc(1,
sizeof (*jteap));
+ replace = false;
}
jteap-event = n-value;
Jim_GetOpt_Obj(goi, o);
@@ -153,9 +155,12 @@
jteap-body =
Jim_DuplicateObj(goi-interp, o);
Jim_IncrRefCount(jteap-body);
- /* add to head of event list */
- jteap-next = tap-event_action;
- tap-event_action = jteap;
+ if (!replace)
+ {
+ /* add to head of event
list */
+ jteap-next =
tap-event_action;
+ tap-event_action =
jteap;
+ }
Jim_SetEmptyResult(goi-interp);
} else {
/* get */
@@ -374,7 +379,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)
+ tap-enabled = true;
}
}
___
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 #3...
I committed a fix for a bug where running jtag configure twice would
cause an infinite loop upon event nofitication, but it still bothers me that
jtag configure was invoked twice...
--
Ø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 2652)
+++ 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 2652)
+++ 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 2652)
+++ 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 2681)
+++ 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 },
@@ -583,6 +584,17 @@
return JIM_ERR;
}
+
+void jtag_notify_reset(void)
+{
+ jtag_tap_t *tap;
+ for (tap = jtag_all_taps(); tap; tap = tap-next_tap)
+ {
+ jtag_tap_handle_event(tap, JTAG_TAP_EVENT_POST_RESET);
+ }
+}
+
+
int jtag_register_commands(struct
Re: [Openocd-development] PXA270 problems
On Wed, Sep 9, 2009 at 9:39 AM, Michael Schwingenrincew...@discworld.dascon.de wrote: Øyvind Harboe wrote: 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. Maybe we should commit that fix as a temporary solution until someone fixes the automake files? Ah! Should we commit kludges or wait for a proper fix? There is a good workaround for this, use the -s option. No patch is necessary. What's annoying is that we had a working state, which was later broken - and the breakage was never taken back or fixed. Something else was fixed that broke this... yes. Don't ask me about install issues under various *nix distributions... -- Ø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
Sorry, forgot to Cc list
-- Forwarded message --
From: Sergey Lapin slapi...@gmail.com
Date: Wed, Sep 9, 2009 at 12:00 PM
Subject: Re: [Openocd-development] PXA270 problems
To: Øyvind Harboe oyvind.har...@zylin.com
On Wed, Sep 9, 2009 at 11:45 AM, Øyvind Harboeoyvind.har...@zylin.com wrote:
On Wed, Sep 9, 2009 at 9:39 AM, Michael
Schwingenrincew...@discworld.dascon.de wrote:
Øyvind Harboe wrote:
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.
Maybe we should commit that fix as a temporary solution until someone
fixes the automake files?
Ah!
Should we commit kludges or wait for a proper fix?
There is a good workaround for this, use the -s option. No patch
is necessary.
What's annoying is that we had a working state, which was later broken -
and the breakage was never taken back or fixed.
Something else was fixed that broke this... yes. Don't ask me
about install issues under various *nix distributions...
I just don't understand what really do you want to fix as proper fix.
We have ${prefix}/lib/openocd/, which is PKGLIBDIR. Do you want to
install all that to PKGDATADIR (${prefix}/share/openocd)?
Or what goal do you want to achieve? as I understand, everything which
is installed to lib is not found. Does -s option adds search paths,
or redefines default one?
All the best,
S.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA270 problems
I just don't understand what really do you want to fix as proper fix.
We have ${prefix}/lib/openocd/, which is PKGLIBDIR. Do you want to
install all that to PKGDATADIR (${prefix}/share/openocd)?
You'll have to start a new thread on this. I attempted a fix, but I was
told it wouldn't work on all distributions, so I decided not to get involved.
Perhaps you can post the patch and suggest that it should be applied
and then perhaps we can hear the protests again?
See TODO for more details.
--
Ø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] xscale debug_handler.bin
Hi, all!
TODO does have the following entry:
- regression: xscale does not place debug_handler.bin into the right
spot. workaround:
use -s option on command line to place xscale/debug_handler.bin in
search path.
And, really, ${prefix}/lib/openocd/xscale is not within scripts search path.
We can:
* add PKGLIBDIR ($prefix/lib/openocd) to scripts search path.
* add xscale/debug_handler.bin to PKGDATADIR ($prefix/share/openocd/...)
* add xscale/debug_handler.bin to $libexecdir/openocd, and add that
path to scripts search dir.
What solution is more appropriate? Might be something else?
All the best,
S.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] sync command
One problem with GDB is that it can get out of sync with the target. While GDB believes that the target is in the halted mode, the target could be running, powered down, halted, etc. Here is an idea: - add a new command to OpenOCD, sync. When this is issued on a target, the next step command will be a no-op. - when needing to sync up GDB to the target state, issue a monitor sync + stepi. A similar scheme would be required for attaching to OpenOCD as GDB is trying to halt the target upon connection. OpenOCD would then issue an implicit sync upon attaching to the target. GDB will query the target for the register values after connect, upon which it is told white lies today. A stepi immediately after connecting GDB to OpenOCD would then be required to sync up GDB to the target state Thoughts? -- Ø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: cfi.c: Improved support for some flash devices
Hi,
This patch adds target algorithm support for those flash devices that do not
support DQ5 polling. So far they could only be programmed with host algorithm,
but this was way too slow.
I added support for 16-bit devices only (I have an SST39VF3201). I didn't want
to add support for 8 and 32 bit without being able to test the assembler code.
The different assembler code fragments can now be of arbitrary size (fixed a
hard coded value).
All working areas are now freed at the end of cfi_spansion_write_block(). This
fixes a bug (cfi_info-write_algorithm wasn't freed before, and caused a crash
when the write function was called again). It also prevents the working_area
from becoming fragmented in two halfes.
Regards,
Rolf
Index: src/flash/cfi.c
===
--- src/flash/cfi.c (revision 2681)
+++ src/flash/cfi.c (working copy)
@@ -1384,6 +1384,31 @@
0xeafe /* b 81ac sp_16_done */
};
+ static const uint32_t word_16_code_dq7only[] = {
+/* sp_16_code: */
+ 0xe0d050b2, /* ldrh r5, [r0], #2 */
+ 0xe1c890b0, /* strh r9, [r8] */
+ 0xe1cab0b0, /* strh r11, [r10]*/
+ 0xe1c830b0, /* strh r3, [r8]*/
+ 0xe1c150b0, /* strh r5, [r1] */
+ 0xe1a0, /* nop (mov r0,r0)*/
+/* */
+/* sp_16_busy: */
+ 0xe1d160b0, /* ldrh r6, [r1] */
+ 0xe0257006, /* eor r7, r5, r6 */
+ 0xe2177080, /* ands r7, #0x80 */
+ 0x1afb, /* bne 8168 sp_16_busy */
+/* */
+ 0xe2522001, /* subs r2, r2, #1 ; 0x1 */
+ 0x03a05080, /* moveq r5, #128 ; 0x80 */
+ 0x0a01, /* beq 81ac sp_16_done */
+ 0xe2811002, /* add r1, r1, #2 ; 0x2 */
+ 0xeaf0, /* b 8158 sp_16_code */
+/* */
+/* 81ac sp_16_done: */
+ 0xeafe /* b 81ac sp_16_done */
+ };
+
static const uint32_t word_8_code[] = {
/* 81b0 sp_16_code_end: */
0xe4d05001, /* ldrb r5, [r0], #1 */
@@ -1423,10 +1448,10 @@
armv4_5_info.core_state = ARMV4_5_STATE_ARM;
/* flash write code */
+ int target_code_size;
if (!cfi_info-write_algorithm)
{
uint8_t *target_code;
- int target_code_size;
const uint32_t *src;
/* convert bus-width dependent algorithm code to correct endiannes */
@@ -1437,8 +1462,18 @@
target_code_size = sizeof(word_8_code);
break;
case 2:
- src = word_16_code;
- target_code_size = sizeof(word_16_code);
+ /* Check for DQ5 support */
+ if( cfi_info-status_poll_mask (1 5) )
+ {
+src = word_16_code;
+target_code_size = sizeof(word_16_code);
+ }
+ else
+ {
+/* No DQ5 support. Use DQ7 DATA# polling only. */
+src = word_16_code_dq7only;
+target_code_size = sizeof(word_16_code_dq7only);
+ }
break;
case 4:
src = word_32_code;
@@ -1515,7 +1550,7 @@
retval = target_run_algorithm(target, 0, NULL, 10, reg_params,
cfi_info-write_algorithm-address,
- cfi_info-write_algorithm-address + ((24 * 4) - 4),
+ cfi_info-write_algorithm-address + ((target_code_size) - 4),
1, armv4_5_info);
status = buf_get_u32(reg_params[5].value, 0, 32);
@@ -1532,7 +1567,7 @@
count -= thisrun_count;
}
- target_free_working_area(target, source);
+ target_free_all_working_areas(target);
destroy_reg_param(reg_params[0]);
destroy_reg_param(reg_params[1]);
Index: src/flash/non_cfi.c
===
--- src/flash/non_cfi.c (revision 2681)
+++ src/flash/non_cfi.c (working copy)
@@ -140,7 +140,10 @@
/* SST 39VF* do not support DQ5 status polling - this currently is
only supported by the host algorithm, not by the target code using
- the work area. */
+ the work area.
+ Only true for 8-bit and 32-bit wide memories. 16-bit wide memories
+ without DQ5 status polling are supported by the target code.
+*/
{
.mfr = CFI_MFR_SST,
.id = 0x2782,/* SST39xF160 */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH: cfi.c: Improved support for some flash devices
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
