Re: [Openocd-development] Request of feature freeze
You didn't talk about when you cut the branch. I don't think we want to slow down development in svn head for much more than a week or two? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] More printf fixes
Anyone have a chance to test on Linux? svn head builds on my Debian box this morning. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Broken r1870 (head)
Looking at your configuration scripts, they should *not* call init once they are implemented correctly. This does mean that omap3.cpu has to be enabled *before* it can be used (?) On the other hand, in previous discussion, we had learned that init has to be called *after* target create. But from some tests, it seems that init has to be called *before* tapenable. Do you see the deadlock? How to resolve this? We may need to iron out a few issues in OpenOCD... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] More printf fixes
On Thursday 21 May 2009, Rick Altherr wrote: Yeah, given that it is an integer and of variable size, casting to intmax_t is probably appropriate. Please try the attached patch. The '%j' format worked on an x86_64 build. Live and learn... I'd never heard of '%j' before! Next thing you know, '\09' will finally stop working... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Broken r1870 (head)
Øyvind Harboe wrote: Looking at your configuration scripts, they should *not* call init once they are implemented correctly. Do you like to give any hints how to implement them correctly and what do you think is wrong with them? We talk about http://svn.berlios.de/svnroot/repos/openocd/trunk/src/target/board/ti_beagleboard.cfg http://svn.berlios.de/svnroot/repos/openocd/trunk/src/target/target/omap3530.cfg This does mean that omap3.cpu has to be enabled *before* it can be used (?) On the other hand, in previous discussion, we had learned that init has to be called *after* target create. But from some tests, it seems that init has to be called *before* tapenable. Do you see the deadlock? How to resolve this? We may need to iron out a few issues in OpenOCD... What do you propose OMAP3 people to do until this is done? Stay with an older version? E.g. 1606 which Magnus uses? Many thanks Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Request of feature freeze
On Thursday 21 May 2009, Øyvind Harboe wrote: You didn't talk about when you cut the branch. I don't think we want to slow down development in svn head for much more than a week or two? Alternatively, isn't the branch where all non-essential stuff should be parked until head is stabilized and cuts the release? With everyone focussing energy on the release, instead of any non-essential stuff? (Or what lots of folk do: private quilt series, updated as needed, until head opens to non-bugfix patches.) Agreed that key when parts were missing. Pending a working testing/QA/bug tracking proposal ... should there at least be a working schedule the next release? Maybe like: 25 May (Monday) -- last features go in ... four weeks of stability/testing/fixing/polish ... with weekly milestone labels, RC1, RC2, etc 22 June (Monday) -- target for release That's just an idea. Maybe three weeks of focussed work is a better target; only take another if that doesn't suffice. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SAM7S256 is broken by 1825
Hello Øyvind, Does svn head work if you use 1824 for ft2232.c only? I have make a new test, copy of the 1872 do not help only. I must use the long sequence too: tms_sequence long This mean, I must copy the 1824 over the 1872 and use the long sequence to get the SAM and LPC working. Best regards, Michael -Ursprüngliche Nachricht- Von: oyvindhar...@gmail.com [mailto:oyvindhar...@gmail.com]im Auftrag von Øyvind Harboe Gesendet: Donnerstag, 21. Mai 2009 18:11 An: Michael Fischer Cc: Openocd-Dev Betreff: Re: [Openocd-development] SAM7S256 is broken by 1825 On Thu, May 21, 2009 at 4:43 PM, Michael Fischer fische...@t-online.de wrote: Hello list, reference is made to Strange behavior with r1857 and SAM7S256: https://lists.berlios.de/pipermail/openocd-development/2009-May/006929.html The last version which is working is the r1824, the r1825 makes the problems. Does svn head work if you use 1824 for ft2232.c only? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: relocate configuration scripts?
On Thu, 2009-05-21 at 22:38 -0400, Duane Ellis wrote:
Zach
static inline functions should be preferred over macros, yes.
I personally despise 'static inline' functions.
One cannot never set breakpoints on them, because the debugger cannot
figure out *which* instance you want to set the breakpoint at.
That is true of a call to any small well-used function (not just inline
ones), so I'm not sure that I understand your point. Certainly, I am
not sure how the other alternatives really make debugging all that much
easier or better. If anything, macros are more dangerous.
The first Google result for 'static inline or macros' gave me the
following page, which I think makes the argument fairly clear:
https://www.securecoding.cert.org/confluence/display/seccode/PRE00-C.+Prefer+inline+or+static+functions+to+function-like+macros
As this shows, programmers that always expect macros to work like
functions are in for a huge surprise when using a macro like this:
#define CUBE(n) ((n) * (n) * (n))
...
y = CUBE(x++);
but the same invocation would have worked fine with a function:
static inline cube(int n) { return n * n * n; }
...
y = cube(x++);
Honestly, I would prefer to read the second one, and debugging it will
be easier because programmers will not need to worry about these kinds
of side-effects occurring.
Bottom line: static inline functions should be preferred over macros in
all new C99 code.
Cheers,
Zach
P.S. Debuggers are for wimps. ;)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Broken r1870 (head)
I'm going to be out of the office for the next week, so I'm turning into
a pumpkin RSN.
omap3_dbginit should be made part of the reset sequence.
OpenOCD supports hot-plugging of targets. Feel free to scream, but this
is something that developers do since it saves time. If it bricks a beagleboard
a year, it is still a bargain :-)
There is a *slight* bit of autoconfiguration going on with OpenOCD. The
target is examined (during startup and/or reset sequence) so that e.g.
version of debug hardware and hardware capabilities can be read out
and OpenOCD structures can be set up.
I believe the best approach with OMAP would be to set up the entire
JTAG system during reset and not rely on rexamine upon startup.
Try the attached patch and call in the morning...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 1805)
+++ src/target/cortex_m3.c (working copy)
@@ -63,7 +63,7 @@
.arch_state = armv7m_arch_state,
.target_request_data = cortex_m3_target_request_data,
-
+
.halt = cortex_m3_halt,
.resume = cortex_m3_resume,
.step = cortex_m3_step,
@@ -71,7 +71,7 @@
.assert_reset = cortex_m3_assert_reset,
.deassert_reset = cortex_m3_deassert_reset,
.soft_reset_halt = cortex_m3_soft_reset_halt,
-
+
.get_gdb_reg_list = armv7m_get_gdb_reg_list,
.read_memory = cortex_m3_read_memory,
@@ -79,9 +79,9 @@
.bulk_write_memory = cortex_m3_bulk_write_memory,
.checksum_memory = armv7m_checksum_memory,
.blank_check_memory = armv7m_blank_check_memory,
-
+
.run_algorithm = armv7m_run_algorithm,
-
+
.add_breakpoint = cortex_m3_add_breakpoint,
.remove_breakpoint = cortex_m3_remove_breakpoint,
.add_watchpoint = cortex_m3_add_watchpoint,
@@ -151,12 +151,12 @@
armv7m_common_t *armv7m = target-arch_info;
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
-
+
/* mask off status bits */
cortex_m3-dcb_dhcsr = ~((0x 16) | mask_off);
/* create new register mask */
cortex_m3-dcb_dhcsr |= DBGKEY | C_DEBUGEN | mask_on;
-
+
return mem_ap_write_atomic_u32(swjdp, DCB_DHCSR, cortex_m3-dcb_dhcsr);
}
@@ -166,10 +166,10 @@
armv7m_common_t *armv7m = target-arch_info;
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
-
+
/* clear step if any */
cortex_m3_write_debug_halt_mask(target, C_HALT, C_STEP);
-
+
/* Read Debug Fault Status Register */
mem_ap_read_atomic_u32(swjdp, NVIC_DFSR, cortex_m3-nvic_dfsr);
/* Write Debug Fault Status Register to enable processing to resume ??
Try with and without this !! */
@@ -186,20 +186,20 @@
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
u32 dhcsr_save;
-
+
/* backup dhcsr reg */
dhcsr_save = cortex_m3-dcb_dhcsr;
-
+
/* mask interrupts if not done already */
if (!(cortex_m3-dcb_dhcsr C_MASKINTS))
mem_ap_write_atomic_u32(swjdp, DCB_DHCSR, DBGKEY | C_MASKINTS |
C_HALT | C_DEBUGEN);
mem_ap_write_atomic_u32(swjdp, DCB_DHCSR, DBGKEY | C_MASKINTS | C_STEP
| C_DEBUGEN);
LOG_DEBUG( );
-
+
/* restore dhcsr reg */
- cortex_m3-dcb_dhcsr = dhcsr_save;
+ cortex_m3-dcb_dhcsr = dhcsr_save;
cortex_m3_clear_halt(target);
-
+
return ERROR_OK;
}
@@ -210,14 +210,14 @@
swjdp_common_t *swjdp = armv7m-swjdp_info;
u32 savedram;
int retvalue;
-
+
mem_ap_read_u32(swjdp, 0x2000, savedram);
mem_ap_write_u32(swjdp, 0x2000, opcode);
cortexm3_dap_write_coreregister_u32(swjdp, 0x2000, 15);
cortex_m3_single_step_core(target);
armv7m-core_cache-reg_list[15].dirty =
armv7m-core_cache-reg_list[15].valid;
retvalue = mem_ap_write_atomic_u32(swjdp, 0x2000, savedram);
-
+
return retvalue;
}
@@ -239,28 +239,28 @@
{
int i;
u32 dcb_demcr;
-
+
/* get pointers to arch-specific information */
armv7m_common_t *armv7m = target-arch_info;
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
- cortex_m3_fp_comparator_t *fp_list = cortex_m3-fp_comparator_list;
+ cortex_m3_fp_comparator_t *fp_list = cortex_m3-fp_comparator_list;
cortex_m3_dwt_comparator_t *dwt_list = cortex_m3-dwt_comparator_list;
mem_ap_read_atomic_u32(swjdp, DCB_DEMCR, dcb_demcr);
LOG_DEBUG(DCB_DEMCR =
Re: [Openocd-development] Broken r1870 (head)
Øyvind Harboe wrote: I'm going to be out of the office for the next week, so I'm turning into a pumpkin RSN. omap3_dbginit should be made part of the reset sequence. OpenOCD supports hot-plugging of targets. Feel free to scream, but this is something that developers do since it saves time. If it bricks a beagleboard a year, it is still a bargain :-) There is a *slight* bit of autoconfiguration going on with OpenOCD. The target is examined (during startup and/or reset sequence) so that e.g. version of debug hardware and hardware capabilities can be read out and OpenOCD structures can be set up. I believe the best approach with OMAP would be to set up the entire JTAG system during reset and not rely on rexamine upon startup. Try the attached patch and call in the morning... Are you sure that you attached the right patch? The attached one seems to be a src/target/cortex_m3.c whitespace fix one, only? See below. Best regards Dirk Index: src/target/cortex_m3.c === --- src/target/cortex_m3.c (revision 1805) +++ src/target/cortex_m3.c (working copy) @@ -63,7 +63,7 @@ .arch_state = armv7m_arch_state, .target_request_data = cortex_m3_target_request_data, - + .halt = cortex_m3_halt, .resume = cortex_m3_resume, .step = cortex_m3_step, @@ -71,7 +71,7 @@ .assert_reset = cortex_m3_assert_reset, .deassert_reset = cortex_m3_deassert_reset, .soft_reset_halt = cortex_m3_soft_reset_halt, - + .get_gdb_reg_list = armv7m_get_gdb_reg_list, .read_memory = cortex_m3_read_memory, @@ -79,9 +79,9 @@ .bulk_write_memory = cortex_m3_bulk_write_memory, .checksum_memory = armv7m_checksum_memory, .blank_check_memory = armv7m_blank_check_memory, - + .run_algorithm = armv7m_run_algorithm, - + .add_breakpoint = cortex_m3_add_breakpoint, .remove_breakpoint = cortex_m3_remove_breakpoint, .add_watchpoint = cortex_m3_add_watchpoint, @@ -151,12 +151,12 @@ armv7m_common_t *armv7m = target-arch_info; cortex_m3_common_t *cortex_m3 = armv7m-arch_info; swjdp_common_t *swjdp = armv7m-swjdp_info; - + /* mask off status bits */ cortex_m3-dcb_dhcsr = ~((0x 16) | mask_off); /* create new register mask */ cortex_m3-dcb_dhcsr |= DBGKEY | C_DEBUGEN | mask_on; - + return mem_ap_write_atomic_u32(swjdp, DCB_DHCSR, cortex_m3-dcb_dhcsr); } @@ -166,10 +166,10 @@ armv7m_common_t *armv7m = target-arch_info; cortex_m3_common_t *cortex_m3 = armv7m-arch_info; swjdp_common_t *swjdp = armv7m-swjdp_info; - + /* clear step if any */ cortex_m3_write_debug_halt_mask(target, C_HALT, C_STEP); - + /* Read Debug Fault Status Register */ mem_ap_read_atomic_u32(swjdp, NVIC_DFSR, cortex_m3-nvic_dfsr); /* Write Debug Fault Status Register to enable processing to resume ?? Try with and without this !! */ @@ -186,20 +186,20 @@ cortex_m3_common_t *cortex_m3 = armv7m-arch_info; swjdp_common_t *swjdp = armv7m-swjdp_info; u32 dhcsr_save; - + /* backup dhcsr reg */ dhcsr_save = cortex_m3-dcb_dhcsr; - + ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Request of feature freeze
On Thursday 21 May 2009, Rick Altherr wrote: On May 21, 2009, at 5:02 PM, David Brownell wrote: Worth IMO drawing a distinction between core support and the rest. ... So I'd agree it's certainly time to work on stability for the core, no new features/functionality. But that should leave the door open to other bits, IMO. The process for stabilizing hasn't been well defined, so let me explain the process I've been following for the last few rounds of patches as well as what I use for my day job. I use risk vs reward along with the level of testing and time in the release cycle to determine if a path should be applied. Most of us do, yes. Although there are other dimensions that also come into play. For risk, I use the following criteria: None - Every change has risk. This is never used. Low - The changes either affect a small portion of the code base, are very small but repetitious throughout the code base, or are entirely mechanical in nature (running the code through a script) Medium - The changes affect more than one component in the code base, are medium-sized but repetitious, or change the semantics or output of an infrequently used command High - The changes affect 3 or more components in the code base, affect a core subsystem, are large but repetitious, change the semantics or output of any frequently used command, or may cause any sort of overall instability (crash, hang, etc) Low/medium/high is fair enough, though it's often not easy to quantify. For reward, I use the following: None - No actual impact to a typical user. These are things like changes to maintainer scripts, developer docs, etc. Low - Resolved issue affects a small portion of users, has only minor impact on a medium to large size user base (fixing typos, changing error message, etc), or provides minor improvement to ancillary installed items (documentation, helper scripts, contrib items) Medium - Resolved issue affects a medium-sized portion of the users or provides major improvement to ancillary installed items (docs, scripts, contrib items) High - Resolved issue affects a large portion of users or solves an overall instability issue (crash, hang, etc) Likewise, often hard to quantify. Talking about a typical user always raises my suspicions; there are all sizes and shapes. Might be worth thinking about a few different categories for now though. Maybe GDB user that wants to debug embedded no-MMU microcontroller code; Bootloader developer who's basically focussed on getting U-Boot into flash or de-bricking, working with new boards (or updating older ones); and so on. Unblocking some types of users can broaden the user community. Some of those users, in short, are potential. And one of the goals of new releases is to grow that user community. ;) After that, the decision process moves along a sliding scale based on time left until release: This implies some things about release schedule and process... 2 weeks before release - Must be medium or high reward with low risk. Must be tested on multiple interfaces and targets if appropriate. 4 weeks before release - Must be medium or high reward with low or medium risk. Must be tested on at least one interface and multiple targets if appropriate. I think we're probably now closer to 4 weeks than 2. Another dimension being: developers during that part of the cycle need to focus on finding and fixing bugs. 8 weeks before release - Any reward with low or medium risk. Testing highly preferred but not explicitly required. Over 8 weeks before release - Any well written patch will generally be accepted. Best if things *always* require testing, IMO, even if only from the original developer. :) These criteria are just guidelines to help patch authors understand what will be allowed when and to help maintainers decide which patches to apply. Of course, special circumstances can and do happen. If there is a patch that doesn't meet the criteria above but there is a good reason it should be applied for the release, the patch and the justification should be sent to the list for feedback from the community. If in doubt, send it to the list. Yes. If a patch is rejected solely because of the timing within the release cycle, it should be held and resubmitted once the current release is finished. Resubmitting being the responsibility of the initial developer, as with all resubmission (including split this up, please fix this problem, etc). Stuff like quilt makes it easy to maintain a series of patches on top of whatever SCM is involved, note. If the patch is rejected for any other reason, it should be reevaluated after any requested changes have been made. You never know if a 1 patch might have portions meet the criteria once it is broken up into smaller, logical chunks. I'm also open to suggestions on how
[Openocd-development] [patch] nand cleanups
Remove un-implemented and dubious nand copy command.
Doing this efficiently would mean doing the copying on
the target CPU, instead of back and forth through JTAG.
If anyone ever needs this functionality, that's what
they should implement.
Also, update on-line help for nand dump to display
its two optional flags; and for nand write to display
a recently added flag.
---
src/flash/nand.c | 31 +++
1 file changed, 3 insertions(+), 28 deletions(-)
Remove un-implemented and dubious nand copy command.
Doing this efficiently would mean doing the copying on
the target CPU, instead of back and forth through JTAG.
If anyone ever needs this functionality, that's what
they should implement.
Also, update on-line help for nand dump to display
its two optional flags; and for nand write to display
a recently added flag.
---
src/flash/nand.c | 31 +++
1 file changed, 3 insertions(+), 28 deletions(-)
--- a/src/flash/nand.c
+++ b/src/flash/nand.c
@@ -35,7 +35,6 @@ static int handle_nand_list_command(stru
static int handle_nand_probe_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
static int handle_nand_check_bad_blocks_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
static int handle_nand_info_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
-static int handle_nand_copy_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
static int handle_nand_write_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
static int handle_nand_dump_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
static int handle_nand_erase_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
@@ -311,12 +310,11 @@ int nand_init(struct command_context_s *
check NAND flash device num for bad blocks [first last]);
register_command(cmd_ctx, nand_cmd, erase, handle_nand_erase_command, COMMAND_EXEC,
erase blocks on NAND flash device num first last);
- register_command(cmd_ctx, nand_cmd, copy, handle_nand_copy_command, COMMAND_EXEC,
- copy from NAND flash device num offset length ram-address);
register_command(cmd_ctx, nand_cmd, dump, handle_nand_dump_command, COMMAND_EXEC,
- dump from NAND flash device num filename offset size [options]);
+ dump from NAND flash device num filename
+ offset size [oob_raw|oob_only]);
register_command(cmd_ctx, nand_cmd, write, handle_nand_write_command, COMMAND_EXEC,
- write to NAND flash device num filename offset [oob_raw|oob_only|oob_softecc]);
+ write to NAND flash device num filename offset [oob_raw|oob_only|oob_softecc|oob_softecc_kw]);
register_command(cmd_ctx, nand_cmd, raw_access, handle_nand_raw_access_command, COMMAND_EXEC,
raw access to NAND flash device num ['enable'|'disable']);
}
@@ -1270,29 +1268,6 @@ int handle_nand_check_bad_blocks_command
return ERROR_OK;
}
-static int handle_nand_copy_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc)
-{
- nand_device_t *p;
-
- if (argc != 4)
- {
- return ERROR_COMMAND_SYNTAX_ERROR;
-
- }
-
- p = get_nand_device_by_num(strtoul(args[0], NULL, 0));
- if (p)
- {
-
- }
- else
- {
- command_print(cmd_ctx, NAND flash device '#%s' is out of bounds, args[0]);
- }
-
- return ERROR_OK;
-}
-
static int handle_nand_write_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc)
{
u32 offset;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: relocate configuration scripts?
On Thu, 2009-05-21 at 20:23 -0700, David Brownell wrote:
On Thursday 21 May 2009, Zach Welch wrote:
I feel like this is a dumb question but here goes Why [are] all
of the TCL configuration files (src/target/{target,board,interface}/*)
located in src/target/ instead of src/tcl/?
And why src instead of a toplevel config?
Why named .../*.cfg instead of .../*.tcl?
Regarding the extension: It's Tradition. [[ *cue Broadway music* ]]
There are too many documents (and .cfg files themselves) to buck it.
OpenOCD has been around for a while, and this would seriously confuse
things for users reading docs (on external sites that we can't update).
Also, because they are not really TCL scripts. They are Jim TCL
scripts, so -- if anything -- they should be renamed '.jim'
Myself, I would agree to 'svn mv src/tcl ${DST}', DST=tcl or DST=jim.
Other opinions? [[ *music swells* -- exeunt ]]
Why don't you make a proposal for a revised
structure. I'd plan for target/*.cfg and
board/*.cfg to grow enough that they'll
need another level; maybe targets should be
grouped by vendor sooner, rather than later.
I was trying to punt this architectural work to Wookey, but I have
already posted a similar idea in my reply to Duane. Since he expressed
the initial interest with the configuration files (and I know he can
handle the technical challenge), I was hoping to delegate this work,
either to him or someone else qualified Say... you would do
If someone does not take charge, I will commit the ideas to The List.
Ultimately, it will take a SVN committer to make these changes, but
someone else could probably write a script that will take the proper
actions for us
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] nand support
Hi, all! Do I miss something or OpenOCD do definitely have NAND support? For which processorts it exists? How hard it is po port that to at91sam9260? Thanks a lot, S. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] nand support
On Friday 22 May 2009, Sergey Lapin wrote: Do I miss something or OpenOCD do definitely have NAND support? It has nand support. src/flash/*nand*c ... and the current SVN finally has some documentation, which will I suspect appear at http://openocd.berlios.de/web/?page_id=54 within a few days. For which processorts it exists? Various ARMs. How hard it is po port that to at91sam9260? Shouldn't be hard to get basic soft-ecc working. Sort of like Orion ... I think the fast-download code there should be pulled out and made available for all ARMs with a DCC. But I'd encourage you to support its 1-bit hardware ECC logic too. Implement a write_page() using it. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Broken r1870 (head)
Trying again...
My editor is screwing things up with whitespace, hence all those irrelevant
changes...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 1805)
+++ src/target/cortex_m3.c (working copy)
@@ -63,7 +63,7 @@
.arch_state = armv7m_arch_state,
.target_request_data = cortex_m3_target_request_data,
-
+
.halt = cortex_m3_halt,
.resume = cortex_m3_resume,
.step = cortex_m3_step,
@@ -71,7 +71,7 @@
.assert_reset = cortex_m3_assert_reset,
.deassert_reset = cortex_m3_deassert_reset,
.soft_reset_halt = cortex_m3_soft_reset_halt,
-
+
.get_gdb_reg_list = armv7m_get_gdb_reg_list,
.read_memory = cortex_m3_read_memory,
@@ -79,9 +79,9 @@
.bulk_write_memory = cortex_m3_bulk_write_memory,
.checksum_memory = armv7m_checksum_memory,
.blank_check_memory = armv7m_blank_check_memory,
-
+
.run_algorithm = armv7m_run_algorithm,
-
+
.add_breakpoint = cortex_m3_add_breakpoint,
.remove_breakpoint = cortex_m3_remove_breakpoint,
.add_watchpoint = cortex_m3_add_watchpoint,
@@ -151,12 +151,12 @@
armv7m_common_t *armv7m = target-arch_info;
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
-
+
/* mask off status bits */
cortex_m3-dcb_dhcsr = ~((0x 16) | mask_off);
/* create new register mask */
cortex_m3-dcb_dhcsr |= DBGKEY | C_DEBUGEN | mask_on;
-
+
return mem_ap_write_atomic_u32(swjdp, DCB_DHCSR, cortex_m3-dcb_dhcsr);
}
@@ -166,10 +166,10 @@
armv7m_common_t *armv7m = target-arch_info;
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
-
+
/* clear step if any */
cortex_m3_write_debug_halt_mask(target, C_HALT, C_STEP);
-
+
/* Read Debug Fault Status Register */
mem_ap_read_atomic_u32(swjdp, NVIC_DFSR, cortex_m3-nvic_dfsr);
/* Write Debug Fault Status Register to enable processing to resume ??
Try with and without this !! */
@@ -186,20 +186,20 @@
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
u32 dhcsr_save;
-
+
/* backup dhcsr reg */
dhcsr_save = cortex_m3-dcb_dhcsr;
-
+
/* mask interrupts if not done already */
if (!(cortex_m3-dcb_dhcsr C_MASKINTS))
mem_ap_write_atomic_u32(swjdp, DCB_DHCSR, DBGKEY | C_MASKINTS |
C_HALT | C_DEBUGEN);
mem_ap_write_atomic_u32(swjdp, DCB_DHCSR, DBGKEY | C_MASKINTS | C_STEP
| C_DEBUGEN);
LOG_DEBUG( );
-
+
/* restore dhcsr reg */
- cortex_m3-dcb_dhcsr = dhcsr_save;
+ cortex_m3-dcb_dhcsr = dhcsr_save;
cortex_m3_clear_halt(target);
-
+
return ERROR_OK;
}
@@ -210,14 +210,14 @@
swjdp_common_t *swjdp = armv7m-swjdp_info;
u32 savedram;
int retvalue;
-
+
mem_ap_read_u32(swjdp, 0x2000, savedram);
mem_ap_write_u32(swjdp, 0x2000, opcode);
cortexm3_dap_write_coreregister_u32(swjdp, 0x2000, 15);
cortex_m3_single_step_core(target);
armv7m-core_cache-reg_list[15].dirty =
armv7m-core_cache-reg_list[15].valid;
retvalue = mem_ap_write_atomic_u32(swjdp, 0x2000, savedram);
-
+
return retvalue;
}
@@ -239,28 +239,28 @@
{
int i;
u32 dcb_demcr;
-
+
/* get pointers to arch-specific information */
armv7m_common_t *armv7m = target-arch_info;
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
- cortex_m3_fp_comparator_t *fp_list = cortex_m3-fp_comparator_list;
+ cortex_m3_fp_comparator_t *fp_list = cortex_m3-fp_comparator_list;
cortex_m3_dwt_comparator_t *dwt_list = cortex_m3-dwt_comparator_list;
mem_ap_read_atomic_u32(swjdp, DCB_DEMCR, dcb_demcr);
LOG_DEBUG(DCB_DEMCR = 0x%8.8x,dcb_demcr);
-
+
/* this regsiter is used for emulated dcc channel */
mem_ap_write_u32(swjdp, DCB_DCRDR, 0);
-
+
/* Enable debug requests */
mem_ap_read_atomic_u32(swjdp, DCB_DHCSR, cortex_m3-dcb_dhcsr);
if (!(cortex_m3-dcb_dhcsr C_DEBUGEN))
mem_ap_write_u32(swjdp, DCB_DHCSR, DBGKEY | C_DEBUGEN);
-
+
/* clear any interrupt masking */
cortex_m3_write_debug_halt_mask(target, 0, C_MASKINTS);
-
+
/* Enable trace and dwt */
mem_ap_write_u32(swjdp, DCB_DEMCR, TRCENA | VC_HARDERR | VC_BUSERR);
/* Monitor bus faults */
@@ -275,7 +275,7 @@
Re: [Openocd-development] SAM7S256 is broken by 1825
On Fri, May 22, 2009 at 11:08 AM, Michael Fischer fische...@t-online.de wrote: Hello list, I would suggest that ft2232.c 1824 is committed to trunk and that the newest version of ft2232.c is split into a series of patches. First commit all the harmless changes, then try to divide thinigs into real changes. But we should use the long sequence as default? In this case we have a working solution. And for testing we can enable the short sequence and can check step by step which patch breaks the functionality. Good question. You'll have to follow up with the rest of the guys, I'm out of the office until june 2. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] PATCH] [0/3] cfi x16_as_x8 implementation.
Hello all: This start a patchset series for implementing x16_as_x8 cfi compliant feature. · 01-x16_as_x8-consolidate_addresses.patch · 02-x16_as_x8-flash_address.patch · 03-x16_as_x8-multibyte_read.patch I have taken a view to the CFI specification [0] and it looks that the approach should also work for intel chips, while I had only tested it with spansion flash. FYI, I'm using this patchset all the time while working with flash on the boards I'm testing. I finally merged the command_address functionality into flash_address function. The rest is the same as I sent. I hope this patchset is considered for version 0.2.0. But a little testing should confirm this. [0] http://www.jedec.org/download/search/jesd68-01.pdf -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [1/3] cfi x16_as_x8 implementation.
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI specification [0] and it looks that the
approach should also work for intel chips, while I had only tested it with
spansion flash.
FYI, I'm using this patchset all the time while working with flash on the
boards I'm testing.
I finally merged the command_address functionality into flash_address
function. The rest is the same as I sent.
I hope this patchset is considered for version 0.2.0. But a little
testing should confirm this.
[0] http://www.jedec.org/download/search/jesd68-01.pdf
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -2129,11 +2129,11 @@
if (bank-chip_width == 1)
{
u8 manufacturer, device_id;
- if((retval = target_read_u8(target, bank-base + 0x0, manufacturer)) != ERROR_OK)
+ if((retval = target_read_u8(target, flash_address(bank, 0, 0x00), manufacturer)) != ERROR_OK)
{
return retval;
}
- if((retval = target_read_u8(target, bank-base + 0x1, device_id)) != ERROR_OK)
+ if((retval = target_read_u8(target, flash_address(bank, 0, 0x01), device_id)) != ERROR_OK)
{
return retval;
}
@@ -2142,11 +2142,11 @@
}
else if (bank-chip_width == 2)
{
- if((retval = target_read_u16(target, bank-base + 0x0, cfi_info-manufacturer)) != ERROR_OK)
+ if((retval = target_read_u16(target, flash_address(bank, 0, 0x00), cfi_info-manufacturer)) != ERROR_OK)
{
return retval;
}
- if((retval = target_read_u16(target, bank-base + 0x2, cfi_info-device_id)) != ERROR_OK)
+ if((retval = target_read_u16(target, flash_address(bank, 0, 0x02), cfi_info-device_id)) != ERROR_OK)
{
return retval;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [2/3] cfi x16_as_x8 implementation.
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI specification [0] and it looks that the
approach should also work for intel chips, while I had only tested it with
spansion flash.
FYI, I'm using this patchset all the time while working with flash on the
boards I'm testing.
I finally merged the command_address functionality into flash_address
function. The rest is the same as I sent.
I hope this patchset is considered for version 0.2.0. But a little
testing should confirm this.
[0] http://www.jedec.org/download/search/jesd68-01.pdf
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -112,9 +112,11 @@
/* inline u32 flash_address(flash_bank_t *bank, int sector, u32 offset) */
static __inline__ u32 flash_address(flash_bank_t *bank, int sector, u32 offset)
{
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
+
/* while the sector list isn't built, only accesses to sector 0 work */
if (sector == 0)
- return bank-base + offset * bank-bus_width;
+ return bank-base + (offset * bank-bus_width cfi_info-x16_as_x8 );
else
{
if (!bank-sectors)
@@ -122,7 +124,7 @@
LOG_ERROR(BUG: sector list not yet built);
exit(-1);
}
- return bank-base + bank-sectors[sector].offset + offset * bank-bus_width;
+ return bank-base + bank-sectors[sector].offset + (offset * bank-bus_width cfi_info-x16_as_x8 );
}
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [3/3] cfi x16_as_x8 implementation.
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI specification [0] and it looks that the
approach should also work for intel chips, while I had only tested it with
spansion flash.
FYI, I'm using this patchset all the time while working with flash on the
boards I'm testing.
I finally merged the command_address functionality into flash_address
function. The rest is the same as I sent.
I hope this patchset is considered for version 0.2.0. But a little
testing should confirm this.
[0] http://www.jedec.org/download/search/jesd68-01.pdf
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -204,9 +204,18 @@
static u16 cfi_query_u16(flash_bank_t *bank, int sector, u32 offset)
{
target_t *target = bank-target;
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
u8 data[CFI_MAX_BUS_WIDTH * 2];
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 2, data);
+ if(cfi_info-x16_as_x8)
+ {
+ u8 i;
+ for(i=0;i2;i++)
+ target-type-read_memory(target, flash_address(bank, sector, offset+i), bank-bus_width, 1,
+data[i*bank-bus_width] );
+ }
+ else
+ target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 2, data);
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0] | data[bank-bus_width] 8;
@@ -217,9 +226,18 @@
static u32 cfi_query_u32(flash_bank_t *bank, int sector, u32 offset)
{
target_t *target = bank-target;
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
u8 data[CFI_MAX_BUS_WIDTH * 4];
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 4, data);
+ if(cfi_info-x16_as_x8)
+ {
+ u8 i;
+ for(i=0;i4;i++)
+ target-type-read_memory(target, flash_address(bank, sector, offset+i), bank-bus_width, 1,
+data[i*bank-bus_width] );
+ }
+ else
+ target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 4, data);
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0] | data[bank-bus_width] 8 | data[bank-bus_width * 2] 16 | data[bank-bus_width * 3] 24;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: relocate configuration scripts?
On Fri, 2009-05-22 at 06:35 -0400, Duane Ellis wrote: zach Also, because they are not really TCL scripts. zach They are Jim TCL scripts, . so -- zach if anything -- they should be renamed '.jim' -1 From me. That suggestion was mostly in jest. The main config scripts (interface, board, chip) should remain CFG. they are nothing more then: openocd THING configuration scripts So, it sounds like it might be sensible to use .cfg for these... The *others* - are all helpers - and are TCL scripts, they generally do not configure something. ... and '.tcl' for these. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: relocate configuration scripts?
On Friday 22 May 2009, Duane Ellis wrote: The *others* - are all helpers - and are TCL scripts, they generally do not configure something. Actually, .jim sounds better ... when I consult a TCL manual, I keep seeing things that I need that are not found in TCL. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Balloon board config and some queries
+++ Zach Welch [2009-05-21 15:12 -0700]: On Thu, 2009-05-21 at 21:50 +0100, Wookey wrote: +++ Wookey [2009-05-19 12:29 +0100]: As described on I like the idea for a base.cfg file, as it allows users to tweak the defaults of their installed OpenOCD. In this light, I can see us pushing default settings like this out of the C code and into TCL. More generally, I like the idea of building logical layers of TCL files, which seems to be your principle thrust here. It was. And no-one has said anything about the important issue I wanted to get some feedback on: how best to split up config files. Perhaps I should just send in a patch and see what people have to say about it? I think an opportunity exists for an architect to bring more order to the TCL files. What little looking I did suggested this was indeed true. Currently it's a mess, and a mess in a multitude of styles. The lack of response to your query indicates to me that no one can whip out a quick description for you, so you may have given this topic more recent and considered thought than others. That's quite worrying :-) (given that I've considered exactly 1.5 boards and 4 dongles, and been using openOCD for a whole 3 weeks) A patch might be nice, but it might also be too concrete. I would enjoy reading a description of a process that developers could use to structure their own configuration files. Of course, it would be better to have both, so we can see both your intentions and actualizations. But best of all, you might even add said documentation as doc/manual/apropos.txt. I figure that writing this up should not take much effort, if you already have a plan in mind for making a patch. Hmm, I did wonder if asking questions like this might get me another job. Like everyone tuits are in very short supply. My biggest problem is that I don't feel I have any sort of good overview about other use cases and considerations. Novices re-arranging things might not be ideal. Things like: 1) Is there any agreement that the reset info doesn't really belong in the board file because it depends on the dongle and wiring too, or is that an unusual case? 2) How much room is there for standardising things like reset timeouts and speed settings to suitable defaults? (there is no way to tell from a given file wether the value in there is actually tested/looked-up/important or if it's a random number copied from some other file and actually means sensible default that's just a couple that spring to mind. Looking would no doubt sugest more. But I guess even some basic tidying and consistentifying would be a step in the right direction. I suggest the doxygen manual rather than the user guide, because it seems to be the intent for OpenOCD to provide complete configurations that can simply be used without tinkering. Thus, their architecture and development rules seems belong in the developer manual, and I think this would be a great step forward for us. Never touched doxygen. Is it easy? latex on the other hand I can just about manage. If nothing else, I hope this suggestion might spur others to consider preempting this documentary effort with the architectural plans that led us to the current status quo. If not, you will have a clean slate. Thanx for constructive comment. I'll try marking 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] Request of feature freeze
On May 21, 2009, at 11:38 PM, Øyvind Harboe wrote: You didn't talk about when you cut the branch. I don't think we want to slow down development in svn head for much more than a week or two? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com Cutting the branch should happen about 2 weeks before the release. That way any changes that are brought into the release can typically be trivially merged from trunk. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Request of feature freeze
On May 22, 2009, at 12:04 AM, David Brownell wrote: On Thursday 21 May 2009, Øyvind Harboe wrote: You didn't talk about when you cut the branch. I don't think we want to slow down development in svn head for much more than a week or two? Alternatively, isn't the branch where all non-essential stuff should be parked until head is stabilized and cuts the release? With everyone focussing energy on the release, instead of any non-essential stuff? I'm not fond of making branches to serve as the trunk after the release. That just makes a lot of work for the release maintainer to straighten out the tree later. Now, I'm all for having large features developed on branches. (Or what lots of folk do: private quilt series, updated as needed, until head opens to non-bugfix patches.) I encourage developers to use tools like git-svn or quilt to build and maintain patchsets until they can be integrated into the trunk. Agreed that key when parts were missing. Pending a working testing/QA/bug tracking proposal ... should there at least be a working schedule the next release? Maybe like: 25 May (Monday) -- last features go in ... four weeks of stability/testing/fixing/polish ... with weekly milestone labels, RC1, RC2, etc 22 June (Monday) -- target for release That's just an idea. Maybe three weeks of focussed work is a better target; only take another if that doesn't suffice. - Dave A while back, we had kicked around a tentative date of 7/1. I'm not tied to it by any means, but it does seem to provide sufficient time to stabilize. As for doing RCs, I like to start that in the last 2 week window when the accepted patches are few and the branch has been cut. That way the RCs are tagged from the branch and things are already pretty stable. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Request of feature freeze
On May 22, 2009, at 12:46 AM, David Brownell wrote: For risk, I use the following criteria: None - Every change has risk. This is never used. Low - The changes either affect a small portion of the code base, are very small but repetitious throughout the code base, or are entirely mechanical in nature (running the code through a script) Medium - The changes affect more than one component in the code base, are medium-sized but repetitious, or change the semantics or output of an infrequently used command High - The changes affect 3 or more components in the code base, affect a core subsystem, are large but repetitious, change the semantics or output of any frequently used command, or may cause any sort of overall instability (crash, hang, etc) Low/medium/high is fair enough, though it's often not easy to quantify. Very true. I encourage people to evaluate the risk and reward of their patches and include their assessment with the patch. It's even better if they include details on what the risks and rewards are. Quantifying these isn't an exact science, so the more data the better. Having a template to fill out when submitting a patch can also be useful for this. It at least prompts the patch author to think about these items. Of course, that assumes that they know such a template exists and they are willing to fill it out. For reward, I use the following: None - No actual impact to a typical user. These are things like changes to maintainer scripts, developer docs, etc. Low - Resolved issue affects a small portion of users, has only minor impact on a medium to large size user base (fixing typos, changing error message, etc), or provides minor improvement to ancillary installed items (documentation, helper scripts, contrib items) Medium - Resolved issue affects a medium-sized portion of the users or provides major improvement to ancillary installed items (docs, scripts, contrib items) High - Resolved issue affects a large portion of users or solves an overall instability issue (crash, hang, etc) Likewise, often hard to quantify. Talking about a typical user always raises my suspicions; there are all sizes and shapes. Might be worth thinking about a few different categories for now though. Maybe GDB user that wants to debug embedded no-MMU microcontroller code; Bootloader developer who's basically focussed on getting U-Boot into flash or de-bricking, working with new boards (or updating older ones); and so on. Unblocking some types of users can broaden the user community. Some of those users, in short, are potential. And one of the goals of new releases is to grow that user community. ;) See above. In fact, you could remove the word typical from the description for None and not change the intent. Certainly there are different classes of users and changes will impact them differently. In terms of assessing patches for release integration, we are interested in the impact to the project as a whole. If a change only affects one user class, that's important to note regardless of which class it is. After that, the decision process moves along a sliding scale based on time left until release: This implies some things about release schedule and process... Yes, it does. At a certain point, the patches accepted are affected by the release schedule and process and vice versa. 2 weeks before release - Must be medium or high reward with low risk. Must be tested on multiple interfaces and targets if appropriate. 4 weeks before release - Must be medium or high reward with low or medium risk. Must be tested on at least one interface and multiple targets if appropriate. I think we're probably now closer to 4 weeks than 2. Another dimension being: developers during that part of the cycle need to focus on finding and fixing bugs. Agreed. 8 weeks before release - Any reward with low or medium risk. Testing highly preferred but not explicitly required. Over 8 weeks before release - Any well written patch will generally be accepted. Best if things *always* require testing, IMO, even if only from the original developer. :) Also agreed, but I tend to be more willing to accept code inspection early on. So, the introduction of a new NAND driver would probably fall into the Low risk and Low/Medium reward area. Right ... although, to affected users it would be high reward, while it would remain low risk to everyone. True, but the reward needs to be considered in the context of the entire project, not just the affected users. If you limit the scope to only the affected users, you find that most bugs are high reward. Given our hope to release by 7/1, we have a little over 5 weeks. I don't know where 7/1 came from. I had thought sooner was in the air... 7/1 has been kicked around a bit, but not formally agreed upon. I think it sets a reasonable deadline. I'd prefer it have some testing, but
Re: [Openocd-development] [PATCH] More printf fixes
Committed revision 1882. On May 21, 2009, at 11:43 AM, Rick Altherr wrote: On May 21, 2009, at 11:24 AM, David Brownell wrote: On Thursday 21 May 2009, Rick Altherr wrote: I believe the fix for off_t should be portable, but I'm less certain of the struct timeval fix. The timeval fix looks like it reverses a fix I needed: pld.c: In function ‘handle_pld_load_command’: pld.c:194: error: format ‘%i’ expects type ‘int’, but argument 6 has type ‘__suseconds_t’ Maybe you can just cast it to int and use %d. Yeah, given that it is an integer and of variable size, casting to intmax_t is probably appropriate. Please try the attached patch. printf-fixes.patch -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] nand cleanups
Committed revision 1883. On May 22, 2009, at 1:31 AM, David Brownell wrote: Remove un-implemented and dubious nand copy command. Doing this efficiently would mean doing the copying on the target CPU, instead of back and forth through JTAG. If anyone ever needs this functionality, that's what they should implement. Also, update on-line help for nand dump to display its two optional flags; and for nand write to display a recently added flag. --- src/flash/nand.c | 31 +++ 1 file changed, 3 insertions(+), 28 deletions(-) nand-copy.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SVF patch according to Johann's test
Are we waiting on testing results? Rick On May 21, 2009, at 7:57 AM, SimonQian wrote: Johann, I found the svf_check_tdo has been modified in the SVN HEAD. Can you check it on your target? Attachment is my patch to use buf_cmp_mask when compare data, please check it too. A problem in svf.c and xsvf.c: xsvf.c: In function `handle_xsvf_command': xsvf.c:1025: warning: long int format, different type arg (arg 4) svf.c: In function `handle_svf_command': svf.c:333: warning: int format, different type arg (arg 3) They should be the same problem. 2009-05-21 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： SimonQian 发送时间： 2009-05-21 20:57:02 收件人： Rick Altherr 抄送： 'openocd-development' 主题： Re: [Openocd-development] SVF patch according to Johann's test I'll check it out this week. 2009-05-21 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： Rick Altherr 发送时间： 2009-05-21 13:32:22 收件人： SimonQian 抄送： 'openocd-development' 主题： Re: [Openocd-development] SVF patch according to Johann's test This doesn't seem to be applied to trunk, nor does it apply cleanly. Is there an updated version available? Rick On Apr 3, 2009, at 6:11 AM, SimonQian wrote: So the patch in this mail is enough. It fix only the svf_check_tdo function. 2009-04-03 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： Spencer Oliver 发送时间： 2009-04-03 20:41:39 收件人： 'SimonQian'; 'openocd-development' 抄送： 主题： Re: [Openocd-development] SVF patch according to Johann's test Fix: 1. As Johann suggested, max line width is 80 characters, according to GNU coding standard. This is not a requirement of openocd Theses are the openocd coding rules, they were part of the old readme but need adding to the texi: This is from the old readme - needs adding to the docs again 5. Coding Style The following rules try to describe formatting and naming conventions that should be followed to make the whole OpenOCD code look more consistent. The ultimate goal of coding style should be readability, and these rules may be ignored for a particular (small) piece of code if that makes it more readable. Formatting rules: - remove any trailing white space - use TAB characters for indentation, not spaces - displayed TAB width is 4 characters - make sure NOT to use DOS '\r\n' line feeds - do not add more than 2 empty lines to source files - do not add trailing empty lines to source files - do not use C++ style comments (//) - lines may be reasonably wide - there's no anachronistic 80 characters limit Naming rules: - identifiers use lower-case letters only - identifiers consisting of multiple words use underline characters between consecutive words - macros use upper-case letters only - structure names shall be appended with '_s' - typedefs shall be appended with '_t' Function calls: - function calls have no space between the functions name and the parameter list: my_func(param1, param2, ...) Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development svf.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned svf.diff -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SVF patch according to Johann's test
I think we can commit this patch, it only changes svf_check_tdo function, which is used to check tdo output with desired values. The patch will call buf_cmp_mask function to do the comparation instead of writing the loop code. The patch also fix a bug when data length is 32 bit(equal to sizeof(int)). Attached patch remove other modifications except for svf_check_tdo function. 2009-05-23 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： Rick Altherr 发送时间： 2009-05-23 01:44:54 收件人： SimonQian 抄送： 'openocd-development' 主题： Re: [Openocd-development] SVF patch according to Johann's test Are we waiting on testing results? Rick On May 21, 2009, at 7:57 AM, SimonQian wrote: Johann, I found the svf_check_tdo has been modified in the SVN HEAD. Can you check it on your target? Attachment is my patch to use buf_cmp_mask when compare data, please check it too. A problem in svf.c and xsvf.c: xsvf.c: In function `handle_xsvf_command': xsvf.c:1025: warning: long int format, different type arg (arg 4) svf.c: In function `handle_svf_command': svf.c:333: warning: int format, different type arg (arg 3) They should be the same problem. 2009-05-21 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： SimonQian 发送时间： 2009-05-21 20:57:02 收件人： Rick Altherr 抄送： 'openocd-development' 主题： Re: [Openocd-development] SVF patch according to Johann's test I'll check it out this week. 2009-05-21 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： Rick Altherr 发送时间： 2009-05-21 13:32:22 收件人： SimonQian 抄送： 'openocd-development' 主题： Re: [Openocd-development] SVF patch according to Johann's test This doesn't seem to be applied to trunk, nor does it apply cleanly. Is there an updated version available? Rick On Apr 3, 2009, at 6:11 AM, SimonQian wrote: So the patch in this mail is enough. It fix only the svf_check_tdo function. 2009-04-03 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： Spencer Oliver 发送时间： 2009-04-03 20:41:39 收件人： 'SimonQian'; 'openocd-development' 抄送： 主题： Re: [Openocd-development] SVF patch according to Johann's test Fix: 1. As Johann suggested, max line width is 80 characters, according to GNU coding standard. This is not a requirement of openocd Theses are the openocd coding rules, they were part of the old readme but need adding to the texi: This is from the old readme - needs adding to the docs again 5. Coding Style The following rules try to describe formatting and naming conventions that should be followed to make the whole OpenOCD code look more consistent. The ultimate goal of coding style should be readability, and these rules may be ignored for a particular (small) piece of code if that makes it more readable. Formatting rules: - remove any trailing white space - use TAB characters for indentation, not spaces - displayed TAB width is 4 characters - make sure NOT to use DOS '\r\n' line feeds - do not add more than 2 empty lines to source files - do not add trailing empty lines to source files - do not use C++ style comments (//) - lines may be reasonably wide - there's no anachronistic 80 characters limit Naming rules: - identifiers use lower-case letters only - identifiers consisting of multiple words use underline characters between consecutive words - macros use upper-case letters only - structure names shall be appended with '_s' - typedefs shall be appended with '_t' Function calls: - function calls have no space between the functions name and the parameter list: my_func(param1, param2, ...) Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development svf.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned svf.diff -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned svf.diff Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND documentation? My current notes...
On Thursday 21 May 2009, Nicolas Pitre wrote: On Thu, 21 May 2009, David Brownell wrote: I also noticed that two commands (erase, check_bad) are unusual in that they require *block* numbers as parameters, rather than the offsets used everywhere else in OpenOCD (and in U-Boot, and the Linux-MTD utilities). Comments on changing that to become more consistent, and holding off on documenting/committing-to the current interface until this issue is resolved? Uniformity is good. If you do this change, please don't forget to update existing scripts using those commands too. The only existing in-tree script using this is for SheevaPlug, which has nand erase 0 0 4. That should become nand erase 0 0 $X (*) where X is [expr $nand_block_size * 4] ... would you know the value of $nand_block_size? I'd guess that having a 4Gbit NAND means it's 2KB/page, 128KB/block. - Dave (*) Or nand erase $_TARGETNAME 0 $X, to avoid numeric target designators, though it won't much matter on this board for now. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND documentation? My current notes...
On Fri, 22 May 2009, David Brownell wrote: On Thursday 21 May 2009, Nicolas Pitre wrote: On Thu, 21 May 2009, David Brownell wrote: I also noticed that two commands (erase, check_bad) are unusual in that they require *block* numbers as parameters, rather than the offsets used everywhere else in OpenOCD (and in U-Boot, and the Linux-MTD utilities). Comments on changing that to become more consistent, and holding off on documenting/committing-to the current interface until this issue is resolved? Uniformity is good. If you do this change, please don't forget to update existing scripts using those commands too. The only existing in-tree script using this is for SheevaPlug, which has nand erase 0 0 4. That should become nand erase 0 0 $X (*) where X is [expr $nand_block_size * 4] ... would you know the value of $nand_block_size? I'd guess that having a 4Gbit NAND means it's 2KB/page, 128KB/block. Exact. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [0/3] cfi x16_as_x8 implementation.
Raúl Sánchez Siles wrote: Hello all: This start a patchset series for implementing x16_as_x8 cfi compliant feature. · 01-x16_as_x8-consolidate_addresses.patch · 02-x16_as_x8-flash_address.patch · 03-x16_as_x8-multibyte_read.patch I have taken a view to the CFI specification [0] and it looks that the approach should also work for intel chips, while I had only tested it with spansion flash. That looks good to me - I would have expected a lot more changes. Some style comments: - I do not really like left shifts with what is effectively a bool variable as shift amount (bank-bus_width cfi_info-x16_as_x8). The logic is correct, but it looks strange. - In cfi.c, I think we should always use a loop of single-byte reads instead of using separate code for the x16_as_x8 and the normal case. Using the single-byte reads should be safe on wider bus/flash widths, and would make one code path that is better tested. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svn 1881 with jlink and STM32
I am just updated to svn 1881 to use with my STM32 and jlink(yellow
v6.0). I had been using 1183, which worked every time, but was
unbearably slow. Revision 1881 is lightning fast compared with the
old revision. I am however seeing a few issues.
It takes 5 or six tries to get my program to download into flash. I
either get a segmentation fault at startup or an error while writing
the code to flash. I have attached examples of both problems below
along with my configuration file. I am away this weekend but would be
able to get a debug build running to try some things out next week.
Great work on the speed up!
$ sudo /usr/local/gnu-arm/bin/openocd -f
../GNUTools/openOCD/newLPM.cfg -c init -c sleep 200 -f
flashAll.script -c reset run -c shutdown
Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
500 kHz
Error: J-Link command EMU_CMD_VERSION failed (-110)
Info : J-Link ARM V6 compiled Aug 28 2007 19:22:02
Info : JLink caps 0x77fbf
Info : JLink max mem block 9992
Info : Vref = 3.306 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3041). Workaround: increase set remotetimeout in
GDB
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer:
0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (Manufacturer:
0x020, Part: 0x6414, Version: 0x0)
Info : JTAG Tap/device matched
Warn : no telnet port specified, using default port
Warn : no gdb port specified, using default port
Warn : no tcl port specified, using default port
Info : device id = 0x10016414
Info : flash size = 256kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
wrote 6844 byte from file ../BootLoader/source/bl.elf in 0.670785s
(9.963839 kb/s)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (1025). Workaround: increase set remotetimeout in
GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (9037). Workaround: increase set remotetimeout in
GDB
Error: timed out while waiting for target halted
Error: error executing stm32x flash write algorithm
Error: flash writing failed with error code: 0xfc7a
Error: error writing to flash at address 0x0800 at offset 0x2000 (-902)
$ sudo /usr/local/gnu-arm/bin/openocd -f
../GNUTools/openOCD/newLPM.cfg -c init -c sleep 200 -f
flashAll.script -c reset run -c shutdown
Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
500 kHz
Error: J-Link command EMU_CMD_VERSION failed (-110)
Error: J-Link command EMU_CMD_VERSION failed (-110)
Segmentation fault
$ cat ../GNUTools/openOCD/newLPM.cfg
# script for stm32
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME stm32
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
interface jlink
# jtag speed
jtag_khz 500
jtag_nsrst_delay 100
jtag_ntrst_delay 100
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst
#jtag scan chain
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# See STM Document RM0008
# Section 26.6.3
set _CPUTAPID 0x3ba00477
}
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $_CPUTAPID
if { [info exists BSTAPID ] } {
set _BSTAPID $BSTAPID
} else {
# See STM Document RM0008
# Section 26.6.2
# Low density devices, Rev A
set _BSTAPID1 0x06412041
# Medium density devices, Rev A
set _BSTAPID2 0x06410041
# Medium density devices, Rev B and Rev Z
set _BSTAPID3 0x16410041
# High density devices, Rev A
set _BSTAPID4 0x06414041
}
jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1
-expected-id $_BSTAPID1 -expected-id $_BSTAPID2 -expected-id
$_BSTAPID3 -expected-id $_BSTAPID4
set _TARGETNAME [format %s.cpu $_CHIPNAME]
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position
$_TARGETNAME
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x2000
-work-area-size 49152 -work-area-backup 0
flash bank stm32x 0 0 0 0 0
gdb_memory_map enable
gdb_flash_program enable
# For more information about the configuration files, take a look at:
# openocd.texi
$
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Sat, 2009-05-23 at 00:18 +0200, Magnus Lundin wrote: Zach Welch wrote: On Tue, 2009-05-19 at 16:53 +0200, Magnus Lundin wrote: Hi Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Error: J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (-110) Open OCD seems to get reasonable ansvers from first two JLink commands. The /* query hardware maximum memory block */ should not be run for this version, I had removed it in my patch. Next patch will use results from JLink caps to select what info to query. I am waiting for more info from Segger about version diffrences and endpoints. How are we doing with this patch? It looks like we have made some good progress this week, so I don't want the effort to stall. What are the thoughts about committing your latest version? Even if more changes may be pending, it seems that your work has improved things for folks with some devices, so I think we have made constructive progress from where we were before now. If nothing else, we should get some more testing feedback. ;) Cheers, Zach There is a set of new patches that has been tested by Michael Fischer, as far as i know there were no problems. There are still things that should be fixed in the resethandling in jtag_add_reset and minimizing the differences between ft2232 and jlink behaviour. But still would suggest that the following patcches are commited. They are not untested. I will apply them here and see if they magically cure my own woes. Regardless, I think these changes should be committed in some for, though I can see various ways that I would like to clean your code. Would you mind my taking a pass over them before I commit them? Incidentally, do you think this might also solve the problem that was just reported by Dylan Reid? I have cc'd him in the hope that he will try your patches and report the latest results. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Zach Welch wrote: On Sat, 2009-05-23 at 00:18 +0200, Magnus Lundin wrote: Zach Welch wrote: On Tue, 2009-05-19 at 16:53 +0200, Magnus Lundin wrote: Hi Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Error: J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (-110) Open OCD seems to get reasonable ansvers from first two JLink commands. The /* query hardware maximum memory block */ should not be run for this version, I had removed it in my patch. Next patch will use results from JLink caps to select what info to query. I am waiting for more info from Segger about version diffrences and endpoints. How are we doing with this patch? It looks like we have made some good progress this week, so I don't want the effort to stall. What are the thoughts about committing your latest version? Even if more changes may be pending, it seems that your work has improved things for folks with some devices, so I think we have made constructive progress from where we were before now. If nothing else, we should get some more testing feedback. ;) Cheers, Zach There is a set of new patches that has been tested by Michael Fischer, as far as i know there were no problems. There are still things that should be fixed in the resethandling in jtag_add_reset and minimizing the differences between ft2232 and jlink behaviour. But still would suggest that the following patcches are commited. They are not untested. I will apply them here and see if they magically cure my own woes. Regardless, I think these changes should be committed in some for, though I can see various ways that I would like to clean your code. Would you mind my taking a pass over them before I commit them? Sure, I am out of style discussions on this list. Incidentally, do you think this might also solve the problem that was just reported by Dylan Reid? I have cc'd him in the hope that he will try your patches and report the latest results. It should help, but from the info given it is hard to tell what actually broke. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: relocate configuration scripts?
David Brownell wrote: On Friday 22 May 2009, Duane Ellis wrote: The *others* - are all helpers - and are TCL scripts, they generally do not configure something. Actually, .jim sounds better ... when I consult a TCL manual, I keep seeing things that I need that are not found in TCL. Like what... are they perhaps these are easy to add? One thing that is missing is simplistic file IO - open/close/read/write. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Doxygen strip code comments = NO
I prefer the STRIP_CODE_COMMENTS = NO Reason: Don't hide things. Make it all visible. $ svn diff Doxyfile Index: Doxyfile === --- Doxyfile(revision 1858) +++ Doxyfile(working copy) @@ -697,7 +697,7 @@ # doxygen to hide any special comment blocks from generated source code # fragments. Normal C and C++ comments will always remain visible. -STRIP_CODE_COMMENTS= YES +STRIP_CODE_COMMENTS= NO # If the REFERENCED_BY_RELATION tag is set to YES # then for each documented function all documented ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Doxygen strip code comments = NO
On Fri, 2009-05-22 at 20:05 -0400, Duane Ellis wrote: I prefer the STRIP_CODE_COMMENTS = NO Reason: Don't hide things. Make it all visible. Committed r1887. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
Try this again to the whole list.
Here is the trace. I'm taking a quick look at it right now. I am
guessing that having jlink_jtag_handle = 0 is the problem, just trying
to figure out how that happened.
Dylan
(gdb) run -f ../GNUTools/openOCD/newLPM.cfg -c init -c sleep 200 -f
flashAll.script -c reset run -c shutdown
Starting program: /scratch/gnu-arm/bin/openocd -f
../GNUTools/openOCD/newLPM.cfg -c init -c sleep 200 -f
flashAll.script -c reset run -c shutdown
Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
500 kHz
Error: J-Link command EMU_CMD_VERSION failed (-110)
Error: J-Link command EMU_CMD_VERSION failed (-110)
Program received signal SIGSEGV, Segmentation fault.
0x00a84e85 in jlink_usb_write (jlink_jtag=0x0, out_length=1) at jlink.c:918
/scratch/openocd/src/jtag/jlink.c:918:23443:beg:0xa84e85
(gdb) bt
#0 0x00a84e85 in jlink_usb_write (jlink_jtag=0x0, out_length=1) at jlink.c:918
#1 0x00a84f2f in jlink_simple_command (command=1 '\001') at jlink.c:509
#2 0x00a85dbe in jlink_get_version_info () at jlink.c:549
#3 0x00a860f5 in jlink_init () at jlink.c:324
#4 0x00a7f188 in jtag_interface_init (cmd_ctx=0x8830008) at jtag.c:2370
#5 0x00a78cb3 in handle_init_command (cmd_ctx=0x8830008,
cmd=0x883e228 init, args=0x8843344, argc=0) at openocd.c:133
#6 0x00b1e89a in run_command (context=0x8830008, c=0x883e548,
words=0x8843340, num_words=1) at command.c:399
#7 0x00b1ebe2 in script_command (interp=0x8830020, argc=1, argv=0xbfc3f8e0)
at command.c:126
#8 0x00b130ee in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x88430a0)
at jim.c:8708
#9 0x00b13d51 in Jim_EvalCoreCommand (interp=0x8830020, argc=3,
argv=0xbfc3f9a0) at jim.c:10846
#10 0x00b130ee in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x8843268)
at jim.c:8708
#11 0x00b13962 in Jim_CatchCoreCommand (interp=0x8830020, argc=2,
argv=0xbfc3fa60) at jim.c:11413
#12 0x00b130ee in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x883fc68)
at jim.c:8708
#13 0x00b17e9f in Jim_EvalExpression (interp=0x8830020, exprObjPtr=0x8844298,
exprResultPtrPtr=0xbfc3fbc4) at jim.c:6927
---Type return to continue, or q return to quit---
#14 0x00b18c13 in Jim_GetBoolFromExpr (interp=0x8830020, exprObjPtr=0x8844298,
boolPtr=0xbfc3fc08) at jim.c:7210
#15 0x00b18d4b in Jim_IfCoreCommand (interp=0x8830020, argc=5, argv=0xbfc3fc70)
at jim.c:10297
#16 0x00b130ee in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x883e9f0)
at jim.c:8708
#17 0x00b15294 in JimCallProcedure (interp=0x8830020, cmd=0x883eb98, argc=0,
argv=0xbfc3fd70) at jim.c:8857
#18 0x00b134a7 in Jim_EvalObj (interp=0x8830020, scriptObjPtr=0x883e970)
at jim.c:8714
#19 0x00b14f0f in Jim_Eval_Named (interp=0x8830020, script=0x883e5b0 init,
filename=0xb41eeb command.c, lineno=453) at jim.c:8901
#20 0x00b1e7c6 in command_run_line (context=0x8830008, line=0x883e5b0 init)
at command.c:453
#21 0x00b1d029 in parse_config_file (cmd_ctx=0x8830008) at configuration.c:118
#22 0x00a78bc8 in openocd_main (argc=13, argv=0xbfc40034) at openocd.c:268
#23 0x080484b2 in main (argc=Cannot access memory at address 0x1
) at main.c:39
(gdb) list
913 }
914
915 static inline int usb_bulk_write_ex(usb_dev_handle *dev, int ep,
916 char *bytes, int size, int timeout)
917 {
918 return usb_bulk_with_retries(wrap_usb_bulk_write,
919 dev, ep, bytes, size, timeout);
920 }
921
922 static inline int usb_bulk_read_ex(usb_dev_handle *dev, int ep,
(gdb) p wrap_usb_bulk_write
$1 = {int (usb_dev_handle *, int, char *, int,
int)} 0xa851f0 wrap_usb_bulk_write
(gdb) p dev
No symbol dev in current context.
(gdb) p wrap_usb_bulk_write
$2 = (int (*)(usb_dev_handle *, int, char *, int,
int)) 0xa851f0 wrap_usb_bulk_write
(gdb) up
#1 0x00a84f2f in jlink_simple_command (command=1 '\001') at jlink.c:509
/scratch/openocd/src/jtag/jlink.c:509:13195:beg:0xa84f2f
(gdb) list
504 int result;
505
506 DEBUG_JTAG_IO(0x%02x, command);
507
508 usb_out_buffer[0] = command;
509 result = jlink_usb_write(jlink_jtag_handle, 1);
510
511 if (result != 1)
512 {
513 LOG_ERROR(J-Link command 0x%02x failed (%d),
command, result);
(gdb) p jlink_jtag_handle
$3 = (jlink_jtag_t *) 0x0
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
Something strikes me as pretty broken here. Maybe I am seeing ghosts.
I put in a few prints to see what was going on, then got confused and
ran from the debugger. This is what I found:
static int jlink_get_version_info(void)
{
int result;
int len;
u32 jlink_caps, jlink_max_size;
/* query hardware version */
jlink_simple_command(EMU_CMD_VERSION);
result = jlink_usb_read(jlink_jtag_handle, 2);
if (2 != result)
{
///* Sometimes this fails, that doesn't seem to matter
LOG_ERROR(J-Link command EMU_CMD_VERSION failed
(%d)\n, result);
return ERROR_JTAG_DEVICE_ERROR;
}
///* most of the time it works and we get to here
///* Problem is that what is read is J- the first two bytes of
the jlink identifier string
len = buf_get_u32(usb_in_buffer, 0, 16);
///* len now holds 11594, which is what buf_get_u32 returns when
it is fed J-
result = jlink_usb_read(jlink_jtag_handle, len);
///* jlink_usb_read doesn't check the length of the buffer before reading
///* so it wipes out a bunch of variables including jlink_jtag_handle
if (result != len)
{
LOG_ERROR(J-Link command EMU_CMD_VERSION read failed
(%d)\n, result);
return ERROR_JTAG_DEVICE_ERROR;
}
The crazy thing is that sometimes this works. Often enough to be
usable actually. I added a check to jlink_usb_read and it makes it
fail every time. I attached the patch as I think it is the right
thing to do anyways. If you increase JLINK_IN_BUFFER_SIZE to
something big enough, it will keep it functional.
I don't have any experience with low level jtag interfacing, what is
this code trying to do? Should something other than J- be returned
after EMU_CMD_VERSION?
Wish I had more time to debug this tonight, but if I don't get home
for memorial day weekend the GF is not going to be too happy :-)
Dylan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Sat, May 23, 2009 at 6:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote: There is a set of new patches that has been tested by Michael Fischer, as far as i know there were no problems. There are still things that should be fixed in the resethandling in jtag_add_reset and minimizing the differences between ft2232 and jlink behaviour. But still would suggest that the following patcches are commited. They are not untested. I'd like to test as well for my V3 black J-link. It works well with your previous patch. But the latest trunk does not build under Arch Linux. It is also pointed out by Simon Qian. How should I modify that file? xsvf.c: In function ‘handle_xsvf_command’: xsvf.c:1025: error: format ‘%jd’ expects type ‘intmax_t’, but argument 4 has type ‘long int’ make[3]: *** [xsvf.lo] Error 1 -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Sat, May 23, 2009 at 9:12 AM, Xiaofan Chen xiaof...@gmail.com wrote: I'd like to test as well for my V3 black J-link. It works well with your previous patch. But the latest trunk does not build under Arch Linux. It is also pointed out by Simon Qian. How should I modify that file? xsvf.c: In function ‘handle_xsvf_command’: xsvf.c:1025: error: format ‘%jd’ expects type ‘intmax_t’, but argument 4 has type ‘long int’ make[3]: *** [xsvf.lo] Error 1 Change it to %ld as previous version helps. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Sat, 2009-05-23 at 09:12 +0800, Xiaofan Chen wrote: On Sat, May 23, 2009 at 6:18 AM, Magnus Lundin lun...@mlu.mine.nu wrote: There is a set of new patches that has been tested by Michael Fischer, as far as i know there were no problems. There are still things that should be fixed in the resethandling in jtag_add_reset and minimizing the differences between ft2232 and jlink behaviour. But still would suggest that the following patcches are commited. They are not untested. I'd like to test as well for my V3 black J-link. It works well with your previous patch. But the latest trunk does not build under Arch Linux. It is also pointed out by Simon Qian. How should I modify that file? xsvf.c: In function ‘handle_xsvf_command’: xsvf.c:1025: error: format ‘%jd’ expects type ‘intmax_t’, but argument 4 has type ‘long int’ make[3]: *** [xsvf.lo] Error 1 Broken in r1882, and fixed in r1888. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
2009/5/23 Zach Welch z...@superlucidity.net: I'd like to test as well for my V3 black J-link. It works well with your previous patch. But the latest trunk does not build under Arch Linux. It is also pointed out by Simon Qian. How should I modify that file? xsvf.c: In function ‘handle_xsvf_command’: xsvf.c:1025: error: format ‘%jd’ expects type ‘intmax_t’, but argument 4 has type ‘long int’ make[3]: *** [xsvf.lo] Error 1 Broken in r1882, and fixed in r1888. --Z Thanks for the fast response. Now it is fine. I've applied the three patches (but I do not use ft2232) and my black J-link V3 seems to work fine with Olimex LPC-P2148 board. Tested under Ubuntu 9.04 (I was thinking the Arch GCC compiler may be too harsh so I rebooted to Ubuntu). -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Sat, 2009-05-23 at 09:35 +0800, Xiaofan Chen wrote: 2009/5/23 Zach Welch z...@superlucidity.net: I'd like to test as well for my V3 black J-link. It works well with your previous patch. But the latest trunk does not build under Arch Linux. It is also pointed out by Simon Qian. How should I modify that file? xsvf.c: In function ‘handle_xsvf_command’: xsvf.c:1025: error: format ‘%jd’ expects type ‘intmax_t’, but argument 4 has type ‘long int’ make[3]: *** [xsvf.lo] Error 1 Broken in r1882, and fixed in r1888. --Z Thanks for the fast response. Now it is fine. I've applied the three patches (but I do not use ft2232) and my black J-link V3 seems to work fine with Olimex LPC-P2148 board. Tested under Ubuntu 9.04 (I was thinking the Arch GCC compiler may be too harsh so I rebooted to Ubuntu). Great to hear. I am working on these now and should have them committed within an hour or two. (I have several things distracting me, or it would be much sooner.) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, May 23, 2009 at 5:59 AM, Dylan Reid dgr...@gmail.com wrote: $ sudo /usr/local/gnu-arm/bin/openocd -f ../GNUTools/openOCD/newLPM.cfg -c init -c sleep 200 -f flashAll.script -c reset run -c shutdown Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ 500 kHz Error: J-Link command EMU_CMD_VERSION failed (-110) Info : J-Link ARM V6 compiled Aug 28 2007 19:22:02 Info : JLink caps 0x77fbf Info : JLink max mem block 9992 Info : Vref = 3.306 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3041). Workaround: increase set remotetimeout in GDB I've had similar error message and similar warning message before with the yellow J-Link. Magnus's patch solved that. Could you try his patch? Right now I do not have the yellow J-Link with me (it is at work place). BTW, I've segmentation fault with some versions as well. But the latest trunk seems to be ok. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] nand support
On Fri, 22 May 2009, David Brownell wrote: On Friday 22 May 2009, Sergey Lapin wrote: How hard it is po port that to at91sam9260? Shouldn't be hard to get basic soft-ecc working. Sort of like Orion ... I think the fast-download code there should be pulled out and made available for all ARMs with a DCC. Note that the actual fast download code is not in the orion NAND driver. It is already provided by the target support code. What you see in the orion driver is some code to transfer a page of data from the target's memory to the NAND controller. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, May 23, 2009 at 8:49 AM, Dylan Reid dgr...@gmail.com wrote:
Something strikes me as pretty broken here. Maybe I am seeing ghosts.
I put in a few prints to see what was going on, then got confused and
ran from the debugger. This is what I found:
static int jlink_get_version_info(void)
{
int result;
int len;
u32 jlink_caps, jlink_max_size;
/* query hardware version */
jlink_simple_command(EMU_CMD_VERSION);
result = jlink_usb_read(jlink_jtag_handle, 2);
if (2 != result)
{
///* Sometimes this fails, that doesn't seem to matter
LOG_ERROR(J-Link command EMU_CMD_VERSION failed
(%d)\n, result);
return ERROR_JTAG_DEVICE_ERROR;
}
This is in line with my past testing. It seems to me Magnus' patch solved this.
///* most of the time it works and we get to here
///* Problem is that what is read is J- the first two bytes of
the jlink identifier string
len = buf_get_u32(usb_in_buffer, 0, 16);
///* len now holds 11594, which is what buf_get_u32 returns when
it is fed J-
result = jlink_usb_read(jlink_jtag_handle, len);
///* jlink_usb_read doesn't check the length of the buffer before reading
///* so it wipes out a bunch of variables including jlink_jtag_handle
if (result != len)
{
LOG_ERROR(J-Link command EMU_CMD_VERSION read failed
(%d)\n, result);
return ERROR_JTAG_DEVICE_ERROR;
}
You are right. It should probably check the return result of the read
operation (usb_bulk_read).
The crazy thing is that sometimes this works. Often enough to be
usable actually. I added a check to jlink_usb_read and it makes it
fail every time. I attached the patch as I think it is the right
thing to do anyways. If you increase JLINK_IN_BUFFER_SIZE to
something big enough, it will keep it functional.
Where is the patch?
I don't have any experience with low level jtag interfacing, what is
this code trying to do? Should something other than J- be returned
after EMU_CMD_VERSION?
Wish I had more time to debug this tonight, but if I don't get home
for memorial day weekend the GF is not going to be too happy :-)
I am also thinking that the USB timeout value may be extended a bit longer.
Right now it is 1000ms. Should be ok. But may not be ok for people
using VM or similar.
--
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] nand support
On Friday 22 May 2009, Nicolas Pitre wrote: On Fri, 22 May 2009, David Brownell wrote: On Friday 22 May 2009, Sergey Lapin wrote: How hard it is po port that to at91sam9260? Shouldn't be hard to get basic soft-ecc working. Sort of like Orion ... I think the fast-download code there should be pulled out and made available for all ARMs with a DCC. Note that the actual fast download code is not in the orion NAND driver. It is already provided by the target support code. What you see in the orion driver is some code to transfer a page of data from the target's memory to the NAND controller. Right. I'd call the new reusable bit something like a FIFO write routine ... it's a bit of a hack to transfer to SRAM, then to the FIFO/Controller, since it *could* just as easily have tweaked DCC code to write directly to the FIFO not to SRAM. But it was probably easier to figure it out this way, first time around. N'est-ce pas? :) ... and doing this bulk I/O makes me want to see some fast upload code too. Later, maybe! - dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] more NAND cleanup and doc updates
Update two oddball NAND commands to work with {offset, length}
instead of block numbers, matching the other commands as well
as usage in U-Boot and the Linux-MTD utilities.
Document them accordingly. Update the single in-tree use of
those commands (sheevaplug).
ALSO:
(a) Document the current 2 GByte/chip ceiling for NAND chipsize.
(32 bit offset/length values can't represent 4 GBytes.) Maybe
after the upcoming release, the code can switch to 64-bits.
(b) The nand check_bad_blocks should report bad blocks. They
are not invalid blocks; they're bad ones.
(c) Tweak the nand info command to handle the no arguments
case sanely (show everything, instead of showing garbage) and
not listing the blocksize in hex kbytes (duh).
---
doc/openocd.texi| 37 +++-
src/flash/nand.c| 109 ++
src/target/board/sheevaplug.cfg |2
3 files changed, 109 insertions(+), 39 deletions(-)
Update two oddball NAND commands to work with {offset, length}
instead of block numbers, matching the other commands as well
as usage in U-Boot and the Linux-MTD utilities.
Document them accordingly. Update the single in-tree use of
those commands (sheevaplug).
ALSO:
(a) Document the current 2 GByte/chip ceiling for NAND chipsize.
(32 bit offset/length values can't represent 4 GBytes.) Maybe
after the upcoming release, the code can switch to 64-bits.
(b) The nand check_bad_blocks should report bad blocks. They
are not invalid blocks; they're bad ones.
(c) Tweak the nand info command to handle the no arguments
case sanely (show everything, instead of showing garbage) and
not listing the blocksize in hex kbytes (duh).
---
doc/openocd.texi| 37 +++-
src/flash/nand.c| 109 ++
src/target/board/sheevaplug.cfg |2
3 files changed, 109 insertions(+), 39 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2596,6 +2596,15 @@ boot loader, operating system, or other
de-brick a board.
@end enumerate
+...@b{note:} At the time this text was written, the largest NAND
+flash fully supported by OpenOCD is 2 GiBytes (16 GiBits).
+This is because the variables used to hold offsets and lengths
+are only 32 bits wide.
+(Larger chips may work in some cases, unless an offset or length
+is larger than 0x, the largest 32-bit unsigned integer.)
+Some larger devices will work, since they are actually multi-chip
+modules with two smaller chips and individual chipselect lines.
+
@section NAND Configuration Commands
@cindex NAND configuration
@@ -2682,9 +2691,19 @@ spare areas associated with each data pa
@end itemize
@end deffn
-...@deffn Command {nand erase} num ...
+...@deffn Command {nand erase} num offset length
@cindex NAND erasing
-...@b{note:} Syntax is in flux.
+Erases blocks on the specified NAND device, starting at the
+specified @var{offset} and continuing for @var{length} bytes.
+Both of those values must be exact multiples of the device's
+block size, and the region they specify must fit entirely in the chip.
+The @var{num} parameter is the value shown by @command{nand list}.
+
+...@b{note:} This command will try to erase bad blocks, when told
+to do so, which will probably invalidate the manufacturer's bad
+block marker.
+For the remainder of the current server session, @command{nand info}
+will still report that the block ``is'' bad.
@end deffn
@deffn Command {nand write} num filename offset [option...]
@@ -2748,8 +2767,18 @@ the underlying driver from applying hard
@section Other NAND commands
@cindex NAND other commands
-...@deffn Command {nand check_bad} num ...
-...@b{note:} Syntax is in flux.
+...@deffn Command {nand check_bad_blocks} [offset length]
+Checks for manufacturer bad block markers on the specified NAND
+device. If no parameters are provided, checks the whole
+device; otherwise, starts at the specified @var{offset} and
+continues for @var{length} bytes.
+Both of those values must be exact multiples of the device's
+block size, and the region they specify must fit entirely in the chip.
+The @var{num} parameter is the value shown by @command{nand list}.
+
+...@b{note:} Before using this command you should force raw access
+with @command{nand raw_access enable} to ensure that the underlying
+driver will not try to apply hardware ECC.
@end deffn
@deffn Command {nand info} num
--- a/src/flash/nand.c
+++ b/src/flash/nand.c
@@ -309,12 +309,12 @@ int nand_init(struct command_context_s *
register_command(cmd_ctx, nand_cmd, probe, handle_nand_probe_command, COMMAND_EXEC,
identify NAND flash device num);
register_command(cmd_ctx, nand_cmd, check_bad_blocks, handle_nand_check_bad_blocks_command, COMMAND_EXEC,
- check NAND flash device num for bad blocks [first last]);
+ check NAND flash device num for bad blocks [offset length]);
Re: [Openocd-development] [patch] more NAND cleanup and doc updates
On Friday 22 May 2009, David Brownell wrote:
Update two oddball NAND commands to work with {offset, length}
instead of block numbers...
And FYI that pretty much sums up all the NAND function/doc patches
I expect to send for this release. There's now sane doc matching
the current code, and the main warts have been filed down.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Sat, 2009-05-23 at 00:46 +0200, Magnus Lundin wrote: Zach Welch wrote: On Sat, 2009-05-23 at 00:18 +0200, Magnus Lundin wrote: Zach Welch wrote: On Tue, 2009-05-19 at 16:53 +0200, Magnus Lundin wrote: [snip] There is a set of new patches that has been tested by Michael Fischer, as far as i know there were no problems. There are still things that should be fixed in the resethandling in jtag_add_reset and minimizing the differences between ft2232 and jlink behaviour. But still would suggest that the following patcches are commited. They are not untested. I will apply them here and see if they magically cure my own woes. Regardless, I think these changes should be committed in some for, though I can see various ways that I would like to clean your code. Would you mind my taking a pass over them before I commit them? Sure, I am out of style discussions on this list. Committed the jlink.c changes as r1889. While the JTAG and FTDI changes look fine too, I cannot judge their relative risk/reward at this time, so I feel that I must defer to others on those. I'll follow up though. I kept track of every change that I made in cleaning and included the list with my commit message. My changes were only on (or very near) those lines that you added or changed in your patch. The results were frustrating for me (to say the least), but I hope my efforts will help motivate everyone to avoid similar mistakes in the future. In total, my cleaning removed 1.9K of superfluous changes, which was over 25% of the original patch. The changes are now easier to review, and the code is much easier to understand as a bonus. Here is a short list of things that this patch did wrong: -- Hard-coded constants in code. -- Inefficient flow-control statements (stylistically speaking) -- Insufficient use of temporary variables. -- Superfluous whitespace/comment-style changes. While these are superficial to the compiler, they have a profound affect on the substance of the code for those developing with it. Regardless, the J-Link now works _much_ better for me in my own tests, so I and the entire community of J-Link users owe you a Big Thanks. :) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
