Re: [Openocd-development] Show of hands for/against gerrit
On Fri, Oct 7, 2011 at 5:48 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: http://code.google.com/p/gerrit/ I have no idea what it does, but I'm very excited! :-) Looks interesting, I wonder if it has mailing list integration or simply use emails for notifications :-) I am a bit afraid of the *.war file extensions :-P -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Show of hands for/against gerrit
I'm also a +1. Jim ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Atmel SAM3N with OpenOCD 0.5.0 (and git HEAD too)
On Thu, 6 Oct 2011 23:07:44 +0200 Andreas Fritiofson andreas.fritiof...@gmail.com wrote: That log doesn't show that OpenOCD hangs after accessing flash. The Flash bank access DONE part is wrong, the flash bank has only been set up in OpenOCD, there hasn't been any communication with the target yet. Oops, ok a misinterpretation on my side. It obviously hangs during init, which could mean just about anything. It's impossible to tell without a debug log (-d3). I strippped the script down to what is needed. And get the following output, using current git master/HEAD: ---schnipp--- # src/openocd -f /tmp/armusbocd.script Open On-Chip Debugger 0.6.0-dev-00090-gda8ce5f (2011-10-07-14:09) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 15 kHz trst_only separate trst_push_pull target created Flash bank access DONE Info : clock speed 15 kHz Info : JTAG tap: sam3n.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Info : sam3n.cpu: hardware has 6 breakpoints, 4 watchpoints post init ---schnapp--- A -d3 output is attached. The bt is this: ---schnipp--- (gdb) bt #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb7f1fc3d in select () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0xb7fb72be in ?? () from /lib/i386-linux-gnu/libusb-0.1.so.4 #3 0xb7fc1315 in ftdi_read_data () from /usr/lib/i386-linux-gnu/libftdi.so.1 #4 0x08081dc9 in ft2232_read (buf=0xb7e38008 \202\t\017K\003\003\033\002\vK\002\203K\002\001\031\003, size=12, bytes_read=0xb02c) at ft2232.c:575 #5 0x08082098 in ft2232_send_and_recv (first=0xb7d37008, last=0x0) at ft2232.c:844 #6 0x08085691 in ft2232_execute_queue () at ft2232.c:2136 #7 0x08050e5d in interface_jtag_execute_queue () at driver.c:485 #8 0x0804e77f in jtag_execute_queue_noclear () at core.c:835 #9 0x0804e858 in jtag_execute_queue () at core.c:854 #10 0x080ae475 in jtagdp_transaction_endcheck (dap=0x81d03ec) at adi_v5_jtag.c:226 #11 jtag_dp_run (dap=0x81d03ec) at adi_v5_jtag.c:435 #12 0x080e43c7 in cortex_m3_poll (target=0x81cf290) at cortex_m3.c:536 #13 0x08064c82 in target_poll (target=0x81cf290) at target.c:453 #14 0x080658cb in handle_target (priv=0x81b1028) at target.c:1999 #15 handle_target (priv=0x81b1028) at target.c:1916 #16 0x0805c77b in target_call_timer_callback (now=0xb268, cb=0x81d6b38) at target.c:1147 #17 target_call_timer_callbacks_check_time (checktime=1) at target.c:1176 #18 0x08071f4b in server_loop (command_context=0x81b1008) at server.c:433 #19 0x0804b9ac in openocd_thread (cmd_ctx=0x81b1008, argv=0xb464, argc=3) at openocd.c:306 #20 openocd_main (argc=3, argv=0xb464) at openocd.c:339 #21 0x0804b275 in main (argc=3, argv=0xb464) at main.c:42 ---schnapp--- Any help would be appreciated Attila Kinali -- The trouble with you, Shev, is you don't say anything until you've saved up a whole truckload of damned heavy brick arguments and then you dump them all out and never look at the bleeding body mangled beneath the heap -- Tirin, The Dispossessed, U. Le Guin armusbocd.script Description: Binary data armusbocd.out.d3 Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Atmel SAM3N with OpenOCD 0.5.0
On Thu, 6 Oct 2011 23:07:44 +0200 Andreas Fritiofson andreas.fritiof...@gmail.com wrote: Other than that I'm not of much use, I haven't worked with any of the targets. Btw: if it would help, i could send you (or anyone else for that matter) one of the SAM3N evaluation boards[1]. Attila Kinali [1] http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4846 -- The trouble with you, Shev, is you don't say anything until you've saved up a whole truckload of damned heavy brick arguments and then you dump them all out and never look at the bleeding body mangled beneath the heap -- Tirin, The Dispossessed, U. Le Guin ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Start porting of usb jtag drivers to libusb-1.0 instead of libusb.0.1
Hello to everyone, I start the porting of the usb jtag drivers to the libusb-1.0 library. I tested the jlink driver under linux and it work quite well. I've ported also the rlink and usbprog driver but I can't test them without the hardware. I didn't touch other drivers but I want to submit a patch to have feedback and understand if I'm doing the right things. Regards, Mauro Gamba ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Compile errors....
I'm getting compile errors from a fresh clone of the tree in the files: src/target/armv7a.c src/target/cortex_a.c having to do with unused but set variables. Did I miss something? Jim ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compile errors....
On Fri, Oct 7, 2011 at 4:34 PM, jim norris u17...@att.net wrote: I'm getting compile errors from a fresh clone of the tree in the files: src/target/armv7a.c src/target/cortex_a.c having to do with unused but set variables. Did I miss something? OpenOCD compiles with -Werror which causes all warnings to produce errors. This is to force us to fix all errors as we go along. Please submit a patch to fix the warnings. Thanks! -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Atmel SAM3N with OpenOCD 0.5.0
Atilla, I've been able to bring up your script, with the steps after 'pre init' commented out, using an Olimex ARM-USB-OCD and an Atmel SAM3N-EK development board. I configured OpenOCD with the following: ./configure --enable-maintainer-mode --enable-jlink --enable-ft2232_libftdi Everything seemed to work okay for me on a Fedora 15 system with version 0.18 of libftdi. Jim ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] load_image trouble
On Fri, Oct 7, 2011 at 7:34 AM, Dmitry E. Oboukhov un...@debian.org wrote: I cant upload an image into internal SRAM (AT91SAM9). it can really write only 20 bytes. load_image into internal flash area works fine. But why it doesn't fail if it writes the other regions? It crashes only if it writes into internal SRAM. Could it be that the load_image command uses working area which overlaps with the address you're trying to write, thus corrupting the algorithm? No, I've tested writing area address:0x30-0x300040 (SRAM start address). So, where is your working area? I don't know which config file you use but, looking through some of the at91*.cfg, they generally set up working area to 0x30 and a few KB onwards. Have you tried moving it a bit to see if it makes a difference. I don't see why load_image should need to use working area so maybe it's a long shot. Worth a try anyway. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Show of hands for/against gerrit
+2 Reviewed, +1 Verified... :) Having used Gerrit a little bit, where I work, it seems to enforce a workflow that this mailing list already uses. Any submitted patch needs to go through the review process before it is accepted into Trunk. If a patch needs work, a second version can be submitted with the same Change-Id, and the history of reviews for both patches will be attached together, and only the final revision will be accepted into trunk. My only issue is, I wonder where it would be hosted? Can SourceForge do that? What about appspot.com (AppEngine)? - Alex -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Thursday, October 06, 2011 4:02 PM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Show of hands for/against gerrit I find gerrit intriguing as a way of managing patches. Can I have a show of hands of contributors for/against/don't care/don't know? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.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
Re: [Openocd-development] Atmel SAM3N with OpenOCD 0.5.0 (and git HEAD too)
On Fri, Oct 7, 2011 at 2:37 PM, Attila Kinali att...@kinali.ch wrote: On Thu, 6 Oct 2011 23:07:44 +0200 Andreas Fritiofson andreas.fritiof...@gmail.com wrote: It obviously hangs during init, which could mean just about anything. It's impossible to tell without a debug log (-d3). I strippped the script down to what is needed. And get the following output, using current git master/HEAD: ---schnipp--- # src/openocd -f /tmp/armusbocd.script Open On-Chip Debugger 0.6.0-dev-00090-gda8ce5f (2011-10-07-14:09) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 15 kHz trst_only separate trst_push_pull target created Flash bank access DONE Info : clock speed 15 kHz Info : JTAG tap: sam3n.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Info : sam3n.cpu: hardware has 6 breakpoints, 4 watchpoints post init ---schnapp--- Well, what's the problem now? It seems to work? Or at least get through init, since post init is printed now, which it wasn't before. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
