Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011
No mailing list??? -- Ø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] Fwd: BerliOS will be closed on 31.12.2011
Am 01.10.2011 09:02, schrieb Øyvind Harboe: No mailing list??? No. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] updated Fujitsu FM3 Flash driver
Hi, some comments: 1. please fix warning: fm3.c: In function ‘fm3_chip_erase’: fm3.c:785:25: error: declaration of ‘fm3_info’ shadows a global declaration fm3.c:774:12: error: shadowed declaration is here 2. Remove this history, git keeps it: +// History: +// 2011-07-13 MWi First version +// 2011-09-27 MWi Flash type 2 added, algorithm start address now relocateable -- Ø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] software breakpoint with multicore systems
Can someone review these patches and comment? 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] Verdex: Add support for Gumstix Verdex boards.
Thanks :) On Sat, Oct 1, 2011 at 4:12 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Merged. 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] Fwd: BerliOS will be closed on 31.12.2011
Øyvind Harboe wrote: My first instinct is to move the mailing list wholesale to sourceforge. I agree strongly with this. Spencer Oliver wrote: I agree - I will look into it, website aswell. As for website and repositories, a lot of nice integration can be accomplished when self hosting, as I am doing for several projects already. I would be happy to host also the openocd repository(ies) and set up a Trac, which includes a wiki, a ticket system, a source code browser, and repository history view, all nicely integrated. Jim Larson wrote: Any consideration of using github (github.com)? I've been pretty happy with them and they have a huge user base. I am personally very strongly against depending on companies based in the US for open source project infrastructure. I find there are quite significant drawbacks, due to stupid US law and/or due to the service being provided by a business with a clear agenda, which makes it an impossible choice for any self-respecting open source project. Already the very very first condition of github terms and many others completely rule it out IMO: --8-- http://help.github.com/terms-of-service/ A. Account Terms 1. You must be 13 years or older to use this Service. --8-- This is not significant because OpenOCD has so many contributors under the age of 13, but because it is unacceptable IMO that it would be *ILLEGAL* to welcome a young contributor into the project. It is just absurd. Of course the terms continue with more great stuff. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011
Anders Montonen wrote: Øyvind Harboe wrote: My first instinct is to move the mailing list wholesale to sourceforge. I agree strongly with this. ... I am personally very strongly against depending on companies based in the US for open source project infrastructure. lol wut? From http://sourceforge.net/about: SourceForge.net is owned and operated by Geeknet, Inc., a publicly traded US-based company. I expected this. :) Mailing lists are an exception, because participation does not require creating an SF user account. Another less important factor is that open lists require a lot of work to operate (as everyone having operated a mail server knows) and a large operator benefits tremendously from economy of scale, thus can do a very good job at keeping mailing lists efficient and pleasant. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011
On Oct 1, 2011, at 17:34, Peter Stuge wrote: Øyvind Harboe wrote: My first instinct is to move the mailing list wholesale to sourceforge. I agree strongly with this. ... I am personally very strongly against depending on companies based in the US for open source project infrastructure. lol wut? From http://sourceforge.net/about: SourceForge.net is owned and operated by Geeknet, Inc., a publicly traded US-based company. -a___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011
It was just a suggestion, team, based on my own experience. I'm not pushing it, it has shortcomings, and I certainly appreciate the anti-US bias. There is no way to excuse the huge amount of legal baggage that companies in the US must deal with, and the often overt commercial interests. OTOH, a company having some commercial success isn't as likely to just disappear when you need it. So forget about github and get on with finding a new home. On 10/1/2011 7:34 AM, Peter Stuge wrote: Øyvind Harboe wrote: My first instinct is to move the mailing list wholesale to sourceforge. I agree strongly with this. Spencer Oliver wrote: I agree - I will look into it, website aswell. As for website and repositories, a lot of nice integration can be accomplished when self hosting, as I am doing for several projects already. I would be happy to host also the openocd repository(ies) and set up a Trac, which includes a wiki, a ticket system, a source code browser, and repository history view, all nicely integrated. Jim Larson wrote: Any consideration of using github (github.com)? I've been pretty happy with them and they have a huge user base. I am personally very strongly against depending on companies based in the US for open source project infrastructure. I find there are quite significant drawbacks, due to stupid US law and/or due to the service being provided by a business with a clear agenda, which makes it an impossible choice for any self-respecting open source project. Already the very very first condition of github terms and many others completely rule it out IMO: --8-- http://help.github.com/terms-of-service/ A. Account Terms 1. You must be 13 years or older to use this Service. --8-- This is not significant because OpenOCD has so many contributors under the age of 13, but because it is unacceptable IMO that it would be *ILLEGAL* to welcome a young contributor into the project. It is just absurd. Of course the terms continue with more great stuff. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1809 / Virus Database: 2085/4530 - Release Date: 09/30/11 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] updated Fujitsu FM3 Flash driver
openOCD.fseu wrote:
please find attached the updated Fujistu CORTEX M3 NOR Flash driver.
It includes:
- Improvement of error handling of retval = target_read/write_xxx();
Great to get better error handling! All the repeated retval=..if()
return look absolutely horrible but that's indeed not your fault.
We should maybe have some handy macros for this in shared code, to
make drivers prettier and simpler.
- No #if statements anymore
- Added Flash type 2 support
Great.
Content-Description:
0001-Updated-fm3.c-added-Flash-type-2-support-error-handl.patch
--- a/src/flash/nor/fm3.c
+++ b/src/flash/nor/fm3.c
@@ -1,23 +1,28 @@
-/***
- * Copyright (C) 2011 by Marc Willam, Holger Wech*
- * m.wil...@gmx.eu *
- * Copyright (C) 2011 Ronny Strutz *
- * *
- * This program is free software; you can redistribute it and/or modify *
- * it under the terms of the GNU General Public License as published by *
- * the Free Software Foundation; either version 2 of the License, or *
- * (at your option) any later version. *
- * *
- * This program is distributed in the hope that it will be useful, *
- * but WITHOUT ANY WARRANTY; without even the implied warranty of*
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
- * GNU General Public License for more details. *
- * *
- * You should have received a copy of the GNU General Public License *
- * along with this program; if not, write to the *
- * Free Software Foundation, Inc., *
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
- ***/
+/*
+ * Copyright (C) 2011 by Marc Willam, Holger Wech
*
+ * openOCD.fseu(AT)de.fujitsu.com
*
+ * Copyright (C) 2011 Ronny Strutz
*
+ *
*
+ * This program is free software; you can redistribute it and/or modify
*
+ * it under the terms of the GNU General Public License as published by
*
+ * the Free Software Foundation; either version 2 of the License, or
*
+ * (at your option) any later version.
*
+ *
*
+ * This program is distributed in the hope that it will be useful,
*
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
*
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
*
+ * GNU General Public License for more details.
*
+ *
*
+ * You should have received a copy of the GNU General Public License
*
+ * along with this program; if not, write to the
*
+ * Free Software Foundation, Inc.,
*
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
+
*/
Please avoid all whitespace-only changes. Perhaps especially so in
the license text for a file.
+
+// History:
+// 2011-07-13 MWi First version
+// 2011-09-27 MWi Flash type 2 added, algorithm start address now
relocateable
+
As Øyvind pointed out this is redundant, since git tracks history
already, and with good detail.
enum fm3_variant
{
- mb9bfxx1,
+ mb9bfxx1, /* Flash Type '1' */
mb9bfxx2,
mb9bfxx3,
mb9bfxx4,
mb9bfxx5,
- mb9bfxx6
+ mb9bfxx6,
+ mb9afxx1, /* Flash Type '2' */
+ mb9afxx2,
+ mb9afxx3,
+ mb9afxx4,
+ mb9afxx5,
+ mb9afxx6
+};
It would help to have a separate patch that adds the comma to the
last entry in the enum, followed by another patch that adds the new
variants, making sure to include a comma after the last new entry,
and putting the two comments on separate lines instead of together
with actual values, so that in the future no lines will need to
change unless there is an actual code change. Changing existing lines
creates unneccessary noise in the source code
Re: [Openocd-development] software breakpoint with multicore systems
Hi,
Michel JAOUEN wrote:
Here is a patch correcting this issue.
Content-Description: 0001-breakpoint-smp-software-breakpoint-correction.patch
From 5fc6a3e930bdfde679b50f00cee98ba1273b8ee9 Mon Sep 17 00:00:00 2001
From: Michel Jaouen michel.jao...@stericsson.com
Date: Fri, 30 Sep 2011 18:42:52 +0200
Subject: [PATCH] breakpoint : smp software breakpoint correction
---
src/target/breakpoints.c | 14 +++---
src/target/target.c |7 +++
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/target/breakpoints.c b/src/target/breakpoints.c
index 5a0fc40..d7acf00 100644
--- a/src/target/breakpoints.c
+++ b/src/target/breakpoints.c
@@ -228,6 +228,8 @@ int retval = ERROR_OK;
struct target_list *head;
struct target *curr;
head = target-head;
+ if (type == BKPT_SOFT) breakpoint_add_internal(head-target,
address,length, type);
+ else
while(head != (struct target_list*)NULL)
{
Sorry, but this is unacceptable. You are adding a new level of
conditionals without changing indentation. Come on.
I understand and very much appreciate the desire to touch as few
lines of codes as possible, but that objective can not take
precedence over correct indentation, which is absolutely fundamental
for quality source code, which I guess we all want to work with.
A suggestion is to correctly use goto, in order to avoid changing a
very large block of code, if this makes sense. You might not need to
use goto, but might be able to use return instead. I haven't looked
into this function so I can't say for sure, but the above is in any
case not OK.
@@ -330,15 +332,19 @@ void breakpoint_remove_internal(struct target *target,
uint32_t address)
if (breakpoint)
{
breakpoint_free(target, breakpoint);
+ return 1;
}
else
{
+ if (!target-smp)
LOG_ERROR(no breakpoint at address 0x%8.8 PRIx32 found,
address);
+return 0;
}
Same here about indentation. The added return line is also using
the wrong indentation character, please check your editor settings
and adjust it to the code style already used by the file. (I really
like the feature of some editors to autodetect the indent style used
in a file, but of course not all editors support this.)
void breakpoint_remove(struct target *target, uint32_t address)
{
-if ((target-smp))
+ int found = 0;
+ if ((target-smp))
{
Please avoid mixing whitespace changes with other changes. Send one
patch which fixes all whitespace issues at once.
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -3023,6 +3023,13 @@ COMMAND_HANDLER(handle_bp_command)
{
case 0:
return handle_bp_command_list(CMD_CTX);
+ case 2:
+ {
+ asid = 0;
+ COMMAND_PARSE_NUMBER(u32, CMD_ARGV[0], addr);
+ COMMAND_PARSE_NUMBER(u32, CMD_ARGV[1], length);
+ return handle_bp_command_set(CMD_CTX, addr,
asid, length, hw);
+ }
Why are these {} added, and why have the variable when it isn't used?
//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Typo in src/flash/nor/lpc2000.c
Akos Vandra wrote: Shouldn't the line in src/flash/nor/lpc2000.c:333 be LOG_ERROR(BUG: unknown lpc2000_info-variant encountered); ? I suspect copy pasting from the switch above it. Copypaste errors are plenty. Could you send a patch to fix it? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011
Le 01/10/2011 10:34, Peter Stuge a écrit : I am personally very strongly against depending on companies based in the US for open source project infrastructure. I find there are quite significant drawbacks, due to stupid US law and/or due to the service being provided by a business with a clear agenda, which makes it an impossible choice for any self-respecting open source project. Already the very very first condition of github terms and many others completely rule it out IMO: The anti-American stand is pure stupidity. Find better arguments to discredit any site. As for assuming that an American company is likely to be anti opensource, it is ridiculous. Some are and some are not, as in any other countries in the world. Some people should stick to facts and stop taking their information out of their behind. Having worked on project for Sourceforge for many years I think that Sourceforge is one of the best site for Open Source Michel -- For OS/2 and Linux Software visit http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011
Michel Catudal wrote: I am personally very strongly against depending on companies based in the US for open source project infrastructure. I find there are quite significant drawbacks, due to stupid US law and/or due to the service being provided by a business with a clear agenda, which makes it an impossible choice for any self-respecting open source project. Already the very very first condition of github terms and many others completely rule it out IMO: The anti-American stand is pure stupidity. Find better arguments to discredit any site. I think you misunderstood. It does not matter that a service provider is American, it matters that the service provider is bound by US law, because that means that the service can only be made available under silly terms. I tried to make this clear with the example. As for assuming that an American company is likely to be anti opensource, it is ridiculous. The purpose of every company in every country is to generate profit for the company, which is in some cases perfectly compatible with the aim of a given open source project, and in other cases not so much. In any case, how the company purpose expresses itself can change quickly, while self hosting has none of these problems and great technical advantages in addition. Some people should stick to facts and stop taking their information out of their behind. Yes, calling someone stupid and ridiculous is much better. Having worked on project for Sourceforge for many years I think that Sourceforge is one of the best site for Open Source It's unclear what you mean here, but I think you mean that you worked with development of SF infrastructure. As I already wrote, large operators benefit from economy of scale. For the case of SF mailing lists and the FRS (SF download hosting) I think it is a great move to allow our project to take advantage of this. But I think that the SF services that require a user account are not nearly open enough for a project that wants to call itself open. Sorry if you are offended by this opinion. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
