Re: [Openocd-development] OpenOCD Gerrit Review
Peter, On Wed, Oct 12, 2011 at 01:21:44PM +0200, Peter Stuge wrote: Jason wrote: Is there any intent to integrate gerrit back into the ML? Sending email is easy. Receiving and parsing email is not as easy. Agreed, I've been thinking through the obstacles, from a submitter pov, and I've come up with a few things that I think would help. I'm willing to write the patches if it's generally agreed they would be useful. 1.) Threading versions of a patch series together. So, when the maintainer has a chance to look at the thread, he/she can just go to the end of the thread to get the latest version. This would require a hook script in 'git format-patch' to add In-Reply-To: and to do patch versioning (read and detect from output directory?). Possibly, --versioning? Basically, I'm replacing gerrit's Change-Id with smtp's already useful Message-Id and In-Reply-To. 2.) Mod 'git format-patch' hook script to run checkpatch.pl with a repo appropriate config, inject the output into the patch. Between '---' and the diff. U-boot is already working on making checkpatch.pl more generic and configurable. 3.) While I'm breaking 'git format-patch' why not try to integrate a changelog file? eg. extract the changelog from the previous version for each patch, and throw in a '*** ADD NEW CHANGES HERE ***'. How to handle collapsed patches? 4.) Build a reject filter into the mailinglist server. If it sees 'PATCH' '[vV][0-9]' in the Subject and no In-Reply-To:, it will reject it with a pointer to 'How to submit patches' instructions. Additionally, it could also refuse patches without a 'git-send-email' Message-Id:, and patches without the output of checkpatch.pl in them. This could also be a 'Hold for moderator approval', depending on config options. Or, it could be implemented in the maintainers .procmailrc... See [1] for an existing gripe. I'm the Peter refered to there. I also like to do patch review in the mailer rather than in the browser, but it is difficult to integrate that with Gerrit. Instead of asking about intent, please participate in actually doing this integration. I'm more than happy to, however, I have no maintainer experience. I need some insight before I invest time in creating patches. ... You have probably already found out that Gerrit has an SSH interface besides the web interface. The SSH interface is of course much better suited for integration, but so far I don't think it's possible to create inline comments through it, which is the main glitch for me between what I can do in my mailer and what I could do with Gerrit via SSH. On the other hand the data is better structured in Gerrit which is worth much more for everyone who consumes my review. Oops, missed the ssh interface. Thanks for pointing that out. Jason wrote: If I am out for several days, my openocd imap folder has everything that happened. I browse the subjects, read the threads of interest, and move on. In the gerrit lurkflow, there's quite a bit more clicking (how long ago was it I last checked the pending patch list?) to get the same information. I also have to remember to visit the site. Again: Look at what the tool does and how it works! It is not a web site. It is a code review tool which receives git commits. I'm not at all against Gerrit sending lots of email to the list, the only bug is that review happening on the list will miss out on the point with Gerrit. But of course ideas about how to connect the glitch are very welcome. See my ideas, above. Admittedly, I'm trying to make existing tools do more, not add new ones. I've no problem with gerrit itself, I just tend to be a minimalist when it comes to new tools in existing workflows. A new user has to work significantly harder to maintain a prolonged interest in the project with gerrit (imnsho). See other email about Gerrit sending email. Point taken. On a personal note, I've found it much easier to contribute to u-boot and the kernel vice cyanogenmod. The main reason for this is the lack of a mailinglist for CM (they use gerrit). It is IMO not possible to replace a mailing list with a code review tool. They serve different purposes and complement each other. I agree, github, cyanogenmod and others seem to miss that... Maybe I'm odd and a one-off, but I thought it was worth mentioning Please give yourself more freedom in shaping how the project works. If you like patches to still come to the mailing list then you just have to say so, don't apologize. :) And FWIW I don't think anyone is against it. Thanks, I have no problem contributing to a project, I just haven't contributed here and didn't want to come off like a feature-requester. I'd hate to see that stream of patches and comments dissappear. :-( I'd really like a way to do inline comments via SSH. Can you think of any ideas for how we could do this? Gerrit needs to know which line in which file. As seen above, my ideas are
[Openocd-development] Change in openocd[master]: Add the SAM3N familly to the chip_details table
Attila Kinali has uploaded a new change for review. Change subject: Add the SAM3N familly to the chip_details table .. Add the SAM3N familly to the chip_details table Change-Id: Ic122d324eacf6e667ed6008ebb84708be944222c Signed-off-by: Attila Kinali att...@kinali.ch --- M src/flash/nor/at91sam3.c 1 file changed, 437 insertions(+), 0 deletions(-) git pull ssh://openocd.zylin.com:29418/openocd refs/changes/29/29/1 -- To view, visit http://openocd.zylin.com/29 To unsubscribe, visit http://openocd.zylin.com/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ic122d324eacf6e667ed6008ebb84708be944222c Gerrit-PatchSet: 1 Gerrit-Project: openocd Gerrit-Branch: master Gerrit-Owner: Attila Kinali att...@kinali.ch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Change in openocd[master]: docs: update project url's
On 13 October 2011 20:47, Uwe Hermann u...@hermann-uwe.de wrote: On Wed, Oct 12, 2011 at 01:04:26PM +0300, Spencer Oliver (Code Review) wrote: Spencer Oliver has submitted this change and it was merged. Change subject: docs: update project url's .. docs: update project url's Change-Id: I54fc3aff722ed25143aad85e58d19b72fcecbba0 Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- M NEWTAPS M PATCHES.txt M README M doc/manual/primer/patches.txt M doc/manual/server.txt M doc/openocd.texi 6 files changed, 10 insertions(+), 5 deletions(-) Approvals: Spencer Oliver: Verified; Looks good to me, approved Please configure gerrit so that the full patch is posted on the mailing list additionally, as it used to be. I personally read lots of patches and discussions offline (e.g. in a train) in my mail client, and I'm pretty sure I'm not the only one who'd prefer if patches would still end up on the list (and in the list archive) in addition to gerrit. Thanks! Uwe. -- Hopefully this should be done now - gerrit does not have this feature included yet, so had to write a quick patchset-created hook. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Reviewing in Gerrit
Even if you're not a maintainer, your help to review and comment on patches in Gerrit will be very much appreciated. -- Ø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] OpenOCD Gerrit Review
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Jason ... 1.) Threading versions of a patch series together. So, when the maintainer has a chance to look at the thread, he/she can just go to the end of the thread to get the latest version. This would require a hook script in 'git format-patch' to add In-Reply-To: and to do patch versioning (read and detect from output directory?). Possibly, --versioning? Basically, I'm replacing gerrit's Change-Id with smtp's already useful Message-Id and In-Reply-To. Could the Message-Id be set to, exactly, the Change-Id? ___ 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: 7b54c46 luminary: add peripheral reset script
This is an automated email from Gerrit. Spencer Oliver (s...@spen-soft.co.uk) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/30 -- gerrit commit 7b54c467d52cca17d62c40e15a063437be647605 Author: Spencer Oliver s...@spen-soft.co.uk Date: Mon Oct 17 22:04:21 2011 +0100 luminary: add peripheral reset script some luminary device classes require a reset script to emulate a hardware reset. Change-Id: Id505c92451244b48b0238c2130aebab2df8d208b Signed-off-by: Spencer Oliver s...@spen-soft.co.uk diff --git a/tcl/chip/ti/lm3s/lm3s.tcl b/tcl/chip/ti/lm3s/lm3s.tcl new file mode 100644 index 000..42da8c6 --- /dev/null +++ b/tcl/chip/ti/lm3s/lm3s.tcl @@ -0,0 +1 @@ +source [find chip/ti/lm3s/lm3s_regs.tcl] diff --git a/tcl/chip/ti/lm3s/lm3s_regs.tcl b/tcl/chip/ti/lm3s/lm3s_regs.tcl new file mode 100644 index 000..cb20812 --- /dev/null +++ b/tcl/chip/ti/lm3s/lm3s_regs.tcl @@ -0,0 +1,84 @@ +#* +# +# The following are defines for the System Control register addresses. +# +#* + +set SYSCTL_DID0 0x400FE000 ;# Device Identification 0 +set SYSCTL_DID1 0x400FE004 ;# Device Identification 1 +set SYSCTL_DC0 0x400FE008 ;# Device Capabilities 0 +set SYSCTL_DC1 0x400FE010 ;# Device Capabilities 1 +set SYSCTL_DC2 0x400FE014 ;# Device Capabilities 2 +set SYSCTL_DC3 0x400FE018 ;# Device Capabilities 3 +set SYSCTL_DC4 0x400FE01C ;# Device Capabilities 4 +set SYSCTL_DC5 0x400FE020 ;# Device Capabilities 5 +set SYSCTL_DC6 0x400FE024 ;# Device Capabilities 6 +set SYSCTL_DC7 0x400FE028 ;# Device Capabilities 7 +set SYSCTL_DC8 0x400FE02C ;# Device Capabilities 8 ADC +;# Channels +set SYSCTL_PBORCTL 0x400FE030 ;# Brown-Out Reset Control +set SYSCTL_LDOPCTL 0x400FE034 ;# LDO Power Control +set SYSCTL_SRCR00x400FE040 ;# Software Reset Control 0 +set SYSCTL_SRCR10x400FE044 ;# Software Reset Control 1 +set SYSCTL_SRCR20x400FE048 ;# Software Reset Control 2 +set SYSCTL_RIS 0x400FE050 ;# Raw Interrupt Status +set SYSCTL_IMC 0x400FE054 ;# Interrupt Mask Control +set SYSCTL_MISC 0x400FE058 ;# Masked Interrupt Status and +;# Clear +set SYSCTL_RESC 0x400FE05C ;# Reset Cause +set SYSCTL_RCC 0x400FE060 ;# Run-Mode Clock Configuration +set SYSCTL_PLLCFG 0x400FE064 ;# XTAL to PLL Translation +set SYSCTL_GPIOHSCTL0x400FE06C ;# GPIO High-Speed Control +set SYSCTL_GPIOHBCTL0x400FE06C ;# GPIO High-Performance Bus +;# Control +set SYSCTL_RCC2 0x400FE070 ;# Run-Mode Clock Configuration 2 +set SYSCTL_MOSCCTL 0x400FE07C ;# Main Oscillator Control +set SYSCTL_RCGC00x400FE100 ;# Run Mode Clock Gating Control +;# Register 0 +set SYSCTL_RCGC10x400FE104 ;# Run Mode Clock Gating Control +;# Register 1 +set SYSCTL_RCGC20x400FE108 ;# Run Mode Clock Gating Control +;# Register 2 +set SYSCTL_SCGC00x400FE110 ;# Sleep Mode Clock Gating Control +;# Register 0 +set SYSCTL_SCGC10x400FE114 ;# Sleep Mode Clock Gating Control +;# Register 1 +set SYSCTL_SCGC20x400FE118 ;# Sleep Mode Clock Gating Control +;# Register 2 +set SYSCTL_DCGC00x400FE120 ;# Deep Sleep Mode Clock Gating +;# Control Register 0 +set SYSCTL_DCGC10x400FE124 ;# Deep-Sleep Mode Clock Gating +;# Control Register 1 +set SYSCTL_DCGC20x400FE128 ;# Deep Sleep Mode Clock Gating +;# Control Register 2 +set SYSCTL_DSLPCLKCFG 0x400FE144 ;# Deep Sleep Clock Configuration +set SYSCTL_CLKVCLR 0x400FE150 ;# Clock Verification Clear +set SYSCTL_PIOSCCAL 0x400FE150 ;# Precision Internal Oscillator +;# Calibration +set SYSCTL_PIOSCSTAT0x400FE154 ;# Precision Internal Oscillator +;# Statistics +set SYSCTL_LDOARST 0x400FE160 ;# Allow Unregulated LDO to Reset +;# the Part +set SYSCTL_I2SMCLKCFG 0x400FE170 ;# I2S MCLK Configuration +set SYSCTL_DC9 0x400FE190 ;# Device Capabilities 9 ADC +
[Openocd-development] New patch to review for openocd: c3ee958 luminary: add new targets
This is an automated email from Gerrit.
Spencer Oliver (s...@spen-soft.co.uk) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/31
-- gerrit
commit c3ee958fc665dbf9d50b46528fd5f0b03ecd218b
Author: Spencer Oliver s...@spen-soft.co.uk
Date: Mon Oct 17 22:27:49 2011 +0100
luminary: add new targets
update target support from latest SW-DRL 8049
Change-Id: I40aba4d30fe2b79fd955f466c64d99a1dfd63ecf
Signed-off-by: Spencer Oliver s...@spen-soft.co.uk
diff --git a/src/flash/nor/stellaris.c b/src/flash/nor/stellaris.c
index 89cc8ef..4a21028 100644
--- a/src/flash/nor/stellaris.c
+++ b/src/flash/nor/stellaris.c
@@ -124,7 +124,7 @@ struct stellaris_flash_bank
};
// Autogenerated by contrib/gen-stellaris-part-header.pl
-// From Stellaris Firmware Development Package revision 6734
+// From Stellaris Firmware Development Package revision 8049
static struct {
uint32_t partno;
const char *partname;
@@ -166,6 +166,7 @@ static struct {
{0x10C1,LM3S1150},
{0x10C4,LM3S1162},
{0x10C2,LM3S1165},
+ {0x10EC,LM3S1166},
{0x10C6,LM3S1332},
{0x10BC,LM3S1435},
{0x10BA,LM3S1439},
@@ -175,10 +176,12 @@ static struct {
{0x1006,LM3S1607},
{0x10DA,LM3S1608},
{0x10C0,LM3S1620},
+ {0x10CD,LM3S1621},
{0x1003,LM3S1625},
{0x1004,LM3S1626},
{0x1005,LM3S1627},
{0x10B3,LM3S1635},
+ {0x10EB,LM3S1636},
{0x10BD,LM3S1637},
{0x10B1,LM3S1651},
{0x10B9,LM3S1751},
@@ -192,14 +195,29 @@ static struct {
{0x10BE,LM3S1958},
{0x10B5,LM3S1960},
{0x10B8,LM3S1968},
+ {0x10EA,LM3S1969},
+ {0x10CE,LM3S1B21},
+ {0x10CA,LM3S1C21},
+ {0x10CB,LM3S1C26},
+ {0x1098,LM3S1C58},
+ {0x10B0,LM3S1D21},
+ {0x10CC,LM3S1D26},
+ {0x101D,LM3S1F11},
+ {0x101B,LM3S1F16},
+ {0x10AF,LM3S1G21},
+ {0x1095,LM3S1G58},
+ {0x101E,LM3S1H11},
+ {0x101C,LM3S1H16},
{0x100F,LM3S1J11},
{0x103C,LM3S1J16},
{0x100E,LM3S1N11},
{0x103B,LM3S1N16},
{0x10B2,LM3S1P51},
{0x109E,LM3S1R21},
+ {0x10C9,LM3S1R26},
{0x1030,LM3S1W16},
{0x102F,LM3S1Z16},
+ {0x10D4,LM3S2016},
{0x1051,LM3S2110},
{0x1084,LM3S2139},
{0x1039,LM3S2276},
@@ -221,13 +239,17 @@ static struct {
{0x106D,LM3S2793},
{0x10E3,LM3S2911},
{0x10E2,LM3S2918},
+ {0x10ED,LM3S2919},
{0x1054,LM3S2939},
{0x108F,LM3S2948},
{0x1058,LM3S2950},
{0x1055,LM3S2965},
{0x106C,LM3S2B93},
+ {0x1094,LM3S2D93},
+ {0x1093,LM3S2U93},
{0x1008,LM3S3634},
{0x1043,LM3S3651},
+ {0x10C8,LM3S3654},
{0x1044,LM3S3739},
{0x1049,LM3S3748},
{0x1045,LM3S3749},
@@ -252,15 +274,28 @@ static struct {
{0x100B,LM3S5951},
{0x104E,LM3S5956},
{0x1068,LM3S5B91},
+ {0x102E,LM3S5C31},
+ {0x102C,LM3S5C36},
+ {0x105E,LM3S5C51},
+ {0x105B,LM3S5C56},
+ {0x105F,LM3S5D51},
+ {0x105C,LM3S5D56},
+ {0x1087,LM3S5D91},
+ {0x102D,LM3S5G31},
+ {0x101F,LM3S5G36},
+ {0x105D,LM3S5G51},
+ {0x104F,LM3S5G56},
{0x1009,LM3S5K31},
{0x104A,LM3S5K36},
{0x100A,LM3S5P31},
{0x1048,LM3S5P36},
+ {0x10B6,LM3S5P3B},
{0x100D,LM3S5P51},
{0x104C,LM3S5P56},
{0x1007,LM3S5R31},
{0x104B,LM3S5R36},
{0x1047,LM3S5T36},
+ {0x107F,LM3S5U91},
{0x1046,LM3S5Y36},
{0x10A1,LM3S6100},
{0x1074,LM3S6110},
@@ -275,12 +310,18 @@ static struct {
{0x108B,LM3S6637},
{0x10A3,LM3S6730},
{0x1077,LM3S6753},
+ {0x10D1,LM3S6816},
{0x10E9,LM3S6911},
+ {0x10D3,LM3S6916},
{0x10E8,LM3S6918},
{0x1089,LM3S6938},
{0x1072,LM3S6950},
{0x1078,LM3S6952},
{0x1073,LM3S6965},
+ {0x10AA,LM3S6C11},
+ {0x10AC,LM3S6C65},
+ {0x109F,LM3S6G11},
+ {0x10AB,LM3S6G65},
{0x1064,LM3S8530},
{0x108E,LM3S8538},
{0x1061,LM3S8630},
@@ -293,24 +334,51 @@ static struct {
{0x10A6,LM3S8962},
{0x1062,LM3S8970},
{0x10D7,LM3S8971},
+ {0x10AE,LM3S8C62},
+ {0x10AD,LM3S8G62},
+ {0x10CF,LM3S9781},
{0x1067,LM3S9790},
{0x106B,LM3S9792},
+ {0x102D,LM3S9971},
{0x1020,LM3S9997},
+ {0x10D0,LM3S9B81},
{0x1066,LM3S9B90},
{0x106A,LM3S9B92},
{0x106E,LM3S9B95},
{0x106F,LM3S9B96},
+ {0x101D,LM3S9BN2},
+ {0x101E,LM3S9BN5},
+ {0x101F,LM3S9BN6},
+ {0x1070,LM3S9C97},
+ {0x107A,LM3S9CN5},
+ {0x10A9,LM3S9D81},
+ {0x107E,LM3S9D90},
+ {0x1092,LM3S9D92},
+ {0x10C8,LM3S9D95},
+ {0x109D,LM3S9D96},
+ {0x107B,LM3S9DN5},
+ {0x107C,LM3S9DN6},
+
Re: [Openocd-development] OpenOCD Gerrit Review
Alex, On Mon, Oct 17, 2011 at 04:04:21PM -0500, Austin, Alex wrote: -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Jason ... 1.) Threading versions of a patch series together. So, when the maintainer has a chance to look at the thread, he/she can just go to the end of the thread to get the latest version. This would require a hook script in 'git format-patch' to add In-Reply-To: and to do patch versioning (read and detect from output directory?). Possibly, --versioning? Basically, I'm replacing gerrit's Change-Id with smtp's already useful Message-Id and In-Reply-To. Could the Message-Id be set to, exactly, the Change-Id? I'd have to check the RFC [1], but technically, they are both globally unique identifiers. So, I don't see why not. gerrit would have to be modified to look for a Change-Id in the headers of the email, and accept that the first version of a patch series already has a Change-Id assigned. Nothing impossible, there. From a quick glance at the RFC, the Message-Id is required to be globally unique, and _common_practice_ is to use epoch time in seconds '@hostname.tld'. If we're modding gerrit, we could probably do: Message-Id: gerrit-change-id-id_is_h...@users.mailserver.tld and have gerrit parse it out. That would align with common practice and be readily parsible. thx, Jason. [1] http://tools.ietf.org/html/rfc2392 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Gerrit Review
Jason wrote: 1.) Threading versions of a patch series together. I think Gerrit already does this. Did you try it? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] arm-jtag-ew + swd
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
