Re: [Openocd-development] openocd support database
I haven't looked into this, but essentially it is a database over what worked in which version? when should be svn #. The time the test was run isn't *that* interesting. W.r.t. gathering these reports. It's harder to get users to run these smoketests when everything is working fine than when OpenOCD is broken :-) I was thinking that we could get a lot more information if there was a command line tool to gather information required to post a bugreport That way every time someone has a bug, they can gather some info for the smoketesting database. Eventually I expect *most* bugs to be able to creep past *all* the smoketests. So at the top of an email w/a bug report to the list there could be a link to smoketests run in the database for the interface/target combination... -- Ø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] arm7_9_common: Documentation and Typos
On May 19, 2009, at 10:42 PM, Zach Welch wrote:
On Tue, 2009-05-19 at 22:14 -0700, David Brownell wrote:
On Tuesday 19 May 2009, Dean Glazeski wrote:
changed all 'struct target_s' to 'target_t' to keep things
consistent.
I'd rather do away with all typedefs myself, except maybe
for int variants. Ditto that *_t convention.
Anyone feel strongly pro-typedef?
I think typedefs have their place, but I agree they are BAD when
used in
header file declarations.
It all depends. I've seen really horrible uses of typedefs and I've
seen really good use of typedefs. For example, an opaque handle that
is provided to callers of an API to track a resource is really nice as
a typedef. Sure, you can use the socket approach and hand back an int
or you could hand back a pointer to a forward-declared struct, but
that makes the API unnecessarily ugly or confusing. Instead, a
typedef clarifies that the argument is a handle as opposed to an
arbitrary int and allows an easy change in the backing type assuming
everyone recompiles.
I'm not a fan of things like 'typedef uint32_t UInt32'. That is
redundant and only serves as a bad hack instead of a search and replace.
Why? Because 'struct foo' can be forward-declared safely if it will
be
used only for pointers.
If a header includes a 'typedef struct foo foo_t', you can safely
write foo_t * if you want to include the header or 'struct foo *' if
you don't. The typedef just gets rid of the C oddities of putting
structs and enums in their own namespaces.
In turn, this allows header files to be
decoupled from one another. Go back and look at the changes that I
started to decouple the headers and you will see me _removing_
typedefs
to accomplish that mission.
Technically, the typedefs didn't need to be removed to accomplish
that. In fact, the removal of the typedefs can easily cause more
confusion. For simple structs, this isn't necessarily a problem, but
more complex types easily show the benefits of typedefs. Consider the
following:
int list_item_next(struct item * head, struct item * cur, struct item
** next);
versus
typedef enum {
...
} list_error_t;
typedef struct item * list_item_t;
typedef struct item * list_t;
list_error_t list_item_next(list_t head, list_item_t cur, list_item_t
* next);
Technically both have the same behavior, but the second makes the
expected arguments clearer (don't pass an arbitrary element as the
head of the list, next is a value-return param, etc). It also allows
the API to change the underlying representations of the types without
the caller changing (but a recompile might be necessary).
As a result, the changes in this patch result in the system being more
tightly coupled than it really needs to be (and takes it in the
opposite
direction that it should be headed), so I am fairly strongly against
applying it without first seeing the typedef changes removed.
typedefs do not introduce strong coupling in any way. There is still
an option to use the forward declaration via the struct when
necessary. Of course, the use of the struct should only be reserved
for those cases where it needs to be a forward declaration to avoid
include loops.
Other than that, it looks great, and I am really appreciating the
work!
Cheers,
Zach
___
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] Short state table enabled as of r1827
Committed Thanks! Michael Fischer + you have tested it now and there is upcoming work in jtag.c, so get this patch out of the way. -- Ø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] Fwd: [PATCH] mflash: add mflash configure feature
1) This needs to be broken up into multiple patches. 2) It looked like lots of error handling was removed rather than added 3) Not sure why the mflash code is being changed to use the mg prefix. What is mg supposed to mean? 4) Lots of gratuitous formatting changes. If we want to do these types of changes, please use the uncrustify config file in the root of the source tree. Also, make that a separate patch so we can apply it without hunting for actual code changes. Rick On May 19, 2009, at 11:22 PM, Øyvind Harboe wrote: I received this in private email. Obviously it was intended for the list. -- Forwarded message -- From: unsik Kim donar...@gmail.com Date: Tue, May 19, 2009 at 10:19 AM Subject: [PATCH] mflash: add mflash configure feature To: Øyvind Harboe oyvind.har...@zylin.com Hello? I attached mflash patch. changed files: src/flash/mflash.c src/flash/mflash.h doc/openocd.texi Add mflash configure feature. Large file write and dump support. Remove unused option from mflash bank command. Improve error handling. Reduce too long lines. Use mg_ as function prefix. --- Regards, unsik Kim donar...@gmail.com -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com mflash-patch.diff___ 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
[Openocd-development] Cannot connect to target
I have OpenOCD r1836 and libftdi 0.16. I have the atmel evaluation board AT91SAM7X-EK, equipped with sam7x256 (we develop 2 boards with sam7x128 and sam7x512). I work with ubuntu linux 64bit: $ uname -a Linux lab7 2.6.27-14-generic #1 SMP Wed Apr 15 19:29:46 UTC 2009 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 8.10 Release:8.10 Codename: intrepid once compiled openocd I try to connect to AT91SAM7X-EK with sample scrips and obtain the following error $ sudo openocd -f /usr/local/lib/openocd/interface/jtagkey.cfg -f /usr/local/lib/openocd/target/sam7x256.cfg -d 3 Open On-Chip Debugger 0.2.0-in-development (2009-05-19-17:29) svn:1836 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ Debug: 5 0 configuration.c:83 find_file(): found /usr/local/lib/openocd/interface/jtagkey.cfg Debug: 7 0 command.c:88 script_command(): script_command - interface Debug: 8 0 command.c:105 script_command(): script_command - interface, argv[0]=ocd_interface Debug: 9 0 command.c:105 script_command(): script_command - interface, argv[1]=ft2232 Debug: 11 0 command.c:88 script_command(): script_command - ft2232_device_desc Debug: 12 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc Debug: 13 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[1]=Amontec JTAGkey A Debug: 15 0 command.c:88 script_command(): script_command - ft2232_layout Debug: 16 0 command.c:105 script_command(): script_command - ft2232_layout, argv[0]=ocd_ft2232_layout Debug: 17 0 command.c:105 script_command(): script_command - ft2232_layout, argv[1]=jtagkey Debug: 19 0 command.c:88 script_command(): script_command - ft2232_vid_pid Debug: 20 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[0]=ocd_ft2232_vid_pid Debug: 21 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[1]=0x0403 Debug: 22 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[2]=0xcff8 Debug: 23 0 configuration.c:83 find_file(): found /usr/local/lib/openocd/target/sam7x256.cfg Debug: 25 1 command.c:88 script_command(): script_command - reset_config Debug: 26 1 command.c:105 script_command(): script_command - reset_config, argv[0]=ocd_reset_config Debug: 27 1 command.c:105 script_command(): script_command - reset_config, argv[1]=srst_only Debug: 28 1 command.c:105 script_command(): script_command - reset_config, argv[2]=srst_pulls_trst Debug: 29 1 jtag.c:1995 jim_newtap_cmd(): Creating New Tap, Chip: sam7x256, Tap: cpu, Dotted: sam7x256.cpu, 8 params Debug: 30 1 jtag.c:2014 jim_newtap_cmd(): Processing option: -irlen Debug: 31 1 jtag.c:2014 jim_newtap_cmd(): Processing option: -ircapture Debug: 32 1 jtag.c:2014 jim_newtap_cmd(): Processing option: -irmask Debug: 33 1 jtag.c:2014 jim_newtap_cmd(): Processing option: -expected-id Debug: 34 1 jtag.c:2127 jim_newtap_cmd(): Created Tap: sam7x256.cpu @ abs position 0, irlen 4, capture: 0x1 mask: 0xf Debug: 35 1 target.c:3959 jim_target(): Target command params: Debug: 36 1 target.c:3960 jim_target(): target create sam7x256.cpu arm7tdmi -endian little -chain-position sam7x256.cpu -variant arm7tdmi Debug: 38 1 command.c:88 script_command(): script_command - bank Debug: 39 1 command.c:105 script_command(): script_command - bank, argv[0]=ocd_flash_bank Debug: 40 1 command.c:105 script_command(): script_command - bank, argv[1]=at91sam7 Debug: 41 1 command.c:105 script_command(): script_command - bank, argv[2]=0 Debug: 42 1 command.c:105 script_command(): script_command - bank, argv[3]=0 Debug: 43 1 command.c:105 script_command(): script_command - bank, argv[4]=0 Debug: 44 1 command.c:105 script_command(): script_command - bank, argv[5]=0 Debug: 45 1 command.c:105 script_command(): script_command - bank, argv[6]=0 Debug: 47 1 command.c:88 script_command(): script_command - init Debug: 48 1 command.c:105 script_command(): script_command - init, argv[0]=ocd_init Debug: 49 1 openocd.c:131 handle_init_command(): target init complete Debug: 50 1 ft2232.c:1985 ft2232_init(): ft2232 interface using shortest path jtag state transitions Debug: 51 1 ft2232.c:1904 ft2232_init_libftdi(): 'ft2232' interface using libftdi with 'jtagkey' layout (0403:cff8) Debug: 52 29 ft2232.c:1948 ft2232_init_libftdi(): current latency timer: 2 Debug: 53 32 ft2232.c:2219 jtagkey_init(): 80 08 1b Debug: 54 35 ft2232.c:2277 jtagkey_init(): 82 09 0f Debug: 55 38 ft2232.c:422 ft2232_speed(): 86 00 00 Debug: 56 56 openocd.c:138 handle_init_command(): jtag interface init complete Debug: 57 56 jtag.c:2348 jtag_init_inner(): Init JTAG chain Debug: 58 56 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 59 56 jtag.c:1595 jtag_reset_callback(): - Debug: 60 56 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST)
Re: [Openocd-development] Fwd: [PATCH] mflash: add mflash configure feature
1) This needs to be broken up into multiple patches. Good point. I know my patch contains 4 logical and 2 style changes. That's my mistake. I can make seperate patches but it needs painful time. I hope to use this one. Should I seperate patches? If the answer is yes, I'll follow. 2) It looked like lots of error handling was removed rather than added I only removed target memory write error handling. IMHO, checking target's memory function (like target-type-write_memory) is too excessive. All the mflash IO error checked by this patch. 3) Not sure why the mflash code is being changed to use the mg prefix. What is mg supposed to mean? mg_ is comming from company's name mGine. Also, u-boot and linux mflash driver use this prefix. Just for the unity of mflash driver. 4) Lots of gratuitous formatting changes. If we want to do these types of changes, please use the uncrustify config file in the root of the source tree. Also, make that a separate patch so we can apply it without hunting for actual code changes. Same as 1). --- Regards, unsik Kim donar...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC][PATCH] [0/4] x16_as_x8 tentative implementation.
Hello: On Wednesday 20 May 2009 06:36:41 Rick Altherr wrote: From my cursory reading, everything looks fine and straightforward. Since you marked this as an RFC, I'll hold off committing until it is resent to the list. Rick Thank you very much for your review, Rick. I asked for comments because I would prefer applying a cleaner patch. I would like to know if we can merge flash_address and command_address functionality, but in order to tackle this, I'd like to know if command_address would also be useful in the intel case. Another approach would be applying the patchset as I've send it temporarily while working on the above point. If you prefer this, let me know if you prefer a monolithic patch or will you apply each of them (preferred for me). I'm all ears ;) Regards On May 19, 2009, at 3:54 AM, Raúl Sánchez Siles wrote: Hello: This is my first try to implement the x16_as_x8 flash bank option. It is working for me as I would expect flash to work, but please consider this patchset as work in progress since it may still has some flaws. Al patches touch just src/flash/cfi.c file and should apply in this order to trunk. The patchset consists of 4 patches, whose interest areas I explain and comment below: [...] -- Raúl Sánchez Siles -- 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] arm7_9_common: Documentation and Typos
On Tue, 2009-05-19 at 23:17 -0700, Rick Altherr wrote: On May 19, 2009, at 10:42 PM, Zach Welch wrote: On Tue, 2009-05-19 at 22:14 -0700, David Brownell wrote: On Tuesday 19 May 2009, Dean Glazeski wrote: changed all 'struct target_s' to 'target_t' to keep things consistent. I'd rather do away with all typedefs myself, except maybe for int variants. Ditto that *_t convention. Anyone feel strongly pro-typedef? I think typedefs have their place, but I agree they are BAD when used in header file declarations. It all depends. [snip] Yes, thanks for providing a clearer explanation; however, I do not think that this thread fully resolves the topic. To do that, I think we need to expand the documentation to provide style rules for using typedefs in the OpenOCD code, as no rules cover this particular element at the moment (other than emulate). I cannot discern clear rules from the examples that I have read on this list or in the code, so I think there may need to be a brief discussion on the topic to resolve it fully. I will post a new thread shortly. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RFC: style guide update
Hi all, I want to get the style guide up-to-date. Here's my plan. Barring any objections, I will add doc/manual/style.txt by moving the relevant bits out of openocd.texi. The style guide is for developers working on the code; the user guide should not need to mention the code. though that may take some time. I will then patch the new file with some pending changes that I made when style topics were being discussed in the past month. That patch includes a list of those C99 features that the community seemed to think would be acceptable. Others can then choose to revisit my revisions or to expand this section in its new location. In the process, I will revisit my changes to add another section to provide some rules for typedefs, though I have seen that this needs to be filled out have some discussion. What should the typedef rules be? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: [PATCH] mflash: add mflash configure feature
2) It looked like lots of error handling was removed rather than added I only removed target memory write error handling. IMHO, checking target's memory function (like target-type-write_memory) is too excessive. All the mflash IO error checked by this patch. Actually we want all return codes propagated as a rule. This is in line with exception handling. Minimally this will be useful in test suites to check for induced failures. To *ignore* a return value is on par with a catch in exception handling and there should be something in the code that explains how the error is handled after it is caught. -- Ø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] Cannot connect to target
what is the setup of your jumper J10 (JTAGSEL)! Try : - to down the JTAG speed - to up the TRST / SRST delay Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] arm7_9_common: Documentation and Typos
On Tuesday 19 May 2009, Øyvind Harboe wrote: I'd rather do away with all typedefs myself, except maybe for int variants. Ditto that *_t convention. Anyone feel strongly pro-typedef? I think that typedefs are useful when a level of indirection is needed, it is non-trivial to define the type(u32, u8, intptr_t, etc.) or the type itself is horrible to spell out(pointer to a function which takes a pointer to) That non-trivial encapsulates the portability issues; those all boil down to needed. Except, in some cases, the function typedef ... I'd rather see those spelled out in most signatures, but there are cases where that's just on the wrong side of too painful. When the type is striaghtforward(int or struct), then typedef can make things less readable. typedef struct x x_t is such an example. Right. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Doxygen docs
How does mere mortals figure out how to build doxygen docs? The README points to openocd.texi as the auhtoritiative source of documentation? A developer chapter in openocd.texi? Perhaps this should be built and posted daily like openocd.pdf? -- Ø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] OpenOCD and different versions of J-Link
Xiaofan, After telnet connect, which monitor command produces this: Info : accepting 'telnet' connection from 0 TapName| Enabled | IdCode ExpectedIrLen IrCap IrMask Instr ---||-|||--|--|--|- 0 | lpc2148.cpu|Y| 0x4f1f0f0f | 0x4f1f0f0f | 0x04 | 0x01 | 0x0f | 0x0c I don't see this with my setup (using str71x board). Possibly unique to your lpc2148 cpu? I haven't yet tried Magnus merged patch. Will report shortly on if it works for me. Thanks, -gene ___ 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
Magnus Lundin wrote: The following patch combines my previous patch with most of Ben's patch. It can use both EMU_CMD_HW_JTAG2 and EMU_CMD_HW_JTAG3 It defaults to EMU_CMD_HW_JTAG2 so it should work with all interfaces but EMU_CMD_HW_JTAG3 is recommended by SEgger, you can change the behaviour with jlink_hw_jtag 3 or jlink_hw_jtag 2 Autodetection can be done when we know which versions JLink can use what setting, (-d3 logs of setup messages ) Have a nice day Magnus Seems to work OK for me too (hw version yellow/V4 OEM IAR). If I do jlink_hw_jtag 2 it loses USB comm (LED on jlink goes off) and I see messages: jlink hw jtag 3 Error: usb_bulk_read failed (requested=12, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 12) Error: usb_bulk_read failed (requested=12, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 12) Error: usb_bulk_read failed (requested=12, result=-110) : :Must restart openocd to recover. Note: see similar string of messages if USB is unplugged from Jlink while running and must restart it. Does not recover when USB replugged. So I guess I must use 2. Still see occasional segfault on startup (still running r1833 except for jlink.c patch). -gene ___ 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 Wed, May 20, 2009 at 9:25 PM, Gene Smith g...@chartertn.net wrote: Xiaofan, After telnet connect, which monitor command produces this: Info : accepting 'telnet' connection from 0 TapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr ---||-|||--|--|--|- 0 | lpc2148.cpu | Y | 0x4f1f0f0f | 0x4f1f0f0f | 0x04 | 0x01 | 0x0f | 0x0c I don't see this with my setup (using str71x board). Possibly unique to your lpc2148 cpu? I haven't yet tried Magnus merged patch. Will report shortly on if it works for me. Use scan_chain. -- 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 Wed, May 20, 2009 at 10:06 PM, Gene Smith g...@chartertn.net wrote: So I guess I must use 2. Yes that is right. For v1/2/3/4, you have to use 2. Still see occasional segfault on startup (still running r1833 except for jlink.c patch). The latest version (1857) seems to be ok, no more segfault. I have segfault with V1836 as well. -- 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
Xiaofan Chen wrote: On Wed, May 20, 2009 at 10:06 PM, Gene Smith g...@chartertn.net wrote: So I guess I must use 2. Yes that is right. For v1/2/3/4, you have to use 2. Still see occasional segfault on startup (still running r1833 except for jlink.c patch). The latest version (1857) seems to be ok, no more segfault. I have segfault with V1836 as well. Jlink very snappy with Insight/gdb now after setting jtag_hz to 0 (adaptive). Before at 10 Khz (openocd default for str71x) it was pretty sluggish (but worked OK). With RCLK adaptive it also is stable, so far. Seems to program flash on STR712/IAR eval board much faster too (but just a small program, but seems about the same as programming/debugging at the IAR IDE now). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] remove usage of TAP_INVALID global variable to track current end state
On Wed, May 20, 2009 at 6:30 PM, Magnus Lundin lun...@mlu.mine.nu wrote: I think that you should first figure out the logic of controlling several different targets on the same scan chain, with different demands on extra or no extra RTI, specific numbers of transitions etc, how can they communicate their differing needs ? I'm trying to define an API where any default state scheme can be synthesized on top of the JTAG API. This avoids trying to peer into a chrystal ball trying to map out all possible future needs. What I don't understand is what the JTAG layer could possibly contribute here in terms of figuring out what the default state should be. What's even more unclear to me is how any such behaviour could not or should not be synthesized on top of a JTAG API. Certainly a few wrapper fn's around a global variable(be it inside the interface or globally, same thing really), just makes the code more mysterious. -- Ø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] remove usage of TAP_INVALID global variable to track current end state
On Wed, May 20, 2009 at 6:10 PM, Michael Bruck mbr...@digenius.de wrote: I am all in favor for this change. But I would prefer to eliminate the cases first where jtag_add_end_state() is called immediately before jtag_add_*r_scan(..., TAP_INVALID). On arm11.h: ARM11_TAP_DEFAULT should not be changed. It is used only between the arm11 and the arm11_dbgtap layer. The calls to the jtag.c layer all use explicit end states. The idea is to split the deprecation of the API and the phasing out of the API. After the sequence of steps that I outlined are complete, we're left with a mess to clean up. Things are no better or worse than before(in fact it's bug-by-bug compatible), but it is very clear that global variables are being used. -- Ø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] Making all jtag controllers behave equally
Hi Now when we have almost got the new state table infrastructure in plaec and working it is time to think ahead. Shall we retire the 7 step transitions ? No ! expand the founctionallity to allow user (target) defined state transition tables, the current code allows that. Maybe not the default and not recommended for casual users but - Why limit the possibilities ?? Make all jtag interfaces behave as similar as possible ! Perhaps the most problematic is reset handling. Interface jtag reset command handlers should ONLY do one thing: - set hw rst and trst lines to desired state, if necessary execute jtag communications Upper Jtag layer (jtag.c) handles ALL logic about - flushing command queues - setting TAP_RESET state when trst is asserted, adding extra state_move(RAT_RESET) , handling srts_pulls_trst logic etc. This is logic is already confusing and doing it in several places even more so. Just some ideas. Have a nice evening Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] remove usage of TAP_INVALID global variable to track current end state
I am all in favor for this change. But I would prefer to eliminate the cases first where jtag_add_end_state() is called immediately before jtag_add_*r_scan(..., TAP_INVALID). On arm11.h: ARM11_TAP_DEFAULT should not be changed. It is used only between the arm11 and the arm11_dbgtap layer. The calls to the jtag.c layer all use explicit end states. Michael On Wed, May 20, 2009 at 5:39 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: This patch is intended to collect feedback on a change to the JTAG API. I do *not* intend to commit any of this until after a discussion 0.2 release: 1. remove TAP_INVALID as a legal argument. The caller *must* provide an end state. 2. deprecate jtag_add_end_state(). It is the calling code's responsibility to figure out what the end state should be. Today this is handled by a global variable, but the calling code can, in time, be converted to handle this more cleanly. Steps: 1. A patch like the attached one. Remove TAP_INVALID as a valid argument. This should be a pretty safe change and have no effect whatsoever. Commit it and wait a week or so for any fallout to be reported(inconceivable, but I'm just being paranoid about this step). I will redo this patch against svn head when it is time to implement step #1(it took 5 minutes to put together). 2. remove all code in jtag.c that assumes that TAP_INVALID can be passed in as an argument. Commit wait. 3. remove all code in interface drivers that assumes TAP_INVALID can be passed in. Commit wait. 4. rename jtag_add_end_state() to deprecated_add_end_state(). Commit wait. Done! At this point the code is littered with usage of global variables. This usage should be cleaned up in due course, but on a schedule that allows testing each commit. Comments? -- Ø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 mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] version.texi will not create under Mac OS X, r1857
Hello list, in case of my cygwin build under windows the version.texi will be created. But in case of Mac OS X not. Any hints where I can take a look at? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Making all jtag controllers behave equally
One disadvantage of having user defined transition tables is that it would make hardware implementations of a JTAG master more tedious. Doable, but more tedious. We have jtag_add_pathmove() to handle the necessary cases. What a JTAG master/interface would have to ensure is that it doesn't go through some state that the target is dependant on NOT going through... the minimal state table that is currently defined takes care of this. I still feel that well behaved targets would add necessary jtag_add_pathmove()'s to make both short/long tms sequences work. One thing that can help clean up the interface drivers is to remove all references to TAP_INVALID In fact I think this can be done safely today as TAP_INVALID should *never* be passed to the interface drivers. -- Ø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] OSBDM
Hi, Other alternative to add BDM support on OpenOCD is based it on OSBDM: http://forums.freescale.com/freescale/board/message?board.id=OSBDM08thread.id=422 This version uses a S08, but I think there is newer source code using MCF51JM. Best Regards, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Strange behavior with r1857 and SAM7S256 (part2)
Hello list, even the same problem with the 1857 if I use the long tms sequence: tms_sequence long Regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Quick Reference
On Tue, 2009-05-19 at 22:50 -0500, Dean Glazeski wrote:
Hey all,
I ran into this during my random googlings: oocd-quickreference. I
was thinking, this might be something cool to put together as part of
the next release. I'd be willing to help kick it off, just wanted to
see what people though.
I like these ideas: both the reference guide and the fact that you are
willing to help work on it. :)
To one-up it (as is my wont), it would be nice to produce a set of LaTeX
documents that could produce either 1) a complete reference of the TCL
command set or 2) a quick reference, depending on the surrounding
context that the core .tex file gets applied:
doc/user_ref/full_guide.tex
doc/user_ref/quick_guide.tex
doc/user_ref/parts/*.tex
The 'parts' would be included by the first two, in the appropriate
places, with each defining different commands for defining the commands.
For example, the top-level files could define different versions of
\newcommand{\oocdCmdName}[1]{...}
\newcommand{\oocdCmdBriefDesc[1]{...}
\newcommand{\oocdCmdFullDesc[1]{...}
The quick reference would simply define its version of the last to drop
any provided content from its output, whereas the full reference would
integrate it by providing the appropriate formatting. The result would
produce two different works that are positively in-sync with each other,
without any duplication of documentation effort (and less mechanical
redundancy in the documentation itself, once you grok the above syntax).
What do you think? Do you know LaTeX? I love it for making writing
more like coding. :)
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RPM Build
Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz I need to know what they are for so I can take the appropriate action to fix them for the RPM build for Fedora. I know the last one is the info file. I'm going to look into making a match that makes it UTF to make things happy. I'm not sure what the other files are for. Do they make sense in a final distribution of OpenOCD? If so, what are they for? I appreciate any help I can get. Thanks. // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Quick Reference
Hey all,
To one-up it (as is my wont), it would be nice to produce a set of LaTeX
documents that could produce either 1) a complete reference of the TCL
command set or 2) a quick reference, depending on the surrounding
context that the core .tex file gets applied:
doc/user_ref/full_guide.tex
doc/user_ref/quick_guide.tex
doc/user_ref/parts/*.tex
The 'parts' would be included by the first two, in the appropriate
places, with each defining different commands for defining the commands.
For example, the top-level files could define different versions of
\newcommand{\oocdCmdName}[1]{...}
\newcommand{\oocdCmdBriefDesc[1]{...}
\newcommand{\oocdCmdFullDesc[1]{...}
I like this idea and wouldn't mind playing around with the idea.
The quick reference would simply define its version of the last to drop
any provided content from its output, whereas the full reference would
integrate it by providing the appropriate formatting. The result would
produce two different works that are positively in-sync with each other,
without any duplication of documentation effort (and less mechanical
redundancy in the documentation itself, once you grok the above syntax).
What do you think? Do you know LaTeX? I love it for making writing
more like coding. :)
Unfortunately, I am not skilled in the ways of LaTeX. I have tried to
do it before but sort of fell on my face doing it :). I have to say, I
do like writing in a way that is like coding, much in the way I like
drawing with code (GraphViz). At any rate, I'll start looking into it.
Forward me any good LaTeX references you may have that can help me.
// Dean Glazeski
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Magnus Lundin wrote: Dean Glazeski wrote: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz I think : The libddc files are for building target dcc implementations, and nothing in this list is used by the actual running openocd image on fedora. So this is really reference materials for developers. That might help you decide where to place them. Does this mean I can just remove them and be happy? Doing that definitely makes my life much simpler ;). Unless I hear otherwise, I'll rebuild the RPM without these later tonight (its 7pm where I'm at) and I'll throw the RPM up for review with Fedora tomorrow. Thanks! // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Dean Glazeski wrote: Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf /usr/lib64/openocd/ecos/at91eb40a.elf These are *TARGET* files, the package tool you have is *WRONG*HEADED*, or mis-informed - it sees the file as an ELF, then wrong assumes it is an *ELF* target for the intended HOST. You might want to ask the packaging people how to identify such files My hunch is, they have *NEVER* thought about this situation! openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h Again, I think the package tool is wrong or mis-informed, this is a cross compilation package - these are example source files that a user of this tool might use - they are not *HOST* files, but are instead, *TARGET* files and are rightfully included in the package. openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz This I don't know enough about TexInfo stuff to answer - sorry. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Dean Glazeski wrote: Magnus Lundin wrote: Dean Glazeski wrote: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz I think : The libddc files are for building target dcc implementations, and nothing in this list is used by the actual running openocd image on fedora. So this is really reference materials for developers. That might help you decide where to place them. Does this mean I can just remove them and be happy? Doing that definitely makes my life much simpler ;). Unless I hear otherwise, I'll rebuild the RPM without these later tonight (its 7pm where I'm at) and I'll throw the RPM up for review with Fedora tomorrow. Thanks! // Dean Glazeski I have no strong opinion but probably they should be included and go somewhere like /usr/lib/openocd/share/contrib or /usr/share/openocd/contrib/. In the neighboorhood of where all the target cfg files live . This is a bit dictated by Fedora policies. Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Testing, bug tracking and external lists
Magnus Lundin wrote: More of us should be active on places like forum.sparkfun openocd and really help users, get an understanding of the root problem and bring that idea back here to the list to solve it. One suggestion that might help is to Pin a few sticky tags on their forum We should perhaps hash out a few of these things here on the list - and then have them pinned. For instance.. the one and only PINNED item is how to build for svn 717 -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] support avr32
I'd like to know if OpenOCD support AVR32 (AP7000) processors? I was looking a tool [1] to write the flash memory of Atmel reference design ATNGW100. From this maillist history I saw a thread [2] discussing how to add a new target but no further discussion. [1] http://www.sparkfun.com/commerce/product_info.php?products_id=13 [2] https://lists.berlios.de/pipermail/openocd-development/2009-February/004707.html Is it possible using that to rewrite, for example, u-boot in my board? Best regards, --tm ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Duane Ellis wrote: Dean Glazeski wrote: Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf /usr/lib64/openocd/ecos/at91eb40a.elf These are *TARGET* files, the package tool you have is *WRONG*HEADED*, or mis-informed - it sees the file as an ELF, then wrong assumes it is an *ELF* target for the intended HOST. You might want to ask the packaging people how to identify such files My hunch is, they have *NEVER* thought about this situation! The interesting thing about this is that Fedora is sort of hard set on following a filesystem hierarchy standard http://www.pathname.com/fhs/. What this basically means is that architecture specific files go into lib while architecture independent files belong in share. This means that all of the target scripts and this elf file should probably be installed into /usr/share/. I can use patches to fix this for the Fedora RPM if you can tell me how to tweak the build so that the files go elsewhere :). It might be good to consider fixing this to follow the FHS in the current head. openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h Again, I think the package tool is wrong or mis-informed, this is a cross compilation package - these are example source files that a user of this tool might use - they are not *HOST* files, but are instead, *TARGET* files and are rightfully included in the package. Yeah, I don't know how to fix this one. It goes to the right area according to FHS, but it's being picked up as problematic (really just a warning). I'm searching around wiki pages, google, and IRC chats for answers. openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz This I don't know enough about TexInfo stuff to answer - sorry. -Duane. Thanks for the responses. // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
On Wed, 2009-05-20 at 21:43 -0500, Dean Glazeski wrote: Duane Ellis wrote: Dean Glazeski wrote: Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf /usr/lib64/openocd/ecos/at91eb40a.elf These are *TARGET* files, the package tool you have is *WRONG*HEADED*, or mis-informed - it sees the file as an ELF, then wrong assumes it is an *ELF* target for the intended HOST. You might want to ask the packaging people how to identify such files My hunch is, they have *NEVER* thought about this situation! The interesting thing about this is that Fedora is sort of hard set on following a filesystem hierarchy standard. What this basically means is that architecture specific files go into lib while architecture independent files belong in share. This means that all of the target scripts and this elf file should probably be installed into /usr/share/. I can use patches to fix this for the Fedora RPM if you can tell me how to tweak the build so that the files go elsewhere :). It might be good to consider fixing this to follow the FHS in the current head. If you provide a list of difference between the actual/expected install paths for the files in question, I can take a look at the changes required for the autotools scripts. This should be easy to fix, and I am not opposed to doing it. Can such changes negatively affect others? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [1/11]
- add doxygen comments to scan commands in jtag.c - move jtag_add_dr_scan next to interface_jtag_add_dr_scan to keep these function pairs together Michael commit-01-53b89a8.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [2/11]
- add 'const' qualifier to function parameters in jtag.c that are not to be modified or freed by the function Michael commit-02-e7704e6.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [4/11]
- jtag.c: Use single 'for' statement to iterate over list of TAPs in scan functions Michael commit-04-4f198db.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [5/11]
- jtag.c: remove unused variable 'nth_tap' from DR scan functions Michael commit-05-d633f19.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [3/11]
- jtag.c: consolidate all memory allocations in scan functions in one block, add out_fields pointer to set stage for further changes Michael commit-03-cfc2397.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [7/11]
-jtag.c, interface_jtag_add_ir_scan(): - use pointer 'field' instead of scan-fields[nth_tap] - add assertion to ensure that input data has correct size for TAP's IR Michael commit-07-3525e31.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [8/11]
-jtag.c, interface_jtag_add_dr_scan(): - use pointer 'field' instead of scan-fields[field_count] - restructure the main loop to clearly separate the two cases: TAP is not bypassed / TAP is bypassed - add an assert that each non-bypassed TAP receives at least one field - add an assert that checks that no superfluous input fields were passed Michael commit-08-90a4c4e.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [9/11]
- jtag.c, interface_jtag_add_dr_out(): - use pointer 'field' instead of scan-fields[field_count] - restructure the main loop to clearly separate the two cases: TAP is not bypassed / TAP is bypassed (this is to keep the function similar to interface_jtag_add_dr_scan()) - fix bug where only the first output field has its tap field set - add asserts to verify that target_tap points to the one not bypassed TAP Michael commit-09-b924d63.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [10/11]
- jtag.c, interface_jtag_add_ir_scan() [1/2]: - remove temporary scan_size and use tap-ir_length instead - slight loop restructuring to reduce indentation level Michael commit-10-cb32fa6.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jtag.c last set of changes [11/11]
- jtag.c, interface_jtag_add_ir_scan() [2/2]: - retire variable 'found' and use goto instead - add comments on loops Michael commit-11-506cef0.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Zach Welch wrote: On Wed, 2009-05-20 at 21:43 -0500, Dean Glazeski wrote: Duane Ellis wrote: Dean Glazeski wrote: Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf /usr/lib64/openocd/ecos/at91eb40a.elf These are *TARGET* files, the package tool you have is *WRONG*HEADED*, or mis-informed - it sees the file as an ELF, then wrong assumes it is an *ELF* target for the intended HOST. You might want to ask the packaging people how to identify such files My hunch is, they have *NEVER* thought about this situation! The interesting thing about this is that Fedora is sort of hard set on following a filesystem hierarchy standard. What this basically means is that architecture specific files go into lib while architecture independent files belong in share. This means that all of the target scripts and this elf file should probably be installed into /usr/share/. I can use patches to fix this for the Fedora RPM if you can tell me how to tweak the build so that the files go elsewhere :). It might be good to consider fixing this to follow the FHS in the current head. If you provide a list of difference between the actual/expected install paths for the files in question, I can take a look at the changes required for the autotools scripts. This should be easy to fix, and I am not opposed to doing it. Can such changes negatively affect others? Cheers, Zach What's interesting is that it appears that just about everything that goes into /usr/libqual is probably better suited in /usr/share. This is from a 0.1.0 perspective, but all of the TCL scripts, config scripts, and the pre-built elf (for ecos) and bin (for xscale) are all host architecture independent and should be in /usr/share. The config scripts, however, might have a better place in /etc/openocd or some such since they configure the operation of OpenOCD. I think this may affect some of the pieces that are looking for these TCL scripts and the config scripts, but I haven't looked into that stuff. Another question I had is if the source code for the static elf library and the bin is available. I thought I read somewhere about Fedora wanting the source for static libraries. I think there might be an exception for libraries that are compiled for other architectures, aka, ARM and XScale, but I figured it'd be good to find out now. // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag.c last set of changes [11/11]
On May 20, 2009, at 8:30 PM, Michael Bruck wrote: - jtag.c, interface_jtag_add_ir_scan() [2/2]: - retire variable 'found' and use goto instead - add comments on loops Michael commit -11-506cef0.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I'm not really keen on the use of goto in this case. The use of found breaks the code into two clear phases: locate the fields for the tap, and process the fields for that tap. The goto confuses the flow when reading the code. -- 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] jtag.c last set of changes [1/11]
On May 20, 2009, at 8:29 PM, Michael Bruck wrote: - add doxygen comments to scan commands in jtag.c - move jtag_add_dr_scan next to interface_jtag_add_dr_scan to keep these function pairs together Michael commit -01-53b89a8.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed 1-10 as r1859-r1868 -- 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] keep FTDI bitbang status at shutdown
On Feb 23, 2009, at 2:46 AM, Holger Schurig wrote: When I connected to my target and issue the shutdown command via telnet, my target immediately freezes. However, I'd like to use my target device, no matter if openOCD is debugging it or not. Ctrl-C doesn't send the target to nirvana, thought. I tracked this down to a ftdi_disable_bitbang() call that is only there in the BUILD_FT2232_LIBFTDI patch. BTW: urjtag is even worse :-) --- openocd.orig/src/jtag/ft2232.c +++ openocd/src/jtag/ft2232.c @@ -2328,8 +2328,6 @@ status = FT_Close(ftdih); #elif BUILD_FT2232_LIBFTDI == 1 - ftdi_disable_bitbang(ftdic); - ftdi_usb_close(ftdic); ftdi_deinit(ftdic); ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed revision 1869. -- 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] target_read/write_buffer size 0
Committed revision 1870.
On Mar 2, 2009, at 11:27 AM, Øyvind Harboe wrote:
Should a target_read/write_buffer() be a silent no-op or generate an
explicit
error?
I have reason to believe 0 sized elf sections can occur...
Index: C:/workspace/openocd/src/target/target.c
===
--- C:/workspace/openocd/src/target/target.c(revision 1395)
+++ C:/workspace/openocd/src/target/target.c(working copy)
@@ -979,6 +979,12 @@
LOG_ERROR(Target not examined yet);
return ERROR_FAIL;
}
+
+ if (size==0)
+ {
+ LOG_DEBUG(size=0 is safe no-op);
+ return OK;
+ }
if ((address + size - 1) address)
{
@@ -1054,6 +1060,12 @@
LOG_ERROR(Target not examined yet);
return ERROR_FAIL;
}
+
+ if (size==0)
+ {
+ LOG_DEBUG(size=0 is safe no-op);
+ return OK;
+ }
if ((address + size - 1) address)
{
--
Øyvind Harboe
PayBack incident management system
Reduce costs and increase quality, free Starter Edition
http://www.payback.no/index_en.html
___
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] FT2232H / FT2242H support for D2XX driver
On Wed, 2009-05-20 at 22:23 -0700, Rick Altherr wrote: On Mar 25, 2009, at 2:54 PM, joern kaipf wrote: * autodetection if FS or HS device attachted - adapt tck max * enable adaptive clocking if HS device attached and jtag_khz = 0 in cfg (not tested yet) Note: The HS devices are currently only support by the drivers from FTDI and not from the libftdi. So using libftdi and RTCK support will cause a error message. ft2232.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development This doesn't appear to have been applied, but doesn't apply cleanly to HEAD. Is there an updated version available? I cleaned it up and posted it here: https://lists.berlios.de/pipermail/openocd-development/2009-April/005479.html It probably needs a little more work. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Testing, bug tracking and external lists
On Thu, May 21, 2009 at 1:27 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Thu, May 21, 2009 at 9:10 AM, Duane Ellis open...@duaneellis.com wrote: Magnus Lundin wrote: More of us should be active on places like forum.sparkfun openocd and really help users, get an understanding of the root problem and bring that idea back here to the list to solve it. One suggestion that might help is to Pin a few sticky tags on their forum We should perhaps hash out a few of these things here on the list - and then have them pinned. For instance.. the one and only PINNED item is how to build for svn 717 A wiki helps a lot here. Just a simple example, for the Piklab project, we have a short wiki about usb permission problems here. And it indeed helps the user by a lot. http://piklab.wiki.sourceforge.net/USB+Port+Problems And those who is active in the sparkfun forum can put a signature to redirect them to the wiki. The main openocd site can help a lot here as well. Right now it is rather empty. Some simple articles/FAQs/mini-howtos will help the users by a lot. For example, I support a small project pickit-devel. Occasionally I wrote mini howtos and I can point the user to these mini-howtos. http://mcuee.blogspot.com/search/label/PICKit -- 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] resubmit lost works!
On May 15, 2009, at 11:32 AM, David Brownell wrote: On Thursday 14 May 2009, Zach Welch wrote: If anyone knows of patches that have not been applied, please reply here with a link into the mailing list archives to the last version posted: https://lists.berlios.de/pipermail/openocd-development/2009-May/006282.html but here's a tweaked version of that patch. I'd also like to see a brief update about why this list adopts the unusual send as an attachment policy. Generally attachments get discouraged ... since they are harder to review by the normal press reply, trim excess, add in-line comments techniques. - Dave patches.patch___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed with a few modifications for ToT in revision 1872. -- 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
