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
Re: [Openocd-development] resubmit lost works!
On May 17, 2009, at 11:06, Freddie Chopin wrote: Zach Welch pisze: They should have been treated to 'svn mv', because this would have preserved the history available from 'svn log'. First of all - I've tied to do that this way, but TortoiseSVN does not offer such option. It does, but not in an immediately obvious way: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-copy.html Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
Anders Montonen pisze: It does, but not in an immediately obvious way: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-copy.html I can do it that way, but the effect in a patch is worthless as I can only create info about removal of the file, but the new file is not created. In no way I can make TortoiseSVN create a patch with JUST changing paths and names. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
Zach Welch pisze: 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: This was ignored a while ago, but if you think that changing that stuff is worthless just tell me (; https://lists.berlios.de/pipermail/openocd-development/2009-April/005226.html 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
Sorry about dropping this on the floor. Could you resubmit the patch against svn head? Thanks! -- Ø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] resubmit lost works!
Øyvind Harboe pisze:
Sorry about dropping this on the floor.
Could you resubmit the patch against svn head?
attached.
4\/3!!
Index: src/target/board/crossbow_tech_imote2.cfg
===
--- src/target/board/crossbow_tech_imote2.cfg (revision 0)
+++ src/target/board/crossbow_tech_imote2.cfg (revision 0)
@@ -0,0 +1,46 @@
+# Crossbow Technology iMote2
+
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME imote2
+}
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ # force an error till we get a good number
+ set _CPUTAPID 0x
+}
+
+# PXA271 and an Intel Strataflash of 32 Megabytes (p30)
+#
+# Marvell/Intel PXA270 Script
+# set jtag_nsrst_delay to the delay introduced by your reset circuit
+# the rest of the needed delays are built into the openocd program
+jtag_nsrst_delay 800
+# set the jtag_ntrst_delay to the delay introduced by a reset circuit
+# the rest of the needed delays are built into the openocd program
+jtag_ntrst_delay 0
+#use combined on interfaces or targets that can't set TRST/SRST separately
+reset_config trst_and_srst separate
+#jtag scan chain
+
+jtag newtap $_CHIPNAME cpu -irlen 7 -ircapture 0x1 -irmask 0x7f -expected-id
$_CPUTAPID
+
+set _TARGETNAME [format %s.cpu $_CHIPNAME]
+target create $_TARGETNAME xscale -endian $_ENDIAN -chain-position
$_TARGETNAME -variant pxa27x
+$_TARGETNAME configure -work-area-virt 0x0x5c00 -work-area-phys
0x0x5c00 -work-area-size 0x1 -work-area-backup 1
+# maps to PXA internal RAM. If you are using a PXA255
+# you must initialize SDRAM or leave this option off
+
+
+#flash bank driver base size chip_width bus_width
+# works for P30 flash
+flash bank cfi 0x 0x200 2 2 0
Index: src/target/board/digi_connectcore_wi-9c.cfg
===
--- src/target/board/digi_connectcore_wi-9c.cfg (revision 0)
+++ src/target/board/digi_connectcore_wi-9c.cfg (revision 0)
@@ -0,0 +1,127 @@
+##
+# Target: DIGI ConnectCore Wi-9C
+##
+
+reset_config trst_and_srst
+
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME ns9360
+}
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ # This config file was defaulting to big endian..
+ set _ENDIAN big
+}
+
+
+# What's a good fallback frequency for this board if RCLK is
+# not available??
+jtag_rclk 1000
+
+
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ set _CPUTAPID 0x
+}
+
+set _TARGETNAME [format %s.cpu $_CHIPNAME]
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+jtag_nsrst_delay 200
+jtag_ntrst_delay 0
+
+
+##
+# Target configuration
+##
+
+target create $_TARGETNAME arm926ejs -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm926ejs
+$_TARGETNAME configure -event reset-init {
+ mww 0x90600104 0x3331
+ mww 0xA070 0x0001 # Enable the memory controller.
+ mww 0xA0700024 0x0006 # Set the refresh counter 6
+ mww 0xA0700028 0x0001 #
+ mww 0xA0700030 0x0001 # Set the precharge period
+ mww 0xA0700034 0x0004 # Active to precharge command period is 16
clock cycles
+ mww 0xA070003C 0x0001 # tAPR
+ mww 0xA0700040 0x0005 # tDAL
+ mww 0xA0700044 0x0001 # tWR
+ mww 0xA0700048 0x0006 # tRC 32 clock cycles
+ mww 0xA070004C 0x0006 # tRFC 32 clock cycles
+ mww 0xA0700054 0x0001 # tRRD
+ mww 0xA0700058 0x0001 # tMRD
+ mww 0xA0700100 0x4280 # Dynamic Config 0 (cs4)
+ mww 0xA0700120 0x4280 # Dynamic Config 1 (cs5)
+ mww 0xA0700140 0x4280 # Dynamic Config 2 (cs6)
+ mww 0xA0700160 0x4280 # Dynamic Config 3 (cs7)
+ #
+ mww 0xA0700104 0x0203 # CAS latency is 2 at 100 MHz
+ mww 0xA0700124 0x0203 # CAS latency is 2 at 100 MHz
+ mww 0xA0700144 0x0203 # CAS latency is 2 at 100 MHz
+ mww 0xA0700164 0x0203 # CAS latency is 2 at 100 MHz
+ #
+ mww 0xA0700020 0x0103 # issue SDRAM PALL command
+ #
+ mww 0xA0700024 0x0001 # Set the refresh counter to be as small as
possible
+ #
+ # Add some dummy writes to give the SDRAM time to settle, it needs two
+ # AHB clock cycles, here we poke in the debugger flag, this lets
+ # the software know that we are in the debugger
+ mww 0xA090 0x0002
+ mww 0xA090 0x0002
+ mww 0xA090 0x0002
+ mww 0xA090 0x0002
+ mww 0xA090 0x0002
+
Re: [Openocd-development] resubmit lost works!
Committed. Thanks! -- Ø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] resubmit lost works!
On Sat, 2009-05-16 at 16:57 +0200, Øyvind Harboe wrote:
Committed.
It took me a while to recognize the fact, but this was a case where the
current patch policy fails us badly.
r1798 broken the history for all of the files that were moved, because
they were removed ('svn rm') and then new copies added (w/ 'svn add').
They should have been treated to 'svn mv', because this would have
preserved the history available from 'svn log'. As it is, these all
look like new files, and it now requires some detective work to find
their older revision histories.
It might be nice to fix this to restore the history for those files.
Looking forward, we need to be careful about taking these kinds of
patches in the future, or adopt a better process for taking patches.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
Where do I post bugs that I observe, but have no time to pursue?
Here is a bug that I have observed and kinda know the reason for:
proc foo{a} {
verify_image $a
}
# this will fail since command.c does not correctly create an overrideable proc
foo c:\\temp\\test.bin
#this works
verify_image c:\\temp\\test.bin
--
Ø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] resubmit lost works!
On May 14, 2009, at 11:03 PM, Øyvind Harboe wrote:
Where do I post bugs that I observe, but have no time to pursue?
Here is a bug that I have observed and kinda know the reason for:
proc foo{a} {
verify_image $a
}
# this will fail since command.c does not correctly create an
overrideable proc
foo c:\\temp\\test.bin
#this works
verify_image c:\\temp\\test.bin
--
Ø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
Generally this is where a bug tracking system comes into play. Of
course, as a community, we seem to be against that idea.
--
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] resubmit lost works!
Generally this is where a bug tracking system comes into play. Of course, as a community, we seem to be against that idea. I think it's a matter of timing and we're nearing the point where it would be *less* work for everybody if we had a bugtracking system. -- Ø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] resubmit lost works!
Generally this is where a bug tracking system comes into play. Of course, as a community, we seem to be against that idea. This is something that we like to use too keep track of issues. It's easy to use and at least, outsider don't have to read all the last years of email to know what's work and what don't ! Do we allow anybody to register bugs? Perhaps we should require all bugs to be discussed in this mailing list first? It's no good to have a million bugs in a database and have nobody read that database either. -- Ø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] resubmit lost works!
-Message d'origine-
De : openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de] De la part de Rick
Altherr
Envoyé : 15 mai 2009 02:09
À : Øyvind Harboe
Cc : openocd-development
Objet : Re: [Openocd-development] resubmit lost works!
On May 14, 2009, at 11:03 PM, Øyvind Harboe wrote:
Where do I post bugs that I observe, but have no time to pursue?
Here is a bug that I have observed and kinda know the reason for:
proc foo{a} {
verify_image $a
}
# this will fail since command.c does not correctly create an
overrideable proc
foo c:\\temp\\test.bin
#this works
verify_image c:\\temp\\test.bin
--
Ø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
Generally this is where a bug tracking system comes into play. Of
course, as a community, we seem to be against that idea.
This is something that we like to use too keep track of issues.
It's easy to use and at least, outsider don't have to read all the last
years of email to know what's work and what don't !
My 0.02$
Jonathan
--
Rick Altherr
kc8...@kc8apf.net
He said he hadn't had a byte in three days. I had a short, so I split
it with him.
-- Unsigned
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Øyvind Harboe Verzonden: vrijdag 15 mei 2009 15:15 Aan: Jonathan Dumaresq CC: openocd-development Onderwerp: Re: [Openocd-development] resubmit lost works! Generally this is where a bug tracking system comes into play. Of course, as a community, we seem to be against that idea. This is something that we like to use too keep track of issues. It's easy to use and at least, outsider don't have to read all the last years of email to know what's work and what don't ! Do we allow anybody to register bugs? Perhaps we should require all bugs to be discussed in this mailing list first? It's no good to have a million bugs in a database and have nobody read that database either. Its always good to have a list with open issues. Look at other projects: most have a million bugs open! Seriously, a bug tracker can also be used to post preliminary patches. A while ago I found a bug in uClibc and attached my patch to the ticket. Some maintainer may pick it up and apply the patch, otherwise people may use the patch at their own risk / if they need it. Nico ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
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 | 38 +++--- 1 file changed, 27 insertions(+), 11 deletions(-) --- a/PATCHES +++ b/PATCHES @@ -1,28 +1,45 @@ Please mail patches to: -openocd-developm...@lists.berlios.de + openocd-development@lists.berlios.de -The patch should be against svn trunk using an SVN -diff. +Note that you can't currently send patches to that list unless +you're a member, although the list info page may say otherwise. -Attach the patch to the email as a .txt file and -also write a short change log entry that maintainers -can copy and paste into the commit message +The patch should be against svn trunk using an SVN diff. +If you use git-svn, a git diff or patch is OK too; likewise +a quilt patch, if you use quilt. + +It should be a good patch: focus it on a single issue, and +make it be easily reviewable. Don't make it so large that it's +hard to review; split large patches into smaller ones. (That +can also help track down bugs later on.) All patches should be +clean, which includes preserving the existing coding style and +updating documentation as needed. + +Attach the patch to the email as a .txt file and also write +a short change log entry that maintainers can copy and paste +into the commit message (although though many just include +the $SUBJECT). + +Say if it's a bugfix (describe the bug) or a new feature. +Don't expect patches to merge immediately for the next release. +Be ready to rework patches in response to feedback. Add yourself to the GPL copyright for non-trivial changes. To create a patch from the command line: -svn diff mypatch.txt + svn diff mypatch.txt -http://svnbook.red-bean.com/en/1.0/re09.html +See: -NB! remember to use svn add on new files first! + http://svnbook.red-bean.com/en/1.0/re09.html -http://svnbook.red-bean.com/en/1.0/re01.html +NB! remember to use svn add on new files first! + http://svnbook.red-bean.com/en/1.0/re01.html If you have a decent SVN GUI, then that should be able to create and apply patches as well... - \ No newline at end of file + ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
On Fri, 15 May 2009, David Brownell wrote: I'd also like to see a brief update about why this list adopts the unusual send as an attachment policy. Because one of the maintainer uses Windows and applying patches with cut and paste doesn't work so well? FWIW, I consider patches in attachment annoying as well. Nicolas ___ 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:49 AM, Nicolas Pitre wrote: On Fri, 15 May 2009, David Brownell wrote: I'd also like to see a brief update about why this list adopts the unusual send as an attachment policy. Because one of the maintainer uses Windows and applying patches with cut and paste doesn't work so well? FWIW, I consider patches in attachment annoying as well. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Attachments are annoying, but they avoid lots of odd issues that crop up when email clients get too eager to help. Things like trailing spaces and tab to space conversion tends to happen. Attachments are preserved much better in general. -- 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] resubmit lost works!
Attachments are annoying, but they avoid lots of odd issues that crop up when email clients get too eager to help. Things like trailing spaces and tab to space conversion tends to happen. Attachments are preserved much better in general. If things are leaning towards a bug tracking system, we could keep patches in that system -- Ø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] resubmit lost works!
On Friday 15 May 2009, Rick Altherr wrote: Attachments are annoying, but they avoid lots of odd issues that crop up when email clients get too eager to help. Things like trailing spaces and tab to space conversion tends to happen. Attachments are preserved much better in general. True, but see for example: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt Lots of clients can be made to behave sanely; some don't even need arm-twisting. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
On Fri, 15 May 2009, Øyvind Harboe wrote: Attachments are annoying, but they avoid lots of odd issues that crop up when email clients get too eager to help. Things like trailing spaces and tab to space conversion tends to happen. Attachments are preserved much better in general. If things are leaning towards a bug tracking system, we could keep patches in that system Personally, I consider bug tracking system even worse. Not that I contributed much to OpenOCD patch review (if at all) so far, but my time is just too limited for me to bother commenting on a patch that I have to save to a file then import back into my mailer in order to put my comments along side the parts of the patch I wish to comment on. Having to deal with a bug tracking system for commenting/reviewing patches constitute even more steps and is simply a turn-off for me. I'm deeply involved in a narrow part of the Linux kernel development, and in that world anything else but plain patches in the email body simply don't scale due to the manipulation overhead mentioned above. I do receive many many patches in my inbox every day. If I have the choice, I'll review patches for which I simply have to hit the reply button in my mailer and start inserting my comments inline right away over those that require any additional manipulations. With regard to mailers messing up tab and spaces... well, all I can say is that thousands of Linux developers do use mailers that can be made to preserve email body content, either by default or with some config settings since this is what the established patch review process requires. Many of those email clients are available on Windows and/or MAC too. And saving the email body to a file is usually just as easy as saving an attachment. Git even has a tool to pick up an email folder where you might have saved a bunch of patch-containing emails and apply them all. Note that I'm not asking for any particular requirements here. Simply stating how my review contribution is likely to be influenced by the patch channel. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
On Fri, 15 May 2009, Øyvind Harboe wrote: My main reason for wanting patches in attachments is that I want a *single* format. Forcing attachments help. I'm more often able to apply those patches than the rest. The Linux process requires a _single_ patch format as well. In this mailing list there is also a lot of good contributions from developers who have their first encounter w/svn and patches... Those people can be told how to send their contributions properly with some documentation, regardless of the format. I don't care what that format is really. I just don't want to learn a new method to apply them each time. Indeed. Of course a single format is best. I'm just highlighting the fact that some communities already converged on a format that happens to be the most efficient given the volume of patches involved. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] resubmit lost works!
Hi all, 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/ If there are other issues to which the maintainers failed to respond, please consider posting links to them as well. You do not need to be the original author or contributor of the patches; you only need to remember that we overlooked/ignored/rejected them. Once this seems done, I will update The List in the repository to help track them. Patches do not need apply cleanly to the latest trunk, but that would be nice bonus for us (so feel free to submit newer versions). In any case, all contributions will valued (by me, at least), and I will try to ensure that everyone receives a reply from someone qualified to review or apply it. I will also try to update older patches to apply to trunk. Please note: this is strategic planning, and not for the 0.2.0 release. I know that several of the outstanding patches may not be suitable due to their potential impact, but that is all the more reason to make sure we have all of our ducks in a row for when the release is finished. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
Zach Welch wrote: Hi all, 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/006374.html https://lists.berlios.de/pipermail/openocd-development/ If there are other issues to which the maintainers failed to respond, https://lists.berlios.de/pipermail/openocd-development/2009-May/006459.html I am happy to work on a fix for this one. I just need some direction as to the most appropriate fix, Strontium ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
