[Openocd-development] Tags
When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] arm11: disable broken optimization for setting current scan chain
---
src/target/arm11_dbgtap.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/target/arm11_dbgtap.c b/src/target/arm11_dbgtap.c
index 5c671cc..c6c5a50 100644
--- a/src/target/arm11_dbgtap.c
+++ b/src/target/arm11_dbgtap.c
@@ -199,11 +199,15 @@ int arm11_add_debug_SCAN_N(struct arm11_common *arm11,
* NOTE: the ITRSEL instruction fakes SCREG changing;
* but leaves its actual value unchanged.
*/
- if (arm11-jtag_info.cur_scan_chain == chain) {
- JTAG_DEBUG(SCREG = %d SKIPPED, chain);
- return jtag_add_statemove((state == ARM11_TAP_DEFAULT)
- ? TAP_DRPAUSE : state);
- }
+ // FIX!!! the optimization below is broken because we do not
+ // invalidate the cur_scan_chain upon a TRST/TMS. See arm_jtag.c
+ // for example on how to invlidate cur_scan_chain. Tested patches gladly
+ // accepted!
+// if (arm11-jtag_info.cur_scan_chain == chain) {
+// JTAG_DEBUG(SCREG = %d SKIPPED, chain);
+// return jtag_add_statemove((state == ARM11_TAP_DEFAULT)
+// ? TAP_DRPAUSE : state);
+// }
JTAG_DEBUG(SCREG = %d, chain);
arm11_add_IR(arm11, ARM11_SCAN_N, ARM11_TAP_DEFAULT);
--
1.7.2.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 07:56, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) Release tags are annotated, and so take priority with git describe. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] arm11: disable broken optimization for setting current scan chain
On 5 August 2011 09:00, Øyvind Harboe oyvind.har...@zylin.com wrote:
---
src/target/arm11_dbgtap.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/target/arm11_dbgtap.c b/src/target/arm11_dbgtap.c
index 5c671cc..c6c5a50 100644
--- a/src/target/arm11_dbgtap.c
+++ b/src/target/arm11_dbgtap.c
@@ -199,11 +199,15 @@ int arm11_add_debug_SCAN_N(struct arm11_common *arm11,
* NOTE: the ITRSEL instruction fakes SCREG changing;
* but leaves its actual value unchanged.
*/
- if (arm11-jtag_info.cur_scan_chain == chain) {
- JTAG_DEBUG(SCREG = %d SKIPPED, chain);
- return jtag_add_statemove((state == ARM11_TAP_DEFAULT)
- ? TAP_DRPAUSE : state);
- }
+ // FIX!!! the optimization below is broken because we do not
+ // invalidate the cur_scan_chain upon a TRST/TMS. See arm_jtag.c
+ // for example on how to invlidate cur_scan_chain. Tested patches
gladly
+ // accepted!
+// if (arm11-jtag_info.cur_scan_chain == chain) {
+// JTAG_DEBUG(SCREG = %d SKIPPED, chain);
+// return jtag_add_statemove((state == ARM11_TAP_DEFAULT)
+// ? TAP_DRPAUSE : state);
+// }
JTAG_DEBUG(SCREG = %d, chain);
arm11_add_IR(arm11, ARM11_SCAN_N, ARM11_TAP_DEFAULT);
--
1.7.2.3
better with #if 0 rather than commenting out.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Last call before release
On 5 August 2011 04:38, Rodrigo Rosa rodrigorosa...@gmail.com wrote: I submitted these patches a couple weeks ago, i guess everybody was too busy with the release... Could they be added? Thanks! Sorry should have replied to your original email - i have put them in my patch todo list. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe oyvind.har...@zylin.comwrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) As I posted several times already, it's because the release procedure wasn't followed in creating the rc tags and tarballs. The following basic steps should be followed for a proper rc3 release. There are more things to take in consideration, for example making sure the NEWS file is properly updated and so on. Check the release manual that Zach and David wrote. 1. Manually fix, commit and push the skipped version bumps in configure.in: -AC_INIT([openocd], [0.5.0-dev], +AC_INIT([openocd], [0.5.0-rc3-dev], 2. do a fresh git clone of openocd 3. run tools/release.sh --next rc release 4. verify and publish archives/* 5. merge v0.5.0-rc4-dev into master and push it After this, git describe correctly reflects that we're in rc phase: v0.5.0-rc3-1-gbcded6a And version strings should be correct (didn't test): 0.5.0-rc3 if built from tarball, 0.5.0-rc4-dev if built from git HEAD. I think we really need to do this, like, right now, then wait for feedback from people building the released rc3 tarballs (a week tops), then do the final 0.5.0 release. No patches accepted except build and packaging fixes after rc3 is out. Final 0.5.0 release is very similar: 1. do a fresh git clone of openocd 2. run tools/release.sh --next minor --final release 3. verify and publish archives/* 4. merge v0.6.0-dev into master and push it /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 09:58, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) As I posted several times already, it's because the release procedure wasn't followed in creating the rc tags and tarballs. The following basic steps should be followed for a proper rc3 release. There are more things to take in consideration, for example making sure the NEWS file is properly updated and so on. Check the release manual that Zach and David wrote. 1. Manually fix, commit and push the skipped version bumps in configure.in: -AC_INIT([openocd], [0.5.0-dev], +AC_INIT([openocd], [0.5.0-rc3-dev], 2. do a fresh git clone of openocd 3. run tools/release.sh --next rc release 4. verify and publish archives/* 5. merge v0.5.0-rc4-dev into master and push it After this, git describe correctly reflects that we're in rc phase: v0.5.0-rc3-1-gbcded6a And version strings should be correct (didn't test): 0.5.0-rc3 if built from tarball, 0.5.0-rc4-dev if built from git HEAD. I think we really need to do this, like, right now, then wait for feedback from people building the released rc3 tarballs (a week tops), then do the final 0.5.0 release. No patches accepted except build and packaging fixes after rc3 is out. Final 0.5.0 release is very similar: 1. do a fresh git clone of openocd 2. run tools/release.sh --next minor --final release 3. verify and publish archives/* 4. merge v0.6.0-dev into master and push it /Andreas I will agree that the release process has not been followed with regards to tarballs. However this is not the cause of Øyvind query - please see my previous email. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On Fri, Aug 5, 2011 at 11:02 AM, Spencer Oliver s...@spen-soft.co.ukwrote: On 5 August 2011 09:58, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) As I posted several times already, it's because the release procedure wasn't followed in creating the rc tags and tarballs. I will agree that the release process has not been followed with regards to tarballs. However this is not the cause of Øyvind query - please see my previous email. Release tags are annotated, and so take priority with git describe. Ok, but if the release script would have been used, the v0.5.0-rc* tags would have been annotated. And they really should be, right? That's what the script does, the 0.4.0 and 0.3.0 rc tags were annotated, and it corresponds with Øyvind's initial expectation of a v0.5.0-rc2- output from git describe. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 10:19, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 11:02 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 5 August 2011 09:58, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) As I posted several times already, it's because the release procedure wasn't followed in creating the rc tags and tarballs. I will agree that the release process has not been followed with regards to tarballs. However this is not the cause of Øyvind query - please see my previous email. Release tags are annotated, and so take priority with git describe. Ok, but if the release script would have been used, the v0.5.0-rc* tags would have been annotated. And they really should be, right? That's what the script does, the 0.4.0 and 0.3.0 rc tags were annotated, and it corresponds with Øyvind's initial expectation of a v0.5.0-rc2- output from git describe. /Andreas Release tags are annotated, but not rc tags Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 10:26, Spencer Oliver s...@spen-soft.co.uk wrote: On 5 August 2011 10:19, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 11:02 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 5 August 2011 09:58, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 8:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: When I run git describe now I get v0.4.0-973-g0d7a948 rather than a v0.5.0-rc2-. Is that intentional? I think it's nice that we stick to v0.4.0- until v0.5.0- goes out of the door. I have no particular opinion, except it should be by choice and not by accident :-) As I posted several times already, it's because the release procedure wasn't followed in creating the rc tags and tarballs. I will agree that the release process has not been followed with regards to tarballs. However this is not the cause of Øyvind query - please see my previous email. Release tags are annotated, and so take priority with git describe. Ok, but if the release script would have been used, the v0.5.0-rc* tags would have been annotated. And they really should be, right? That's what the script does, the 0.4.0 and 0.3.0 rc tags were annotated, and it corresponds with Øyvind's initial expectation of a v0.5.0-rc2- output from git describe. /Andreas Release tags are annotated, but not rc tags use git describe --tags to take all tags (including soft) into account. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
Release tags are annotated, but not rc tags This sounds like a good policy to me. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On Fri, Aug 5, 2011 at 11:26 AM, Spencer Oliver s...@spen-soft.co.ukwrote: Release tags are annotated, but not rc tags Oh, but they are, or am I completely oblivious of git tags (quite possible)? $ git checkout v0.4.0-rc2~2 $ git describe v0.4.0-rc1-193-g747a607 http://repo.or.cz/w/openocd.git/tag/cd8ad2e961d3476ddfad3353390ce99a4872bdf1 http://repo.or.cz/w/openocd.git/tag/f74fdc5e4afc94b65cba4b4c357f0e67cc9d185a And why shouldn't they be? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 10:39, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Aug 5, 2011 at 11:26 AM, Spencer Oliver s...@spen-soft.co.uk wrote: Release tags are annotated, but not rc tags Oh, but they are, or am I completely oblivious of git tags (quite possible)? $ git checkout v0.4.0-rc2~2 $ git describe v0.4.0-rc1-193-g747a607 http://repo.or.cz/w/openocd.git/tag/cd8ad2e961d3476ddfad3353390ce99a4872bdf1 http://repo.or.cz/w/openocd.git/tag/f74fdc5e4afc94b65cba4b4c357f0e67cc9d185a And why shouldn't they be? /Andreas No sorry you are correct - the rc tags should be annotated aswell. The current 0.5.0-rc* are soft tags not annotated, which is incorrect. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
And why shouldn't they be? To me it's a matter of taste if rc candidate tags are annotated or not. I'm good with either choice. I was just curious as to whether it was accidental or intentional. Looks like it was accidental in that we really should be using the release procedure and when we do, then we get the annotated rc tags. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Tags
On 5 August 2011 11:07, Øyvind Harboe oyvind.har...@zylin.com wrote: And why shouldn't they be? To me it's a matter of taste if rc candidate tags are annotated or not. I'm good with either choice. I was just curious as to whether it was accidental or intentional. Looks like it was accidental in that we really should be using the release procedure and when we do, then we get the annotated rc tags. guessing by accident. If we had used the release.sh script this would not have happened. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] 3rd Call For Papers, 18th Annual Tcl/Tk Conference 2011
[[ Get your papers in. The deadline for abstracts and proposals is three weeks away. ]] 18th Annual Tcl/Tk Conference (Tcl'2011) http://www.tcl.tk/community/tcl2011/ October 24 - 28, 2011 Comfort Suites Manassas Manassas, Virgina, USA Important Dates: Abstracts and proposals due August 26, 2011 Notification to authors September 12, 2011 WIP and BOF reservations open August 1, 2011 Author materials due October 9, 2011 Tutorials Start October 24, 2011 Conference starts October 26, 2011 Email Contact:tclconfere...@googlegroups.com Submission of Summaries Tcl/Tk 2011 will be held in Manassas, Virgina, USA from October 24 - 28, 2011. The program committee is asking for papers and presentation proposals from anyone using or developing with Tcl/Tk (and extensions). Past conferences have seen submissions covering a wide variety of topics including: * Scientific and engineering applications * Industrial controls * Distributed applications and Network Managment * Object oriented extensions to Tcl/Tk * New widgets for Tk * Simulation and application steering with Tcl/Tk * Tcl/Tk-centric operating environments * Tcl/Tk on small and embedded devices * Medical applications and visualization * Use of different programming paradigms in Tcl/Tk and proposals for new directions. * New areas of exploration for the Tcl/Tk language This year is the fourth year that the Tcl community is participating in the Google Summer of Code. The conference program committee would like to encourage submissions that report on the Tcl projects selected for Google SoC 2011. Submissions should consist of an abstract of about 100 words and a summary of not more than two pages, and should be sent as plain text to tclconference AT googlegroups DOT com no later than August 26, 2011. Authors of accepted abstracts will have until October 9, 2011 to submit their final paper for the inclusion in the conference proceedings. The proceedings will be made available on digital media, so extra materials such as presentation slides, code examples, code for extensions etc. are encouraged. Printed proceedings will be produced as an on-demand book at lulu.com The authors will have 25 minutes to present their paper at the conference. The program committee will review and evaluate papers according to the following criteria: * Quantity and quality of novel content * Relevance and interest to the Tcl/Tk community * Suitability of content for presentation at the conference Proposals may report on commercial or non-commercial systems, but those with only blatant marketing content will not be accepted. Application and experience papers need to strike a balance between background on the application domain and the relevance of Tcl/Tk to the application. Application and experience papers should clearly explain how the application or experience illustrates a novel use of Tcl/Tk, and what lessons the Tcl/Tk community can derive from the application or experience to apply to their own development efforts. Papers accompanied by non-disclosure agreements will be returned to the author(s) unread. All submissions are held in the highest confidentiality prior to publication in the Proceedings, both as a matter of policy and in accord with the U. S. Copyright Act of 1976. The primary author for each accepted paper will receive registration to the Technical Sessions portion of the conference at a reduced rate. TCLCA receives first publication rights, and expects that this is the first time the paper is published. Not a retread from another conference, etc. TCLCA further receives subsequent publication rights, to handle the Publish-On-Demand nature of Lulu, our vendor for the dissemination of the conference proceedings. All other rights are retained by the author. You can put this on your website, include it in a book, expand it into a novel, sell the movie rights, etc. Other Forms of Participation The program committee also welcomes proposals for panel discussions of up to 90 minutes. Proposals should include a list of confirmed panelists, a title and format, and a panel description with position statements from each panelist. Panels should have no more than four speakers, including the panel moderator, and should allow time for substantial interaction with attendees. Panels are not presentations of related research papers. Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather sessions (BOFs) are available on a first-come, first-served basis starting in August 1, 2011. Specific instructions for reserving WIP and BOF time slots will be provided in the registration information available in June 2011. Some WIP and BOF time slots will be held open for on-site reservation. All attendees with an interesting work in progress should consider reserving a WIP slot. Registration Information More information on the conference is available the conference Web site
