Re: [Openocd-development] clang static analyzer
openocd-development-boun...@lists.berlios.de wrote: Cool! I agree, it looks cool. I'd like to see patches having to pass clang static analyzer unscathed before they're ready for review :-) I had a quick look at that output, interesting. Some looked like real bugs, but others it seems clang was getting it wrong.. like if (ptr == NULL) checks which it thought failed, but then it complained about a null ptr dereference. It seemed to get if (!ptr) right though, which I think is preferred linux kernel style. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang static analyzer
Patches pushed Gerrit most welcome! :-) -- Ø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] uploading patches without ssh to Gerrit
Is there a way to upload patches to Gerrit w/o ssh? -- Ø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] Trouble enabling TAPs on DM365
Using OpenOCD on TI DM365, something goes wrong when trying to enable extra TAPs using the JRC; it claims they are enabled, but has trouble getting the version of the EmbeddedICE, and the halt command times out and doesn't work. If I set the EMU0/1 pins so that the extra TAPs are always routed in, then things work OK. I have previously used OpenOCD with DM355, the predecessor SoC, which had the same TAP enable by JRC scheme (which works fine). Any clues on this? I think David Brownell would have been the guy. Good output with TAPs fixed as enabled (EMU pins low): Open On-Chip Debugger 0.6.0-dev-00128-g36e3009-dirty (2011-10-19-20:05) ... trst_only separate trst_push_pull CS0 NAND Info : RCLK (adaptive clock speed) not supported - fallback to 1500 kHz Info : JTAG tap: dm365.etb tap/device found: 0x2b900f0f (mfg: 0x787, part: 0xb900, ver: 0x2) Info : JTAG tap: dm365.arm tap/device found: 0x0792602f (mfg: 0x017, part: 0x7926, ver: 0x0) Info : JTAG tap: dm365.jrc tap/device found: 0x0b83e02f (mfg: 0x017, part: 0xb83e, ver: 0x0) Info : Embedded ICE version 6 Info : dm365.arm: hardware has 2 breakpoint/watchpoint units Info : ETM v1.3 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x80d3 pc: 0xb888 MMU: disabled, D-Cache: disabled, I-Cache: disabled --- Bad output with EMU pins high (default) Open On-Chip Debugger 0.6.0-dev-00128-g36e3009-dirty (2011-10-19-20:05) ... trst_only separate trst_push_pull CS0 NAND Info : RCLK (adaptive clock speed) not supported - fallback to 1500 kHz Info : JTAG tap: dm365.jrc tap/device found: 0x0b83e02f (mfg: 0x017, part: 0xb83e, ver: 0x0) Info : JTAG tap: dm365.etb enabled Info : JTAG tap: dm365.arm enabled Info : Embedded ICE version 0 Error: unknown EmbeddedICE version (comms ctrl: 0x) Info : dm365.arm: hardware has 2 breakpoint/watchpoint units Info : ETM v1.0 halt Info : Halt timed out, wake up GDB. Error: timed out while waiting for target halted in procedure 'halt' Holding the EMU pins low is a possibility but means PCB mods to our board, so it would be nice to get this working.. Happy to hack and submit a patch if someone can give me clues to get started. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Only every second programming works
Hi guys! I am trying to program an lpc1768 device using an oocdlink (Ft2232-based) programmer. Only every other programming works, which is very strange. After the first programming, the uC seems to be in a lockup state. After second programming, it always works as a charm. I'm pretty much sure the problem is with my program script, but can anyone please help me out with this? Regards, Ákos Vandra my openocd.cfg: debug_level 1 source [find interface/oocdlink.cfg] source [find target/lpc1768.cfg] jtag_khz 200 my programming script: akos@FM12BQ:~/projects/ARM/falcoeye/Debug$ cat `which burnjtag` #!/bin/sh FILE=`ls *.elf`; #OPENOCD='/home/akos/Downloads/openocd-0.5.0/src/openocd -s /home/akos/Downloads/openocd-0.5.0/tcl' OPENOCD=openocd echo $FILE; if [ -f $FILE]; then echo No ELF file found...; exit fi #lpcfixchecksum takes only binary files, so #make a binary file from the elf, and fix the checksum. arm-eabi-objcopy -O binary $FILE tmp.bin lpcfixchecksum tmp.bin $OPENOCD -f ./openocd.cfg -c init -c reset run -c mwb 0x400FC040 0x01 -c halt -c flash write_image erase unlock tmp.bin 0x0 bin -c reset run -c mwb 0x400FC040 0x01 -c exit $OPENOCD -f ./openocd.cfg -c init -c reset run -c mwb 0x400FC040 0x01 -c halt -c flash write_image erase unlock tmp.bin 0x0 bin -c reset run -c mwb 0x400FC040 0x01 -c exit rm tmp.bin play /usr/share/sounds/ubuntu/stereo/bell.ogg -q ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Only every second programming works
W dniu 2011-10-19 14:14:11 użytkownik Akos Vandra axo...@gmail.com napisał: #lpcfixchecksum takes only binary files, so #make a binary file from the elf, and fix the checksum. arm-eabi-objcopy -O binary $FILE tmp.bin lpcfixchecksum tmp.bin On LPC2xxx you can use elf, hex of bin - no need to convert anything. -c reset run -c mwb 0x400FC040 0x01 How do you expect to write anything to memory when chip is running? 99% of problems in OpenOCD are solved by using reset halt only. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Only every second programming works
Hi guys! I am trying to program an lpc1768 device using an oocdlink (Ft2232-based) programmer. Only every other programming works, which is very strange. After the first programming, the uC seems to be in a lockup state. After second programming, it always works as a charm. I'm pretty much sure the problem is with my program script, but can anyone please help me out with this? Regards, Ákos Vandra my openocd.cfg: debug_level 1 source [find interface/oocdlink.cfg] source [find target/lpc1768.cfg] jtag_khz 200 my programming script: akos at FM12BQ https://lists.berlios.de/mailman/listinfo/openocd-development:~/projects/ARM/falcoeye/Debug$ cat `which burnjtag` #!/bin/sh FILE=`ls *.elf`; #OPENOCD='/home/akos/Downloads/openocd-0.5.0/src/openocd -s /home/akos/Downloads/openocd-0.5.0/tcl' OPENOCD=openocd echo $FILE; if [ -f $FILE]; then echo No ELF file found...; exit fi #lpcfixchecksum takes only binary files, so #make a binary file from the elf, and fix the checksum. arm-eabi-objcopy -O binary $FILE tmp.bin lpcfixchecksum tmp.bin $OPENOCD -f ./openocd.cfg -c init -c reset run -c mwb 0x400FC040 0x01 -c halt -c flash write_image erase unlock tmp.bin 0x0 bin -c reset run -c mwb 0x400FC040 0x01 -c exit $OPENOCD -f ./openocd.cfg -c init -c reset run -c mwb 0x400FC040 0x01 -c halt -c flash write_image erase unlock tmp.bin 0x0 bin -c reset run -c mwb 0x400FC040 0x01 -c exit rm tmp.bin play /usr/share/sounds/ubuntu/stereo/bell.ogg -q first prog. from a blank device, or first prog. just after connecting your debugger / programmer to your device ? That's not the same ? Laurent http://www.amontec.com/ Amontec JTAGkey-2 : High speed USB JTAG interface ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] uploading patches without ssh to Gerrit
Øyvind Harboe wrote: Is there a way to upload patches to Gerrit w/o ssh? You can also use HTTP once you have configured a password at http://openocd.zylin.com/#settings,http-password See notes on http://www.coreboot.org/Git#Accessing_the_repository //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Building OpenOCD for Windows
Moin, Could someone give me a pointer on how to build current git HEAD on windows? None of the howtos on the net i've tried worked. Each and everyone failed at some point with errors that are out of my league (linking errors, libtool errors etc). Alternatively, i wouldnt mind if someone could provide me with a binary. I'd pay with swiss chocolate :-) 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building OpenOCD for Windows
Attila Kinali wrote: Could someone give me a pointer on how to build current git HEAD on windows? None of the howtos on the net i've tried worked. Each and everyone failed at some point with errors that are out of my league (linking errors, libtool errors etc). Post the actual errors and you may be able to get help. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
Well, the ARM-JTAG-EW is not an FT2232 device as far as I can tell -- it's supposed to be a JLink clone for IAR. I guess the answer is no then. Looks like the right thing is to get a real JLink. Thanks anyway! On Tue, Oct 18, 2011 at 1:52 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Tue, Oct 18, 2011 at 2:47 AM, Michael Ashton d...@gtf.org wrote: Hi, I'm wondering if anyone can say whether it's possible, or might ever be possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD? I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure whether that really means anything. thanks! --Michael Driver is generic for FT2232 devices, you can play with some resistor/diode to make JTAG interface work as SWD :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- Quidquid latine dictum sit, altum viditur. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
Well, the ARM-JTAG-EW is not an FT2232 device as far as I can tell -- it's supposed to be a JLink clone for IAR. I guess the answer is no then. Looks like the right thing is to get a real JLink. Thanks anyway! On Tue, Oct 18, 2011 at 1:52 AM, Tomek CEDROtomek.cedro at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / On Tue, Oct 18, 2011 at 2:47 AM, Michael Ashtondata at gtf.org https://lists.berlios.de/mailman/listinfo/openocd-development wrote: //Hi, //I'm wondering if anyone can say whether it's possible, or might ever be //possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD? //I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure // whether //that really means anything. //thanks! --Michael // // Driver is generic for FT2232 devices, you can play with some // resistor/diode to make JTAG interface work as SWD :-) // // -- // CeDeROM, SQ7MHZ,http://www.tomek.cedro.info / certainly olime waits on Segger JLINK SWD implementation in openocd to let say their arm jtag ew has swd certainly olime waits on Amontec JTAGkey-3 SWD implementation in openocd to let say their 2232 has swd ... Regards, Laurent http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] unsubscribe
___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Unused variables
Nothing to comment here - pretty straightforward.
4\/3!!
From 39cb927737d653db8610fce8001aa98e8b256451 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 19 Oct 2011 17:55:33 +0200
Subject: [PATCH] Unused variables
Fix a few errors with set and unused variables detected by GCC 4.7.0
---
src/target/armv7a.c | 10 +-
src/target/cortex_a.c |2 +-
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/src/target/armv7a.c b/src/target/armv7a.c
index e0d0882..0bac27f 100644
--- a/src/target/armv7a.c
+++ b/src/target/armv7a.c
@@ -129,7 +129,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
uint32_t first_lvl_descriptor = 0x0;
uint32_t second_lvl_descriptor = 0x0;
int retval;
- uint32_t cb;
struct armv7a_common *armv7a = target_to_armv7a(target);
struct arm_dpm *dpm = armv7a-armv4_5_common.dpm;
uint32_t ttb = 0; /* default ttb0 */
@@ -168,7 +167,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
if ((first_lvl_descriptor 0x3) == 2)
{
/* section descriptor */
- cb = (first_lvl_descriptor 0xc) 2;
*val = (first_lvl_descriptor 0xfff0) | (va 0x000f);
return ERROR_OK;
}
@@ -203,9 +201,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
return ERROR_TARGET_TRANSLATION_FAULT;
}
- /* cacheable/bufferable is always specified in bits 3-2 */
- cb = (second_lvl_descriptor 0xc) 2;
-
if ((second_lvl_descriptor 0x3) == 1)
{
/* large page descriptor */
@@ -243,7 +238,7 @@ int armv7a_mmu_translate_va_pa(struct target *target,
uint32_t va,
struct armv7a_common *armv7a = target_to_armv7a(target);
struct arm_dpm *dpm = armv7a-armv4_5_common.dpm;
uint32_t virt = va ~0xfff;
- uint32_t NOS,NS,SH,INNER,OUTER;
+ uint32_t NOS,NS,INNER,OUTER;
*val = 0xdeadbeef;
retval = dpm-prepare(dpm);
if (retval != ERROR_OK)
@@ -260,7 +255,6 @@ int armv7a_mmu_translate_va_pa(struct target *target,
uint32_t va,
/* decode memory attribute */
NOS = (*val 10) 1; /* Not Outer shareable */
NS = (*val 9) 1; /* Non secure */
- SH = (*val 7 ) 1; /* shareable */
INNER = (*val 4) 0x7;
OUTER = (*val 2) 0x3;
@@ -726,7 +720,6 @@ done:
int armv7a_init_arch_info(struct target *target, struct armv7a_common *armv7a)
{
- struct armv7a_common *again;
struct arm *armv4_5 = armv7a-armv4_5_common;
armv4_5-arch_info = armv7a;
target-arch_info = armv7a-armv4_5_common;
@@ -738,7 +731,6 @@ int armv7a_init_arch_info(struct target *target, struct
armv7a_common *armv7a)
armv7a-armv7a_mmu.armv7a_cache.ctype = -1;
armv7a-armv7a_mmu.armv7a_cache.flush_all_data_cache = NULL;
armv7a-armv7a_mmu.armv7a_cache.display_cache_info = NULL;
-again =target_to_armv7a(target);
return ERROR_OK;
}
diff --git a/src/target/cortex_a.c b/src/target/cortex_a.c
index 7547f17..2370d95 100755
--- a/src/target/cortex_a.c
+++ b/src/target/cortex_a.c
@@ -92,7 +92,7 @@ static int cortex_a8_restore_cp15_control_reg(struct target*
target)
1, 0, /* CRn, CRm */
cortex_a8-cp15_control_reg);
}
- return ERROR_OK;
+ return retval;
}
/* check address before cortex_a8_apb read write access with mmu on
--
1.7.4.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
You're right -- my mistake. The web page says: ARM-JTAG-EW emulates on low level the IAR Systems' J-LINK API so it works like normal J-LINK debugger, ... I took this to mean that they were emulating the USB protocol. But a footnote in the manual says -- DLL compatible means that we supply our own jlinkarm.dll. The original IAR-EW DLL will not work with the ARM-JTAG-EW device because ARM-JTAG-EW and IAR J-Link use different USB protocols. So that explains that then. The Olimex manual mentions SWD in the pinout table, so perhaps they have the necessary hardware already. Might give it a shot with libswd but I need to get moving on this project .. On Wed, Oct 19, 2011 at 8:52 AM, jim norris u17...@att.net wrote: Well, the ARM-JTAG-EW is not an FT2232 device as far as I can tell -- it's supposed to be a JLink clone for IAR Yes it is. It has an FT2232D chip in. If you open it up (and void the warranty!) you can see it. However, using the ARM-JTAG-EW to do SWD is not just a software change. As Tomek implied in the previous email, one needs to understand the pinouts. JTAG typically uses 5 pins, while SWD uses 2 pins. So there are some hardware ramifications when using a FT2232 device for SWD versus JTAG as typically found in most debuggers. -- Quidquid latine dictum sit, altum viditur. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
Please read HACKING and post to Gerrit. 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] [PATCH] Unused variables
On 2011-10-19 19:50, Øyvind Harboe wrote: Please read HACKING and post to Gerrit. Sorry, I don't have time to do so because: 1. The patch is trivial 2. I use git in Linux hosted in VitualBox, where emailing patches kinda does not work 3. My knowledge of Linux and Git is minimal So basically I can say that Gerrit posting would NOT work in my environment without some serious effort, while you can just accept that trivial patch or post it there in two seconds. I have got a lot on my head now and no time to spare. Make Gerrit accept patches via web interface (I see no reason why it shouldn't allow to do so as it's web based) and I'll be happy to post anything there - now it's just like a stone wall for me with milions of steps required to send a patch once a year. For me - a user who sometimes patches simple stuff or adds config files - Gerrit is an obstacle, nothing more. Sorry for the inconvenience. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
If you don't have time to work on OpenOCD, then I don't have any problems with that. The world is full of smart people who could have, but don't have time to, contribute to OpenOCD. If you do want to spend some time on OpenOCD, then I urge you to have a look at what Gerrit+Jenkins does for the community. Some of the things that Gerrit+Jenkins does for us: - Contributors, rather than maintainers will do all the work of formulating patches and serving them on a silver platter to the maintainers. - Jenkins will build and check your patch for warnings. If you generate warnings in some of the configurations that Jenkins checks for, you will get an email w/info about that. No other humans will waste time on your patch before it is ready and clean of all nits(warnings, whitespace errors, etc.). - It makes it possible for us to organise the patches, keep track of improved version of patches, etc. and decide when to submit them to the repository with a click of a button. I don't think the maintainers will be accepting or reviewing patches that are not submitted to Gerrit anymore. If this means that we loose those contributors who can't or won't take time time to learn Git and how to configure and us Gerrit, then that's really a non-issue, because maintainers are not going to spend their time to save the contributors this effort. -- Ø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] clang static analyzer
On 10/19/2011 03:51 AM, Jon Povey wrote: openocd-development-boun...@lists.berlios.de wrote: I'd like to see patches having to pass clang static analyzer unscathed before they're ready for review :-) I had a quick look at that output, interesting. Some looked like real bugs, but others it seems clang was getting it wrong.. like if (ptr == NULL) checks which it thought failed, but then it complained about a null ptr dereference. It seemed to get if (!ptr) right though, which I think is preferred linux kernel style. There are some other issues which might make passing the static analyzer be a bad prerequisite for patches. See Important Points to Consider, here: http://clang-analyzer.llvm.org/index.html In short, it's very slow (took over an hour to get through with OpenOCD on my machine), and it's susceptible to false positives. Best, Marti ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: d889fd9 Unused variables
This is an automated email from Gerrit.
Freddie Chopin (freddie.cho...@gmail.com) just uploaded a new patch set to
Gerrit, which you can find at http://openocd.zylin.com/36
-- gerrit
commit d889fd9c01e8e1bc4af31141f126c44c3f26bca9
Author: Freddie Chopin freddie.cho...@gmail.com
Date: Wed Oct 19 21:40:48 2011 +0200
Unused variables
Fix a few errors with set and unused variables detected by GCC 4.7.0
Change-Id: I59b748e18e514ee9f0cde7883b4ed5116198bd4a
Signed-off-by: Freddie Chopin freddie.cho...@gmail.com
diff --git a/src/target/armv7a.c b/src/target/armv7a.c
index e0d0882..0bac27f 100644
--- a/src/target/armv7a.c
+++ b/src/target/armv7a.c
@@ -129,7 +129,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
uint32_t first_lvl_descriptor = 0x0;
uint32_t second_lvl_descriptor = 0x0;
int retval;
- uint32_t cb;
struct armv7a_common *armv7a = target_to_armv7a(target);
struct arm_dpm *dpm = armv7a-armv4_5_common.dpm;
uint32_t ttb = 0; /* default ttb0 */
@@ -168,7 +167,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
if ((first_lvl_descriptor 0x3) == 2)
{
/* section descriptor */
- cb = (first_lvl_descriptor 0xc) 2;
*val = (first_lvl_descriptor 0xfff0) | (va 0x000f);
return ERROR_OK;
}
@@ -203,9 +201,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
return ERROR_TARGET_TRANSLATION_FAULT;
}
- /* cacheable/bufferable is always specified in bits 3-2 */
- cb = (second_lvl_descriptor 0xc) 2;
-
if ((second_lvl_descriptor 0x3) == 1)
{
/* large page descriptor */
@@ -243,7 +238,7 @@ int armv7a_mmu_translate_va_pa(struct target *target,
uint32_t va,
struct armv7a_common *armv7a = target_to_armv7a(target);
struct arm_dpm *dpm = armv7a-armv4_5_common.dpm;
uint32_t virt = va ~0xfff;
- uint32_t NOS,NS,SH,INNER,OUTER;
+ uint32_t NOS,NS,INNER,OUTER;
*val = 0xdeadbeef;
retval = dpm-prepare(dpm);
if (retval != ERROR_OK)
@@ -260,7 +255,6 @@ int armv7a_mmu_translate_va_pa(struct target *target,
uint32_t va,
/* decode memory attribute */
NOS = (*val 10) 1; /* Not Outer shareable */
NS = (*val 9) 1; /* Non secure */
- SH = (*val 7 ) 1; /* shareable */
INNER = (*val 4) 0x7;
OUTER = (*val 2) 0x3;
@@ -726,7 +720,6 @@ done:
int armv7a_init_arch_info(struct target *target, struct armv7a_common *armv7a)
{
- struct armv7a_common *again;
struct arm *armv4_5 = armv7a-armv4_5_common;
armv4_5-arch_info = armv7a;
target-arch_info = armv7a-armv4_5_common;
@@ -738,7 +731,6 @@ int armv7a_init_arch_info(struct target *target, struct
armv7a_common *armv7a)
armv7a-armv7a_mmu.armv7a_cache.ctype = -1;
armv7a-armv7a_mmu.armv7a_cache.flush_all_data_cache = NULL;
armv7a-armv7a_mmu.armv7a_cache.display_cache_info = NULL;
-again =target_to_armv7a(target);
return ERROR_OK;
}
diff --git a/src/target/cortex_a.c b/src/target/cortex_a.c
index 7547f17..2370d95 100755
--- a/src/target/cortex_a.c
+++ b/src/target/cortex_a.c
@@ -92,7 +92,7 @@ static int cortex_a8_restore_cp15_control_reg(struct target*
target)
1, 0, /* CRn, CRm */
cortex_a8-cp15_control_reg);
}
- return ERROR_OK;
+ return retval;
}
/* check address before cortex_a8_apb read write access with mmu on
--
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clang static analyzer
http://clang-analyzer.llvm.org/index.html In short, it's very slow (took over an hour to get through with OpenOCD on my machine), and it's susceptible to false positives. An hour is not the biggest problem if it saves a bunch of maintainer time. Can we choose some minimum threshold for what we'll accept in terms of errors like we do for gcc(-Werror -Wall is minimum acceptable for patches now). -- Ø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] Remove qP from rtos code?
Sorry for bringing this old thread up (no pun intended). This code got a few minutes of my attention after I browsed through the clang static analysis report someone posted recently. rtos.c was one of the first in the list, and while the bug report probably was a false positive, I noticed some serious problems with this code. To be honest, I can't see how it could work at all. The mode variable is repeatedly bit manipulated in ways that can hardly leave any bits set at all. Further, the reply string is repeatedly written over so the reply will probably be nonsense, or at least not what gdb asked for. If this code actually does something useful, please stop me, otherwise I'll simply purge the qP code from rtos.c. /Andreas On Sat, Aug 27, 2011 at 5:01 PM, Jie Zhang jzhang...@gmail.com wrote: Hi Evan, If qThreadExtraInfo is not implemented, qP will be used. But since qThreadExtraInfo has now been implemented, qP should not be needed any more. GDB added qThreadExtraInfo more than 10 years ago. All GDB releases since 5.0 will not send out qP packet if the stub supports qThreadExtraInfo. So I think it's safe for OpenOCD to remove qP support and only keep qThreadExtraInfo. This will make code clean and reduce maintenance effort. Regards, Jie On Thu, Aug 25, 2011 at 8:50 PM, Evan Hunter e...@ozhiker.com wrote: Backward compatibility is the reason - When I was testing with GDB+eclipse I found that OpenOCD received qP packets sometimes, and I think I implemented it first, before reading that same quotation you mentioned. Then when I implemented qThreadExtraInfo, I figured it was nicer to keep qP compatibility too. Regards, Evan Quoting Jie Zhang jzhang...@gmail.com: Hi Evan, GDB manual says about qP: Don't use this packet; use the `qThreadExtraInfo' query instead (see below). Since qThreadExtraInfo is already supported in rtos.c, why qP is still needed? Regards, Jie ___ 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 mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: 4d01a6e rtos: return the correct value if the T or H packets are handled
This is an automated email from Gerrit.
Andreas Fritiofson (andreas.fritiof...@gmail.com) just uploaded a new patch set
to Gerrit, which you can find at http://openocd.zylin.com/38
-- gerrit
commit 4d01a6eafd90b6b0af2ad205c55d87ef66df15ce
Author: Andreas Fritiofson andreas.fritiof...@gmail.com
Date: Thu Oct 20 00:25:08 2011 +0200
rtos: return the correct value if the T or H packets are handled
Change-Id: Iea31e20ee4e35c1a9cb7b93424c92b3f38081067
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
diff --git a/src/rtos/rtos.c b/src/rtos/rtos.c
index 73e2d29..8a59fd3 100644
--- a/src/rtos/rtos.c
+++ b/src/rtos/rtos.c
@@ -406,6 +406,7 @@ int gdb_thread_packet(struct connection *connection, char
*packet, int packet_si
} else {
gdb_put_packet(connection, E01, 3); // thread not
found
}
+ return ERROR_OK;
}
else if ( packet[0] == 'H') // Set current thread ( 'c' for step and
continue, 'g' for all other operations )
{
@@ -414,6 +415,7 @@ int gdb_thread_packet(struct connection *connection, char
*packet, int packet_si
sscanf(packet, Hg%16 SCNx64, current_threadid);
}
gdb_put_packet(connection, OK, 2);
+ return ERROR_OK;
}
return GDB_THREAD_PACKET_NOT_CONSUMED;
--
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch to review for openocd: a2b8874 rtos: remove broken code for handling the deprecated qP packet
This is an automated email from Gerrit.
Andreas Fritiofson (andreas.fritiof...@gmail.com) just uploaded a new patch set
to Gerrit, which you can find at http://openocd.zylin.com/37
-- gerrit
commit a2b8874f55b71a6318fa9447193d62231c53da9a
Author: Andreas Fritiofson andreas.fritiof...@gmail.com
Date: Thu Oct 20 00:21:33 2011 +0200
rtos: remove broken code for handling the deprecated qP packet
Change-Id: Icca522c1e2a2877abb20665b171c61079b1d8f48
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
diff --git a/src/rtos/rtos.c b/src/rtos/rtos.c
index 74e8724..73e2d29 100644
--- a/src/rtos/rtos.c
+++ b/src/rtos/rtos.c
@@ -132,91 +132,7 @@ int gdb_thread_packet(struct connection *connection, char
*packet, int packet_si
{
struct target *target = get_target_from_connection(connection);
- if (strstr(packet, qP))
- {
- #define TAG_THREADID 1 /* Echo the thread identifier */
- #define TAG_EXISTS 2/* Is this process defined
enough to
- fetch registers and its
stack */
- #define TAG_DISPLAY 4 /* A short thing maybe to put
on a window */
- #define TAG_THREADNAME 8/* string, maps 1-to-1 with a
thread is */
- #define TAG_MOREDISPLAY 16 /* Whatever the kernel wants to
say about */
-
- // TODO: need to scanf the mode variable (or it with
the tags), and the threadid
-
- unsigned long mode;
- threadid_t threadid = 0;
- struct thread_detail* detail;
- sscanf(packet, qP%8lx%16 SCNx64, mode, threadid);
-
-
- int found = -1;
-
- if ((target-rtos != NULL) (target-rtos-thread_details
- != NULL)) {
- int thread_num;
- for (thread_num = 0; thread_num
-target-rtos-thread_count;
thread_num++) {
- if
(target-rtos-thread_details[thread_num].threadid
- == threadid) {
- if
(target-rtos-thread_details[thread_num].exists) {
- found = thread_num;
- }
- }
- }
- }
- if (found == -1) {
- gdb_put_packet(connection, E01, 3); // thread not
found
- return ERROR_OK;
- }
-
- detail = target-rtos-thread_details[found];
-
- if ( detail-display_str != NULL )
- {
- mode = TAG_DISPLAY;
- }
- if ( detail-thread_name_str != NULL )
- {
- mode = TAG_THREADNAME;
- }
- if ( detail-extra_info_str != NULL )
- {
- mode = TAG_MOREDISPLAY;
- }
-
-
- mode = TAG_THREADID | TAG_EXISTS;
-
- char thread_str[1000];
-
- sprintf(thread_str, %08lx, mode);
- sprintf(thread_str, %016 PRIx64, threadid);
-
-
- if (mode TAG_THREADID) {
- sprintf(thread_str, %08 PRIx32 10%016 PRIx64,
TAG_THREADID, threadid);
- }
- if (mode TAG_EXISTS) {
- sprintf(thread_str, %08 PRIx32 08%08 PRIx32,
TAG_EXISTS, (detail-exists==true)?1:0);
- }
- if (mode TAG_DISPLAY) {
- sprintf(thread_str, %08 PRIx32 %02x%s, TAG_DISPLAY,
(unsigned char)strlen(detail-display_str), detail-display_str );
- }
- if (mode TAG_MOREDISPLAY) {
- sprintf(thread_str, %08 PRIx32 %02x%s,
TAG_MOREDISPLAY, (unsigned char)strlen(detail-extra_info_str),
detail-extra_info_str );
- }
- if (mode TAG_THREADNAME) {
- sprintf(thread_str, %08 PRIx32 %02x%s,
TAG_THREADNAME, (unsigned char)strlen(detail-thread_name_str),
detail-thread_name_str );
- }
-
- //gdb_put_packet(connection, tmpstr, sizeof(tmpstr)-1);
- gdb_put_packet(connection, thread_str, strlen(thread_str));
-
- // gdb_put_packet(connection, , 0);
- // gdb_put_packet(connection, OK, 2); // all
threads alive
- return ERROR_OK;
- }
- else if (strstr(packet, qThreadExtraInfo,))
+ if (strstr(packet, qThreadExtraInfo,))
{
if ((target-rtos != NULL) (target-rtos-thread_details !=
NULL) (target-rtos-thread_count != 0))
{
--
___
Openocd-development mailing list
Re: [Openocd-development] Remove qP from rtos code?
Hi Andreas, You are right - Looking at it again, the qP code looks like I got halfway through implementing it, then found that I should be using qThreadExtraInfo instead. Please feel free to remove it. The only reason I haven't already is that I've not had time. Regards, Evan From: andr...@fritiofson.net [mailto:andr...@fritiofson.net] On Behalf Of Andreas Fritiofson Sent: Thursday, 20 October 2011 9:13 AM To: Jie Zhang Cc: Evan Hunter; Evan Hunter; openocd-development Subject: Re: [Openocd-development] Remove qP from rtos code? Sorry for bringing this old thread up (no pun intended). This code got a few minutes of my attention after I browsed through the clang static analysis report someone posted recently. rtos.c was one of the first in the list, and while the bug report probably was a false positive, I noticed some serious problems with this code. To be honest, I can't see how it could work at all. The mode variable is repeatedly bit manipulated in ways that can hardly leave any bits set at all. Further, the reply string is repeatedly written over so the reply will probably be nonsense, or at least not what gdb asked for. If this code actually does something useful, please stop me, otherwise I'll simply purge the qP code from rtos.c. /Andreas On Sat, Aug 27, 2011 at 5:01 PM, Jie Zhang jzhang...@gmail.commailto:jzhang...@gmail.com wrote: Hi Evan, If qThreadExtraInfo is not implemented, qP will be used. But since qThreadExtraInfo has now been implemented, qP should not be needed any more. GDB added qThreadExtraInfo more than 10 years ago. All GDB releases since 5.0 will not send out qP packet if the stub supports qThreadExtraInfo. So I think it's safe for OpenOCD to remove qP support and only keep qThreadExtraInfo. This will make code clean and reduce maintenance effort. Regards, Jie On Thu, Aug 25, 2011 at 8:50 PM, Evan Hunter e...@ozhiker.commailto:e...@ozhiker.com wrote: Backward compatibility is the reason - When I was testing with GDB+eclipse I found that OpenOCD received qP packets sometimes, and I think I implemented it first, before reading that same quotation you mentioned. Then when I implemented qThreadExtraInfo, I figured it was nicer to keep qP compatibility too. Regards, Evan Quoting Jie Zhang jzhang...@gmail.commailto:jzhang...@gmail.com: Hi Evan, GDB manual says about qP: Don't use this packet; use the `qThreadExtraInfo' query instead (see below). Since qThreadExtraInfo is already supported in rtos.c, why qP is still needed? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.demailto:Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.demailto: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] Remove qP from rtos code?
Hi! On Thu, Oct 20, 2011 at 12:47 AM, Evan Hunter ehun...@broadcom.com wrote: You are right – Looking at it again, the “qP” code looks like I got halfway through implementing it, then found that I should be using qThreadExtraInfo instead. Please feel free to remove it. The only reason I haven’t already is that I’ve not had time. ** Ok, will do. Since you're familiar with the code, could you comment on the return value patch I just posted ( http://openocd.zylin.com/38 ). I'm just guessing here but it seems reasonable enough. Thanks, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Only every second programming works
On Wed, Oct 19, 2011 at 2:23 PM, freddie_chopin freddie_cho...@op.plwrote: W dniu 2011-10-19 14:14:11 użytkownik Akos Vandra axo...@gmail.com napisał: #lpcfixchecksum takes only binary files, so #make a binary file from the elf, and fix the checksum. arm-eabi-objcopy -O binary $FILE tmp.bin lpcfixchecksum tmp.bin On LPC2xxx you can use elf, hex of bin - no need to convert anything. Actually, that's true for all targets. -c reset run -c mwb 0x400FC040 0x01 How do you expect to write anything to memory when chip is running? 99% of problems in OpenOCD are solved by using reset halt only. LPC17xx is Cortex-M3, right? Then it shouldn't have any problems with writing to memory with the core running. But what is the mwb 0x400FC040 0x01 doing? Perhaps it's better placed in the reset init handler and doing reset init instead. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building OpenOCD for Windows
Freddie Chopin wrote: I guess it's right time for me to provide a new development version on my website... Maybe you can also describe how you build them? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Change in openocd[master]: jlink libusb1 driver with libusb1 common driver interface.
Spencer Oliver wrote: http://openocd.zylin.com/33 adds libusb-1.0 support to the jlink. Just wondering if anyone had any input on this ? Yes, plenty. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
Michael Ashton wrote: On Wed, Oct 19, 2011 at 8:56 AM, Laurent Gauch wrote: certainly olime waits on Segger JLINK SWD implementation in openocd to let say their arm jtag ew has swd certainly olime waits on Amontec JTAGkey-3 SWD implementation in openocd to let say their 2232 has swd ... Ha .. I see .. cheeky of them .. Well, I'm sending it back. --mpa Don't listen too much to Laurent's complaints. Of course he will be unhappy with competition. It might be really easy to make the device speak SWD. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge pe...@stuge.se wrote: It might be really easy to make the device speak SWD. Devices already speaking SWD for some time, need some small support in Target implementation :-) -- 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] arm-jtag-ew + swd
On Thu, Oct 20, 2011 at 1:52 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge pe...@stuge.se wrote: It might be really easy to make the device speak SWD. JLink specification is open, from what Ive seen it should be relatively easy to implement generic (tranfer/bitbang functions) driver for this device :-) -- 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] [PATCH] Unused variables
Freddie Chopin wrote: Please read HACKING and post to Gerrit. I second this. Sorry, I don't have time to do so because: Sorry, noone has time to deal with your patch. 1. The patch is trivial It might seem so, but actually it's not. It has multiple logical changes combined in a single commit, which is no good. Please separate the return error into it's own commit, with it's own clear commit message about how and why. 2. I use git in Linux hosted in VitualBox, where emailing patches kinda does not work Øyvind could have written push instead of post, since commits go to Gerrit using git push, and not email. It's clear that you misunderstood this, and it's clear that you didn't even look into how commits would be sent to Gerrit, before arguing that you do not have time to do so because it is too complicated. Your VM needs network access. I guess it has that. On another note, it's absolutely not neccessary for you to work with OpenOCD source code in any particular operating system. If your prefered environment is Windows then Git can perform line ending translation for you, allowing you to use any Windows tools to work with any project codebase. 3. My knowledge of Linux and Git is minimal That's not a problem. If your willingness to gain knowledge of Git is also minimal, *that* is a big problem, since you can notwork efficiently within the project then. Perhaps you realize that learning a little about Git makes a huge difference in productivity. It's of course impossible to discuss this with someone if they have already decided that they hate Git (you might be surprised how common this is) or that they otherwise don't want to learn the tool. I would see OpenOCD as an opportunity to learn more about Git, and I would be happy that I took the opportunity, since I can benefit from it also outside of OpenOCD. If you run into trouble then please do ask - there are several on the mailing list who are happy to help. So basically I can say that Gerrit posting would NOT work in my environment without some serious effort, The effort in all it's seriousness is documented in HACKING. But here are the steps again, summarized for your convenience: * acquiring any OpenID account (let me know if you can't get one) * registering on the Gerrit website * configuring a username on Gerrit website * (optional) uploading a public ssh key on Gerrit website * adding the commit hook in your local repo * re-committing your change (to get the Change-Id) * git config remote.origin.url with ssh or http URL to Gerrit * git push The next time you've made a commit you run git push again, to send commit(s) to Gerrit. I am confident that this is quite significantly simpler than whatever workflow you currently use with patch files and email software. while you can just accept that trivial patch or post it there in two seconds. Except that you can not get feedback then. Since it is your patch it is you who needs to push it to Gerrit. I have got a lot on my head now and no time to spare. Yeah, it takes time to learn tools, but Gerrit is really not your enemy. Make Gerrit accept patches via web interface (I see no reason why it shouldn't allow to do so as it's web based) IMO that would be stupid. You already have the commit in Git, so it is really impossible to have a simpler interface than git push. and I'll be happy to post anything there - now it's just like a stone wall for me with milions of steps required See above, and HACKING, for the million steps that are required. to send a patch once a year. Next year you do it with one command. Since your VM can not send email I know that you are not using git send-email, which would be similarly simple as git push to Gerrit; you must be creating patch files, and sending them manually in email. This is not efficient. There's really no reason to be inefficient about something, even if you only do it once a year, especially when the knowledge that allows you to work more efficiently can benefit you for a whole year in between. For me - a user who sometimes patches simple stuff or adds config files - Gerrit is an obstacle, nothing more. I think you should look at how Gerrit actually works, and re-evaluate your position. Of course, being required to even think about a new tool is a slight inconvenience for a new contributor, but hopefully you can help document the process, or suggest simplifications, instead of only complaining about how difficult it is before you have any experience. On the flip side, the value of Gerrit is significant. Commits can very quickly and easily come into Gerrit and go out of Gerrit into the public openocd.git repo. (You may have noticed the command line interface via SSH that Gerrit offers.) It's also very easy to make detailed comments on commits. Øyvind mentioned that Gerrit also brings a bit of quality assurance, for free, without human interaction. The slight added inconvenience is instantly amortized by the
Re: [Openocd-development] Only every second programming works
Andreas Fritiofson wrote: But what is the mwb 0x400FC040 0x01 doing? MEMMAP Bit 0 MAP Reset value 0 0 Boot mode. A portion of the Boot ROM is mapped to address 0. 1 User mode. The on-chip Flash memory is mapped to address 0. 6. Debug memory re-mapping - Following chip reset, a portion of the Boot ROM is mapped to address 0 so that it will be automatically executed. The Boot ROM switches the map to point to Flash memory prior to user code being executed. In this way a user normally does not need to know that this re-mapping occurs. However, when a debugger halts CPU execution immediately following reset, the Boot ROM is still mapped to address 0 and can cause confusion. Ideally, the debugger should correct the mapping automatically in this case, so that a user does not need to deal with it. So yes indeed this should be taken care of in openocd. And it should be the default. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
On Wed, Oct 19, 2011 at 4:53 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Oct 20, 2011 at 1:52 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge pe...@stuge.se wrote: It might be really easy to make the device speak SWD. JLink specification is open, from what Ive seen it should be relatively easy to implement generic (tranfer/bitbang functions) driver for this device :-) I noticed that too. Segger's GDB server is Windows-only, which can be inconvenient. Their documentation for their USB protocol looks very complete. -- Quidquid latine dictum sit, altum viditur. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
On Wed, Oct 19, 2011 at 4:49 PM, Peter Stuge pe...@stuge.se wrote: Michael Ashton wrote: On Wed, Oct 19, 2011 at 8:56 AM, Laurent Gauch wrote: certainly olime waits on Segger JLINK SWD implementation in openocd to let say their arm jtag ew has swd certainly olime waits on Amontec JTAGkey-3 SWD implementation in openocd to let say their 2232 has swd ... Ha .. I see .. cheeky of them .. Well, I'm sending it back. --mpa Don't listen too much to Laurent's complaints. Of course he will be unhappy with competition. Which is certainly understandable :) It might be really easy to make the device speak SWD. Might be, but I needed to get something working quickly and reliably -- it's a commercial project. --mpa ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
On Thu, Oct 20, 2011 at 11:54 AM, Michael Ashton d...@gtf.org wrote: JLink specification is open, from what Ive seen it should be relatively easy to implement generic (tranfer/bitbang functions) driver for this device :-) I noticed that too. Segger's GDB server is Windows-only, which can be inconvenient. Their documentation for their USB protocol looks very complete. Once you start to work with J-Link, you will know how incomplete it is. The main issue is that there are many different versions of J-Link with a bit different in the behaviour. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
openocd-development-boun...@lists.berlios.de wrote: If you don't have time to work on OpenOCD, then I don't have any problems with that. The world is full of smart people who could have, but don't have time to, contribute to OpenOCD. [...] If this means that we loose those contributors who can't or won't take time time to learn Git and how to configure and us Gerrit, then that's really a non-issue, because maintainers are not going to spend their time to save the contributors this effort. This is an interesting point of view. I have no doubt that gerrit makes life easier for the maintainers, but there is the barrier of new thing to learn and setup hassle for a new contributor, vs the old system used by many projects of sending patches to a mailing list. You will lose some valuable contributions and contributors because of this. Also the apparent attitude of screw you, we don't care if it's hard, it makes our life easy is offputting. I have a few patches in OpenOCD and one bug I found the other day that I was thinking about working on and sending a patch for. But honestly, having to set up for gerrit workflow makes me less likely to do either. If OpenOCD suffers from a lack of maintainer time and effort but is overrun with enthusastic contributors, then the gerrit thing seems like a good idea. If on the other hand the maintainers are active and keen to encourage new contributors, and the project is suffering from lack of contributor effort, then it seems like it will not be good for project health. I suspect the truth lies somewhere between the two. This is intended to be an objective bit of third-party insight, I am not anti-gerrit - it seems like a nice tool. certainly I am a fan of CI. I apprecite OpenOCD, I'd like to see the project grow in scope and maturity, but this additional barrier to contributing does put me and others off contributing in future. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
Michael Ashton wrote: It might be really easy to make the device speak SWD. Might be, but I needed to get something working quickly and reliably -- it's a commercial project. --mpa I guess you already know that SWD support in OpenOCD is not so complete. If you still want to try to use OpenOCD with SWD then there are basically three approaches you can try: 1. Continue what David Brownell worked on for FT2232-based adapters 2. Try Tomek's libswd, which I think works so far primarily with (only some?) FT2232-based adapters 3. Use a Versaloon (e.g. Versaloon Mini, see http://www.versaloon.com/ ) and Simon's patches to OpenOCD I've only done very brief testing with the Versaloon, but what I've tested works perfectly (SWD programming using vsprog, not using OpenOCD - and JTAG using OpenOCD). I'm unfortunately unsure exactly of the current libswd+OpenOCD status. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Change in openocd[master]: jlink libusb1 driver with libusb1 common driver interface.
On Wed, Oct 19, 2011 at 11:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 19 October 2011 16:38, Mauro Gamba maurill...@gmail.com wrote: Sorry for patch errors. I started to patch the jlink driver to use libusb-1 because libusb-0 is not developed further. I haven't done speed tests until now. http://openocd.zylin.com/33 adds libusb-1.0 support to the jlink. Just wondering if anyone had any input on this ? I believe the approach to only uss libusb-1.0 for J-Link is not a good approach. My idea is to have both options, just like urjtag. When libusb-1.0 is available and specified by the user, it should use libusb-1.0, other wise, it will fall back to libusb-0.1. Benefits of providing both: 1) Make the regression testing easier. 2) Make J-Link to work on platforms where libusb-1.0 is not available, like Solaris/NetBSD/OpenBSD, and older version of FreeBSD, and maybe some embedded Linux platform, and Windows 2000. 3) Make users who prefer to use libusb-0.1 can use libusb-0.1, say Windows users who prefer to keep both Segger driver (to use IAR/Keil/etc) and OpenOCD -- they can use libusb-win32 filter driver. Take note libusb-1.0 Windows does not support libusb0.sys backend now and that makes it not working with the filter driver. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Change in openocd[master]: jlink libusb1 driver with libusb1 common driver interface.
On Thu, Oct 20, 2011 at 1:02 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Oct 19, 2011 at 11:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote: http://openocd.zylin.com/33 adds libusb-1.0 support to the jlink. Just wondering if anyone had any input on this ? I believe the approach to only uss libusb-1.0 for J-Link is not a good approach. My idea is to have both options, just like urjtag. When libusb-1.0 is available and specified by the user, it should use libusb-1.0, other wise, it will fall back to libusb-0.1. Benefits of providing both: 1) Make the regression testing easier. 2) Make J-Link to work on platforms where libusb-1.0 is not available, like Solaris/NetBSD/OpenBSD, and older version of FreeBSD, and maybe some embedded Linux platform, and Windows 2000. 3) Make users who prefer to use libusb-0.1 can use libusb-0.1, say Windows users who prefer to keep both Segger driver (to use IAR/Keil/etc) and OpenOCD -- they can use libusb-win32 filter driver. Take note libusb-1.0 Windows does not support libusb0.sys backend now and that makes it not working with the filter driver. Again, I will point the link to urjtag. http://urjtag.git.sourceforge.net/git/gitweb.cgi?p=urjtag/urjtag;a=tree;f=urjtag/src/tap/usbconn;hb=HEAD In terms of the simple wrapper of libusb-1.0, I think this is a good first try. On the other hand, the function jtag_libusb_match() can probably take one more parameter serial_number so that some debuggers can benefits from the support of multiple units. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
Jon Povey wrote: this additional barrier to contributing does put me and others off contributing in future. Using Git is also a barrier for some, perhaps even for many. Gerrit is new, so sure there will be resistance. Maybe sometime it will be just as common as Git itself. I think the learning curve for Git is much steeper than for Gerrit. Please look at the updated HACKING file, or my previous email, for an overview of the quick and simple steps to use Gerrit: You need an OpenID from somewhere (let me know if you want one from me) You need to register on a web page and pick a username You need to set an HTTP password or upload a public SSH key The above takes not two minutes. Once that has been done, git push on your command line or in your GUI sends commits to Gerrit. Setting up Gerrit is a one-time thing, and it allows much quicker workflow for you, other contributors, the reviewers and the maintainers. An interesting fact is that in the project where I've seen Gerrit introduced there were several new contributors sending commits, who had previously never been seen on the mailing list. I was surprised, but in a good way! //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
If you want to spend the time taking other people's patches and pushing them to Gerrit so they don't have to, go right ahead. You do not have to be an OpenOCD maintainer to do this, anyone can push anyones patches to Gerrit for review. I don't expect you to step up to take such a role, nor do I expect anyone else. Really this is the sort of work that you have to pay someone to do or you have to do it yourself. We're starting to gather data that we're getting *more* and *better* patches submitted to the Git repository. We also see that the less active maintainers are now reviewing and submitting to the repository. I'm thinking a bit about how I can draw up some graphs on this... -- Ø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] [PATCH] Unused variables
Øyvind Harboe wrote: I'm thinking a bit about how I can draw up some graphs on this... Graphing number of commits is easy, but graphing the review is difficult. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
