Re: [Openocd-development] Creative summary of options for OpenOCDdistros

[Nico Coesel]

> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Freddie Chopin
> Sent: woensdag 24 juni 2009 18:28
> To: openocd-development
> Subject: [Openocd-development] Creative summary of options for
> OpenOCDdistros
> 
> OK - be creative. End the flames, throw some ideas. Here goes another
> summary of REALISTIC and ACCEPTABLE options, if ftd2xx.dll will still
be
> "censored" in the distributions.
> 
> 1. Any kind of network protocol that would talk to "driver".
> 
> PRO - Possibilities to use JTAGs over internet to debug remotely,
> possibility to use closed-source drivers (for me that's a pro [; )
> 
> CONS - latency of the medium, need to run another program on one's PC,
> someone has to create the program and that has to be more complicated
> than the one from option 2.

Freddy,
Talking over de network may not be an option for Windows. A couple of
years aho I worked on a portable (Linux / Windows) client - server
application that used tcp/ip. On Linux this worked fine but on Windows
XP we quickly learned that many short packets takes a lot of CPU power
(even when send & received on localhost). We ended up using a shared
memory & signals solution on Windows. A bit more cumbersome to write,
but it performed very well.

Nico Coesel


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Breakpoints do not work for LM3S6918 /

[Joseph Kuss]

I also am posting to the SparkFun's list for openOCD

http://forum.sparkfun.com/viewtopic.php?t=16068

Best regards,

Joe
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Freddie Chopin]

Ronald Vanschoren pisze:
> At least the translation layer should be GPL'd and the binary
> part should be publicly available.

Just like in linux - the "interface" between OpenOCD and library can 
clearly be open-source.

Zach Welch pisze:
> Someone should present a complete design document. ;)

For me this idea is extremely close in implementation to the "tcp/ip 
idea". I think that those two ideas should be merged and the "drivers" 
created in a way that would make it possible to load them into the 
"tcp/ip software" and "modular OpenOCD" without any changes.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Freddie Chopin]

Ronald Vanschoren pisze:
> Bit confused here, what do you mean with "BOTH libraries"

When you enable RLink (for example) which uses libusb, the libusb0.dll 
library HAS TO be present on the system, even if you don't plan to use 
RLink - that is because the libraries now are loaded unconditionally and 
always.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Carte blanche for MIPS support commits anyone?

[Øyvind Harboe]

Just so you guys know. As the recruiter I'm currently
on the lookout for someone I can give carte blanche
to on MIPS changes.

The carte blanche is the final step before being a regular
OpenOCD maintainer w/commit access.

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] The OpenOCD Foundation

[Øyvind Harboe]

> Without biasing the community further than this, what would you expect
> from such an entity? As a user? Developer? Contributor? Vendor? Founder?

I'd like to see an ability to collect money to  pay a developer to do
more tedious
legwork of making more complete and well tested target support or otherwise
crossing various chasms that is hard to do in small steps.

Here are some targets I can think of that require a significant
initial kickstart
effort that I'm not expecting to crop up overnight or as a result of incremental
patches:

- Altera Nios
- PowerPC
- Cortex A8
- 64 bit target support
- Non-JTAG physical interfaces. This includes written guidelines for
interface vendors.


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Advanced Reset Process

[Øyvind Harboe]

On Thu, Jun 25, 2009 at 12:06 AM, David Brownell wrote:
> On Wednesday 24 June 2009, Duane Ellis wrote:
>> > So maybe you can answer this ... What does the "arp_" prefix in
>> > various commands represent?
>> >
>> > "Address Resolution Protocol" was my first reaction ... but
>> > that doesn't seem relevant to JTAG.  ;)
>>
>> That name "arp_" was coined by my self an Oyvind last year when we where
>> trying to introduce "Reset events" and all the other Jim type events.
>>
>> The "ARP" - stood for: "Advanced Reset Process" - 
>
>
> On Wednesday 24 June 2009, Ųyvind Harboe wrote:
>> The idea is to have a prefix to low level fn's that the higher
>> level tcl reset proc uses.
>>
>> As such the choice of prefix is arbitrary.
>
> OK, first question answered.  Thanks.
>
> Next ...
>
>
> Does it seem to you like the reset process is flexible
> enough yet?

The idea is that those targets where the tcl reset
proc doesn't cut it would implement their own
tcl reset proc from scratch. This avoids switching
programming paradigm from procedural to
event based, i.e. we could add events until
the cows go home and still miss that crucial
event for the next target.

I don't believe that it is possible to *ever*
add a reset event that is flexible enough for
all future targets.  I'm in favour of adapting OpenOCD
as we go along rather than create a hugely complicated
monster reset scheme that still won't catch the next
jtag router from hell problems.

> I'm thinking .. no:
>
>  - All those reset events go to debug targets ... but
>   there's at least the ICEpick example, where a JRC
>   needs 100+ TCK cycles after entering TLR, and it's
>   easy to find others.  Loading an FPGA, for one.
>   Those aren't targets; so no events...

I'm not even sure that the reset concept even applies to
an FPGA. For Altera Nios I'd first like to program the
FPGA, then reset the CPU.

>  - I was looking at DM355 documentation and it clearly
>   distinguishes "cold" resets -- both TRST and SRST
>   get cycled -- from "warm" ones -- SRST only.  We
>   don't seem to have a clean way to do "warm" today.

soft_reset_halt?

[I've deleted those items where I had no useful input
at this time]

> And I suspect that if I looked around a bit, I'd find
> more such cases where the reset model isn't (yet!)
> advanced enough.  Thoughts?

A target/board config file can reimplement the
reset proc from scratch. How far does that get you?


-- 
Øyvind Harboe
Embedded software and hardware consulting services
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] Unbreak build for Mac OS X

[Duane Ellis]

Oleksandr Tymoshenko wrote:
> Attached patch unbreaks build on MacOS X (I guess 
> on *BSD too):
>
> - stdlib.h should be included instead of malloc.h for 
> better portability
> - Eliminate "r could be used uninitialized" gcc warning 
>   

COMMITED - Thanks.

-Duane.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch] Unbreak build for Mac OS X

[Oleksandr Tymoshenko]

Attached patch unbreaks build on MacOS X (I guess 
on *BSD too):

- stdlib.h should be included instead of malloc.h for 
better portability
- Eliminate "r could be used uninitialized" gcc warning 

-- 
gonzo
Index: src/helper/membuf.c
===
--- src/helper/membuf.c	(revision 2400)
+++ src/helper/membuf.c	(working copy)
@@ -20,7 +20,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "membuf.h"
Index: src/flash/at91sam3.c
===
--- src/flash/at91sam3.c	(revision 2400)
+++ src/flash/at91sam3.c	(working copy)
@@ -2385,6 +2385,7 @@
 	if (0 == strcmp("show", argv[0])) {
 		if (who == -1) {
 		showall:
+			r = ERROR_OK;
 			for (x = 0 ; x < pChip->details.n_gpnvms ; x++) {
 r = FLASHD_GetGPNVM(&(pChip->details.bank[0]), x, &v);
 if (r != ERROR_OK) {
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch] MIPS/EJTAG watchpoints support

[Oleksandr Tymoshenko]

Attached patch adds simple watchpoint support 
for MIPS32/EJTAG (no value comparation yet).

-- 
gonzo
Index: src/target/mips_ejtag.h
===
--- src/target/mips_ejtag.h	(revision 2400)
+++ src/target/mips_ejtag.h	(working copy)
@@ -96,6 +96,11 @@
 #define EJTAG_IBA10xFF301100
 #define EJTAG_DBS0xFF302000
 #define EJTAG_DBA10xFF302100
+#define		EJTAG_DBCn_NOSB(1 << 13)
+#define		EJTAG_DBCn_NOLB(1 << 12)
+#define		EJTAG_DBCn_BLM_MASK			0xff
+#define		EJTAG_DBCn_BLM_SHIFT		4
+#define		EJTAG_DBCn_BE(1 << 0)
 
 typedef struct mips_ejtag_s
 {
Index: src/target/mips_m4k.c
===
--- src/target/mips_m4k.c	(revision 2400)
+++ src/target/mips_m4k.c	(working copy)
@@ -693,25 +693,132 @@
 
 int mips_m4k_set_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
 {
-	/* TODO */
+	mips32_common_t *mips32 = target->arch_info;
+	mips32_comparator_t * comparator_list = mips32->data_break_list;
+	int wp_num = 0;
+	/*
+	 * watchpoint enabled, ignore all byte lanes in value register
+	 * and exclude both load and store accesses from  watchpoint
+	 * condition evaluation
+	*/
+	int enable = EJTAG_DBCn_NOSB | EJTAG_DBCn_NOLB | EJTAG_DBCn_BE | 
+(0xff << EJTAG_DBCn_BLM_SHIFT);
+	
+	if (watchpoint->set)
+	{
+		LOG_WARNING("watchpoint already set");
+		return ERROR_OK;
+	}
+
+	while(comparator_list[wp_num].used && (wp_num < mips32->num_data_bpoints))
+		wp_num++;
+	if (wp_num >= mips32->num_data_bpoints)
+	{
+		LOG_DEBUG("ERROR Can not find free FP Comparator");
+		LOG_WARNING("ERROR Can not find free FP Comparator");
+		exit(-1);
+	}
+
+	if (watchpoint->length != 4)
+	{
+		LOG_ERROR("Only watchpoints of length 4 are supported");
+		return ERROR_TARGET_UNALIGNED_ACCESS;
+	}
+
+	if (watchpoint->address % 4)
+	{
+		LOG_ERROR("Watchpoints address should be word aligned");
+		return ERROR_TARGET_UNALIGNED_ACCESS;
+	}
+
+	switch (watchpoint->rw)
+	{
+		case WPT_READ:
+			enable &= ~EJTAG_DBCn_NOLB;
+			break;
+		case WPT_WRITE:
+			enable &= ~EJTAG_DBCn_NOSB;
+			break;
+		case WPT_ACCESS:
+			enable &= ~(EJTAG_DBCn_NOLB | EJTAG_DBCn_NOSB);
+			break;
+		default:
+			LOG_ERROR("BUG: watchpoint->rw neither read, write nor access");
+	}
+
+	watchpoint->set = wp_num + 1;
+	comparator_list[wp_num].used = 1;
+	comparator_list[wp_num].bp_value = watchpoint->address;
+	target_write_u32(target, comparator_list[wp_num].reg_address, comparator_list[wp_num].bp_value);
+	target_write_u32(target, comparator_list[wp_num].reg_address + 0x08, 0x);
+	target_write_u32(target, comparator_list[wp_num].reg_address + 0x10, 0x);
+	target_write_u32(target, comparator_list[wp_num].reg_address + 0x18, enable);
+	target_write_u32(target, comparator_list[wp_num].reg_address + 0x20, 0);
+	LOG_DEBUG("wp_num %i bp_value 0x%" PRIx32 "", wp_num, comparator_list[wp_num].bp_value);
+	
 	return ERROR_OK;
 }
 
 int mips_m4k_unset_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
 {
-	/* TODO */
+	/* get pointers to arch-specific information */
+	mips32_common_t *mips32 = target->arch_info;
+	mips32_comparator_t * comparator_list = mips32->data_break_list;
+	
+	if (!watchpoint->set)
+	{
+		LOG_WARNING("watchpoint not set");
+		return ERROR_OK;
+	}
+
+	int wp_num = watchpoint->set - 1;
+	if ((wp_num < 0) || (wp_num >= mips32->num_data_bpoints))
+	{
+		LOG_DEBUG("Invalid FP Comparator number in watchpoint");
+		return ERROR_OK;
+	}
+	comparator_list[wp_num].used = 0;
+	comparator_list[wp_num].bp_value = 0;
+	target_write_u32(target, comparator_list[wp_num].reg_address + 0x18, 0);
+	watchpoint->set = 0;
+
 	return ERROR_OK;
 }
 
 int mips_m4k_add_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
 {
-	/* TODO */
+	mips32_common_t *mips32 = target->arch_info;
+
+	if (mips32->num_data_bpoints_avail < 1)
+	{
+		LOG_INFO("no hardware watchpoints available");
+		return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
+	}
+		
+	mips32->num_data_bpoints_avail--;
+
+	mips_m4k_set_watchpoint(target, watchpoint);
 	return ERROR_OK;
 }
 
 int mips_m4k_remove_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
 {
-	/* TODO */
+	/* get pointers to arch-specific information */
+	mips32_common_t *mips32 = target->arch_info;
+
+	if (target->state != TARGET_HALTED)
+	{
+		LOG_WARNING("target not halted");
+		return ERROR_TARGET_NOT_HALTED;
+	}
+
+	if (watchpoint->set)
+	{
+		mips_m4k_unset_watchpoint(target, watchpoint);
+	}
+
+	mips32->num_data_bpoints_avail++;
+
 	return ERROR_OK;
 }
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[Michel Catudal]

Zach Welch a écrit :
> Personally, I want to be done with talking about these matters and start
> to move on to fix the problems for the community.  Sound good?
>
> Cheers,
>
> Zach
>
>   
Agreed!

-- 
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
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] Creative summary of options for OpenOCD distros

[Zach Welch]

On Thu, 2009-06-25 at 00:12 +0200, Ronald Vanschoren wrote:
> > This is _very_ apt observation, and one I almost forgot myself.
> >   
> Thanks ;-)
> > As (I think) you say here, the Linux kernel module scenario does not
> > affect the legality of a loadable module in the same user-space process
> > as OpenOCD.  The module still violates the GPL when distributed, since
> > it would be derived in part from the type and API definitions provided
> > by the driver interface header files.  Thus, binaries of the driver
> > module could not be distributed.
> >   
> The situation with Linux is a little more gray and I was kinda hoping
> nobody would notice. Some API from Linux is outside GPL (like
> systemcalls and some other). This is probably how NVIDIA makes a full
> closed source kernel module.
> But even if it wasn't so, only the translation layer between Linux API
> and closed source library has to be released. The translation layer is
> obviously derived work, but anything past that obviously is not.
> This is basically the same OpenOCD would do: release everything up to
> FTD2XX API.
> > However, I have mentioned that modular drivers could allow a build-kit
> > to only produce that single driver from source, though the "build"
> > requirements still get out of control.  The latest "link-kit" idea would
> > be perfect for this though!  Modular drivers are still a Good Thing.
> >   
> Link-kit is definitely better then build-kit, but what are we doing
> here? Dynamic linking is also a "link-kit". In my interpretation of GPL,
> there is nothing illegal to distributing an OpenOCD binary that _CAN_
> link to FTD2XX but doesn't require it. We (OpenOCD community) would not
> distribute FTD2XX ourselves, but point users to the FTDI download page
> and say "if you download the DLL and put it in the OpenOCD directory,
> something magic could happen". I'm assuming here it's not legal to
> distribute FTD2xx, I don't know about that as I don't know what license
> it's available under.
> It's all gray here, but won't somebody please think of the chil^H^H^H^H
> users. We must assume they are not very much into building/linking.

Arg.  The link kit suffers from the same deficiencies: what are
distributed inside the ccache?  The _binary_ object files.  Mega-Duh.
In hindsight, this particular solution is just "unlinked binary"
distribution; it should be considered DOA.  I probably missed that
because I'm going on 26+ hours since sleeping.  Sorry.

> As you might have noticed I'm one of the "loose" people regarding this
> GPL thing, but on the other hand I'm not too keen on binary modular
> drivers. At least the translation layer should be GPL'd and the binary
> part should be publicly available. This opens a lot of doors, but maybe
> some we don't want to open...

Someone should present a complete design document. ;)

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] The OpenOCD Foundation

[Wookey]

+++ Zach Welch [2009-06-24 14:00 -0700]:
> On Wed, 2009-06-24 at 09:30 -0700, Zach Welch wrote:
> """
> I hereby commit myself to donating all profits recovered in the pursuit
> of OpenOCD GPL violations on my behalf to a non-profit.  I would prefer
> that the community create The OpenOCD Foundation to receive such funds
> and manage them along with the copyrights and trademarks on behalf the
> open source and free software communities.  Should forming this type of
> organization haven proven intractable, I want any recovered monies to
> fund the Free Software Foundation instead.
> """
> 
> I have prepared a proposal to create The OpenOCD Foundation, which I can
> post in a new thread.  

I'm not sure a project of this size needs a whole foundation of its
own. It might make more sense to look at using an institution like SPI
which provides services like keeping money in pools for projects and
legal advice, to Free Software projects. This requires little more
than asking them to accept OpenOCD and set up a pool for project monies.

Having a copyright assignment body might be useful. 

Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Ronald Vanschoren]

Thanks for pointing out the system32 thing. I forgot about that. I'm an
embedded developer, I don't do things like DLL's ;-)

Bit confused here, what do you mean with "BOTH libraries"

 Original Message  
Subject: [Openocd-development] Creative summary of options for OpenOCD
distros
From: Freddie Chopin 
To: openocd-development 
Date: Thu Jun 25 2009 00:20:53 GMT+0200 (Romance Standard Time)

  Ronald Vanschoren pisze:
  
  
Link-kit is definitely better then build-kit, but what are we doing
here? Dynamic linking is also a "link-kit". In my interpretation of GPL,
there is nothing illegal to distributing an OpenOCD binary that _CAN_
link to FTD2XX but doesn't require it. We (OpenOCD community) would not
distribute FTD2XX ourselves, but point users to the FTDI download page
and say "if you download the DLL and put it in the OpenOCD directory,
something magic could happen". I'm assuming here it's not legal to
distribute FTD2xx, I don't know about that as I don't know what license
it's available under.

  
  
This is not required, because when one installs the drivers for FTDI 
based device, the ftd2xx.dll is automatically copied from the "driver 
package" to windows/system32 folder. The library (dll) just has to be 
"somewhere" where it can be reached via PATH variable. So if one has 
FT2232 based dongle, one has the library somewhere on the system - no 
additional downloading and copying that anywhere is required.

BTW in such scenario it would be best to modify the code so that it 
could use BOTH libraries, selectable somehow during runtime 
(automatically or manually).

4\/3!!
___
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

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Freddie Chopin]

Ronald Vanschoren pisze:
> Link-kit is definitely better then build-kit, but what are we doing
> here? Dynamic linking is also a "link-kit". In my interpretation of GPL,
> there is nothing illegal to distributing an OpenOCD binary that _CAN_
> link to FTD2XX but doesn't require it. We (OpenOCD community) would not
> distribute FTD2XX ourselves, but point users to the FTDI download page
> and say "if you download the DLL and put it in the OpenOCD directory,
> something magic could happen". I'm assuming here it's not legal to
> distribute FTD2xx, I don't know about that as I don't know what license
> it's available under.

This is not required, because when one installs the drivers for FTDI 
based device, the ftd2xx.dll is automatically copied from the "driver 
package" to windows/system32 folder. The library (dll) just has to be 
"somewhere" where it can be reached via PATH variable. So if one has 
FT2232 based dongle, one has the library somewhere on the system - no 
additional downloading and copying that anywhere is required.

BTW in such scenario it would be best to modify the code so that it 
could use BOTH libraries, selectable somehow during runtime 
(automatically or manually).

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Ronald Vanschoren]

> This is _very_ apt observation, and one I almost forgot myself.
>   
Thanks ;-)
> As (I think) you say here, the Linux kernel module scenario does not
> affect the legality of a loadable module in the same user-space process
> as OpenOCD.  The module still violates the GPL when distributed, since
> it would be derived in part from the type and API definitions provided
> by the driver interface header files.  Thus, binaries of the driver
> module could not be distributed.
>   
The situation with Linux is a little more gray and I was kinda hoping
nobody would notice. Some API from Linux is outside GPL (like
systemcalls and some other). This is probably how NVIDIA makes a full
closed source kernel module.
But even if it wasn't so, only the translation layer between Linux API
and closed source library has to be released. The translation layer is
obviously derived work, but anything past that obviously is not.
This is basically the same OpenOCD would do: release everything up to
FTD2XX API.
> However, I have mentioned that modular drivers could allow a build-kit
> to only produce that single driver from source, though the "build"
> requirements still get out of control.  The latest "link-kit" idea would
> be perfect for this though!  Modular drivers are still a Good Thing.
>   
Link-kit is definitely better then build-kit, but what are we doing
here? Dynamic linking is also a "link-kit". In my interpretation of GPL,
there is nothing illegal to distributing an OpenOCD binary that _CAN_
link to FTD2XX but doesn't require it. We (OpenOCD community) would not
distribute FTD2XX ourselves, but point users to the FTDI download page
and say "if you download the DLL and put it in the OpenOCD directory,
something magic could happen". I'm assuming here it's not legal to
distribute FTD2xx, I don't know about that as I don't know what license
it's available under.
It's all gray here, but won't somebody please think of the chil^H^H^H^H
users. We must assume they are not very much into building/linking.

As you might have noticed I'm one of the "loose" people regarding this
GPL thing, but on the other hand I'm not too keen on binary modular
drivers. At least the translation layer should be GPL'd and the binary
part should be publicly available. This opens a lot of doors, but maybe
some we don't want to open...


gr.

Ronald
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Advanced Reset Process

[David Brownell]

On Wednesday 24 June 2009, Duane Ellis wrote:
> > So maybe you can answer this ... What does the "arp_" prefix in
> > various commands represent?
> >
> > "Address Resolution Protocol" was my first reaction ... but
> > that doesn't seem relevant to JTAG.  ;)
> 
> That name "arp_" was coined by my self an Oyvind last year when we where 
> trying to introduce "Reset events" and all the other Jim type events.
> 
> The "ARP" - stood for: "Advanced Reset Process" - 


On Wednesday 24 June 2009, Øyvind Harboe wrote:
> The idea is to have a prefix to low level fn's that the higher
> level tcl reset proc uses.
>
> As such the choice of prefix is arbitrary.

OK, first question answered.  Thanks.

Next ...


Does it seem to you like the reset process is flexible
enough yet?  I'm thinking .. no:

 - All those reset events go to debug targets ... but
   there's at least the ICEpick example, where a JRC
   needs 100+ TCK cycles after entering TLR, and it's
   easy to find others.  Loading an FPGA, for one.
   Those aren't targets; so no events...

 - I was looking at DM355 documentation and it clearly
   distinguishes "cold" resets -- both TRST and SRST
   get cycled -- from "warm" ones -- SRST only.  We
   don't seem to have a clean way to do "warm" today.

 - In cases where there's no SRST available (*), there's
   no alternate hook to trigger reset through JTAG.  For
   example, using JRC operations (I'm hoping to get some
   documentation).  Or with Cortex-M3, it seems that
   some DAP operations can generate SRST too.

 - Wondering why this old PXA255 board won't work with
   current OpenOCD ... docs say that not only does it
   need 35+ TCK cycles after entering TLR, but also
   that the model is to keep SRST active while issuing
   the first few JTAG commands.  Current reset code
   deactivates SRST at the same time as TRST.

 - I found some TI docs talking about "Wait in Reset"
   capability of some systems, triggered by changing
   the EMU0/EMU1 signals (which OpenOCD doesn't know
   about) from "pulled high" to "one driven low".
   Same kind of model as those PXA255 docs describe.

 - Even when SRST *does* exist, I can imagine debug
   scenerios where using it is the wrong thing.  You
   may just want to reset one component, not the whole
   system.

 - Chasing that PXA thing I wanted to just issue a
   reset with no target enabled.  It didn't want to
   do such a thing with only JTAG level stuff defined.

And I suspect that if I looked around a bit, I'd find
more such cases where the reset model isn't (yet!)
advanced enough.  Thoughts?

- Dave

(*) As for example wherever TI's 14-pin JTAG connector
is used.  My DM6446 board through 20-pin CTI to
14-pin level shifting adapter; OMAP3 BeagleBoard.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Freddie Chopin]

Freddie Chopin pisze:
> Actually I think that OpenOCD should switch to dynamic library loading, 
> because the need to have all possible usb libraries when you use Wiggler 
> and OpenOCD version compiles with support for all possible dongles is 
> not very convenient.

... OpenOCD version compile_D with ...

S is really close to D, and it's late [;

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Freddie Chopin]

Michael Schwingen pisze:
> However, as soon as a combination of OpenOCD + non-GPL plugin module is
> distributed as a single package/installer, you might again be in trouble
> with the GPL. IANAL, but anyone willing to distribute an installer
> package *should* be sure, and that means a proposed solution should be
> on the safe side.

What would be the purpose of distributing every possible driver/module 
with OpenOCD installer? There would be a separate 
project/website/whatever that would  have the drivers/modules ready for 
download

Actually I think that OpenOCD should switch to dynamic library loading, 
because the need to have all possible usb libraries when you use Wiggler 
and OpenOCD version compiles with support for all possible dongles is 
not very convenient.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Michael Schwingen]

Freddie Chopin wrote:
> I'm not the first one to suggest such idea (modularity, drivers, ...) on 
> this list.
>   
Right. And modules in the same address space are tricky license-wise.
>   
>> The drivers would have to run in a separate process space, which means
>> 
>
> You are going to check the process spaces on every single PC that is on 
> this planet? Can we please stop this extremism?
>   
I won't check (I compile my own binaries on Linux), and I don't really
care what users do - they may well link OpenOCD to the FTD2XX library
and run that binary on their machine.

However, as soon as a combination of OpenOCD + non-GPL plugin module is
distributed as a single package/installer, you might again be in trouble
with the GPL. IANAL, but anyone willing to distribute an installer
package *should* be sure, and that means a proposed solution should be
on the safe side.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd, ftd2xx

[Duane Ellis]

Zach Welch wrote:
> Hi all,
>
> Here is the full list of GPL-compliant solutions for libftd2xx GPL
> compliance, after further review, consideration, and enumeration:
>
> 1) Documentation:  build it yourself!
> 2) Build-Kit: automate the build on users' machines
> 3) XXX: to be revealed, if legal
> 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx
> 5) sockets: separate ftd2xx into their own process space
> 6) libusb+libftdi: The Right Thing To Do ;)
>   
You are missing (7) - "WinUSB" - the windows platform type solution that
is simular to libusb.
Sadly, it does not go back to Win2K - but - most (popular) others are
solved.

-Duane.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Michael Schwingen]

Freddie Chopin wrote:
> Michael Schwingen pisze:
>   
>> by linking OpenOCD with FTD2XX, you create a
>> derived work which can not be distributed under GPL because the library
>> is not GPL.
>> 
>
> You wouldn't link OpenOCD to anything at all. User would decide what 
> file he/she would like to use, and that file has to provide full ABI 
> that is required for JTAG operations.
>   
I think we were talking about different things - that paragraph was
meant as a clarification of the current situation.

When talking about plugins/modules:
Agreed, that works - *but* only if the file is *not* GPL, and that means
you have to write it from scratch without taking the existing parts of
the FTD2232 JTAG driver from OpenOCD.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] first ftd2xx fix: documentation!

[Freddie Chopin]

Main problem with build environment for Windows is that MinGW itself is 
just a compiler, and MSYS is just a shell. You need like a dozen of 
different addons for MSYS, and you need to compile them and install 
them. It's not common knowledge for Windows user what is the system 
directory on linux.

A build instructions can be detailed, but the process itself is pretty 
long, as you have to download an install lots of stuff - my folder with 
almost-all that is required is 133megs, add the libraries and openocd 
itself.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[Duane Ellis]

David Brownell wrote:
> On Wednesday 24 June 2009, Dominic wrote:
>   
>>  Being the one who followed the project from 
>> its very beginning I believe I do know some things that others may have 
>> missed 
>> or never heard about.
>> 
>
> So maybe you can answer this ... What does the "arp_" prefix in
> various commands represent?
>
> "Address Resolution Protocol" was my first reaction ... but
> that doesn't seem relevant to JTAG.  ;)
>   
That name "arp_" was coined by my self an Oyvind last year when we where 
trying to introduce "Reset events" and all the other Jim type events.

The "ARP" - stood for: "Advanced Reset Process" - 

-Duane.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Freddie Chopin]

Michael Schwingen pisze:
> by linking OpenOCD with FTD2XX, you create a
> derived work which can not be distributed under GPL because the library
> is not GPL.

You wouldn't link OpenOCD to anything at all. User would decide what 
file he/she would like to use, and that file has to provide full ABI 
that is required for JTAG operations.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Zach Welch]

On Wed, 2009-06-24 at 21:36 +0200, Ronald Vanschoren wrote: 
> > Note: Linux kernel modules need to be GPL, too - the only way to have 
> > non-GPL drivers in Linux is to have userspace drivers, which are quite 
> > limited in capabilities.
> >   
> 
> This is not correct. GPL v2 talks about "derived work". It's well
> accepted (by Linus himself and most of the community except the holier
> then pope people) that binary kernel modules (so not releasing source
> code) is acceptable IF the original driver was NOT written for Linux. If
> it is merely ported to Linux, only the portation layer has to be
> released. I think the NVIDIA drivers are an example. I know a company
> who uses such binary drivers and was in contact with FSF who approved
> the approach.

This is _very_ apt observation, and one I almost forgot myself.

> To stay on topic, following this (FSF approved) interpretation of GPL
> v2, FTD2XX is NOT a derived work of OpenOCD so it should not be released
> under GPL.

As (I think) you say here, the Linux kernel module scenario does not
affect the legality of a loadable module in the same user-space process
as OpenOCD.  The module still violates the GPL when distributed, since
it would be derived in part from the type and API definitions provided
by the driver interface header files.  Thus, binaries of the driver
module could not be distributed.

However, I have mentioned that modular drivers could allow a build-kit
to only produce that single driver from source, though the "build"
requirements still get out of control.  The latest "link-kit" idea would
be perfect for this though!  Modular drivers are still a Good Thing.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Freddie Chopin]

Michael Schwingen pisze:
> Freddie Chopin wrote:
>> 2. Modular OpenOCD which would allow binary "drivers" to be used (just 
>> as the drivers are used in Linux kernel)
> What kind of module interface do you envision that would avoid the 
> problems which we currently have with the FTD2XX library?

This idea is identical to the "tcp/ip idea", just without that [; There 
would be a "Generic JTAG ABI" defined, with some functions like reset(), 
write(), read(), identify(), do_sth() etc. The user would provide the 
library (.dll on windows) and run OpenOCD with parameters to use that 
file. Or OpenOCD may scan for files. Or whatever. The library handles 
the interface between JTAG and OpenOCD.

Actually with clever implementation such a library could be used with 
"tcp/ip idea" - the library would not be loaded by OpenOCD but by some 
sotware that would work as a tcp/ip <-> library bridge.

I'm not the first one to suggest such idea (modularity, drivers, ...) on 
this list.

> The drivers would have to run in a separate process space, which means

You are going to check the process spaces on every single PC that is on 
this planet? Can we please stop this extremism?

> Note: Linux kernel modules need to be GPL, too - the only way to have 
> non-GPL drivers in Linux is to have userspace drivers, which are quite 
> limited in capabilities.

Tell that to NVIDIA then [;

Anyway - the "tcp/ip idea" is maily the same - the only problem is that 
user has to have another program which has to be running, with more 
configuration options and more potential problems for end-user. The 
"driver" idea just skips the "network" part.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers

[David Claffey]

The FASTDATA register is part of the EJTAG specification at least back to 3.10
(search for MD00047-2B-EJTAG-SPC-03.10.pdf to see the FASTDATA register).

This patch optimizes any calls to target->type->bulk_write_memory() and I have
only found the call in target.c. I don't know if flash programming will touch
this code.

- David

Nico Coesel wrote:
>>I'm itching to apply any patches on MIPS4K, but I can't really
>>dive into MIPS support and provide useful feedback
>>
>>Part of my job description in OpenOCD is to be a recruiter
>>and we're desperately short on active MIPS target
>>experts.
> 
> If the PIC32 catches on you should see more MIPS experts.
> 
> 
>>So if anyone out there have opinions about MIPS target code,
>>you've been warned that I'll give this a cursory look and then commit it
>>if I hear nothing in a day or two.
> 
> I could give the patches a spin on the MIPS platform I'm working with. I
> just don't know whether 'my' target has the FASTDATA register. I think I
> could give it a try for programming external flash first thing in the
> morning. I can't really promise anything though.
> 
> Nico Coesel
> 
> 
> 
> 
> ___
> 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

Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers

[Spencer Oliver]

> I'm itching to apply any patches on MIPS4K, but I can't 
> really dive into MIPS support and provide useful feedback
> 
> Part of my job description in OpenOCD is to be a recruiter 
> and we're desperately short on active MIPS target experts.
> 
> So if anyone out there have opinions about MIPS target code, 
> you've been warned that I'll give this a cursory look and 
> then commit it if I hear nothing in a day or two.
> 
> 

I will have a look over the next couple of days - using a pic32 target.

Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper

[Spencer Oliver]

> 
> Spencer Oliver wrote:
> > strok_r is not available on win32 - strok is said to be 
> reentrant on win32.
> > Not near a dev pc at the moment so i thought i would point 
> it out - i 
> > can make the change later if you do not have time.
> >   
> 
> Hmm...  Perhaps we should add "strtok_r()" to the replacments.c file.
> 
> We could take an instance from Newlib - it has a BSD licensed 
> implimentation.
> 
> What do you think?
> 

i think just using the win32 strtok will be fine - msdn state it as being
thread safe.
the other msdn choice is to use strtok_s, but that seesm to also be missing
from mingw.

http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/963aac07-da1a
-4612-be4a-faac3f1d65ca

Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Michael Schwingen]

Ronald Vanschoren wrote:
>> Note: Linux kernel modules need to be GPL, too - the only way to have 
>> non-GPL drivers in Linux is to have userspace drivers, which are quite 
>> limited in capabilities.
>>   
>> 
>
> This is not correct. GPL v2 talks about "derived work". It's well
> accepted (by Linus himself and most of the community except the holier
> then pope people) that binary kernel modules (so not releasing source
> code) is acceptable IF the original driver was NOT written for Linux. If
> it is merely ported to Linux, only the portation layer has to be
> released. I think the NVIDIA drivers are an example. I know a company
> who uses such binary drivers and was in contact with FSF who approved
> the approach.
>   
It seems you are right, and I remembered (partially) wrong - this sums
it up nice:

http://lkml.indiana.edu/hypermail/linux/kernel/0312.0/0670.html

However, this still means that if we implement a JTAG-cable module API,
and you implement a JTAG cable driver that then calls FTD2XX, that
module is probably still a derived work - you can't claim that such a
module existed outside OpenOCD before and was just ported to OpenOCD.

> To stay on topic, following this (FSF approved) interpretation of GPL
> v2, FTD2XX is NOT a derived work of OpenOCD so it should not be released
> under GPL.
>   
Right. However, that is not the original problem that started the thread
- the problem is that by linking OpenOCD with FTD2XX, you create a
derived work which can not be distributed under GPL because the library
is not GPL.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd, ftd2xx

[Yusuf Caglar AKYUZ]

Zach Welch wrote:
> On Wed, 2009-06-24 at 20:14 +0100, Ian Guffick wrote:
>> 
>>> Here is the full list of GPL-compliant solutions for libftd2xx GPL
>>> compliance, after further review, consideration, and enumeration:
>>>
>>> 1) Documentation:  build it yourself!
>>> 2) Build-Kit: automate the build on users' machines
>>> 3) XXX: to be revealed, if legal
>>> 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx
>>> 5) sockets: separate ftd2xx into their own process space
>>> 6) libusb+libftdi: The Right Thing To Do ;)
>>>
>> 
>>
>> Just a thought on option 2 - the build kit.
>> This would be a large download, and quite a lot of work for someone to put 
>> together.
>> If the GPL violation happens in distributing code that is linked to FTD2XX, 
>> could the build kit have pre-compiled objects for openocd - that are then 
>> linked on the users machine. The pre-compiled objects, as distributed, would 
>> not be linked to FTD2XX. This would reduce the complexitiy of the build kit 
>> down to a much simpler 'link-kit'. It's function would be no different to 
>> the build kit.
>> I haven't looked into it but maybe this could be as simple as a few object 
>> files, LD and a few MingW libraries along with a batch file.
> 
> I think it will take a little bit more effort than this (some autotools
> magic to ensure users can build different configurations), but this is a
> great idea for reducing the download sizes.  In many ways, it sounds a
> bit like using ccache; once the cache is populated, you only ever link.
> 
> Cheers,
> 
> Zach
> 

Actually this is a very nice approach. Making only linking process
on the user side helps a lot in this case. I suspect this may be
easier than we think. This can be even handled in installer scripts
like nsis.

On the other hand, I have a working build tool at hand, it currently:

+ Downloads FTD2XX libraries,
+ Fetches OpenOCD using SVN,
+ Configures, builds and installs openocd

all with a simple wizard so no user interaction is mandatory.
However, putting cygwin and gcc into kit makes it very huge in size.
It is also possible to download cygwin components without user
interaction(cygwin has an installer) however I couldn't manage it to
work.

I guess, in the end all will be needed on user side is some time and
 bandwidth.

Thanks,
Caglar

P.S. Current SVN HEAD is not building on Windows, at least I cannot
succeed. Configure is unable to test ftd2xx libraries but it is
building if I disable checks.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] first ftd2xx fix: documentation!

[Zach Welch]

Hello,

It remains somewhat unclear to me exactly how badly distributors need to
see a solution today, when users (who are all developers, right?) should
be able to compile the code themselves and use the FTD2XX driver.  

If Windows is the blocker, the first question that should be answered
is: how do we build OpenOCD on Windows?  Everything else goes from that.

Thus, can someone explain why this cannot be solved by good build
process documentation?  No code, other than some command line examples.
Just a good old fashioned HOWTO for building the MinGW32 distribution
from scratch.  Do we have these today in the tree?  I cannot trivially
locate them  Why not?  Same for CygWin, and I apologize if I missed
either of these in-tree.

If someone were to provide instructions for the setup steps (in-tree),
someone can probably turn that into a build-kit script (in-tree).  And
someone else might be able to integrate that with the Qt helper already
under development (which will be in-tree).  Hurrah!

Clarifying this somewhat, the required build process seems to be:

1) download(/compile)/install a MinGW32 toolchain
2) compile/install OpenOCD dependencies in temporary dir
3) this step intentionally left empty, because...

I believe the last step (compile/install OpenOCD) will already be
handled by the Qt wrapper, but I hope interested developers will work on
the list to clarify these details.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] The OpenOCD Foundation

[Zach Welch]

On Wed, 2009-06-24 at 09:30 -0700, Zach Welch wrote:
[snip] 
> To reiterate, I am now no longer willing to accept offers to do the work
> that I actually need to survive, to demonstrate that my motives here
> have no profit in them anymore.  All previous offers for me to do paid
> work are now off the table, until all hostilities from the community
> have been ameliorated.  I hope this action helps resolve some tensions.

Okay, with Dominic's encouragement, let me strike the above and replace
it with something of much clearer intent -- and beneficial to the entire
OpenOCD and free software communities.  Happily, this also saves me from
shooting my career in the foot.

"""
I hereby commit myself to donating all profits recovered in the pursuit
of OpenOCD GPL violations on my behalf to a non-profit.  I would prefer
that the community create The OpenOCD Foundation to receive such funds
and manage them along with the copyrights and trademarks on behalf the
open source and free software communities.  Should forming this type of
organization haven proven intractable, I want any recovered monies to
fund the Free Software Foundation instead.
"""

I have prepared a proposal to create The OpenOCD Foundation, which I can
post in a new thread.  It has been sitting in my Drafts box for weeks,
prepared to be pitched to the community if the need arose.  I would like
to introduce it fully in the next day or two, after adjusting it to
account for recent events, discussions, and pending community feedback.

The arguments for such formal organization are indicated above:
violation money comes from copyright violations, which can only be
enforced by copyright holders.  We have now seen this can turn into a
real nightmare when it comes to taking action, simply by discussing a
possible exception to the license.  Can you imagine what would happen if
anyone of us tried to sue each others customers for violations; even if
those suits turned out to be frivolous, it would be a PITA to sort out
for the community.  Traumatic would not even begin to describe it.

Without such a formal organization, I fear that too many stakeholders
will be involved for the community to take decisive actions when they
are required to defend the project's IP.  From what I understand, a lack
of rights-holder unity may hinder or derail some types of enforcement
efforts in the future.

Collective IP is an area where things become less clear to me. I know
how to exercise my own rights as an individual far better than those of
a project as a whole.  Anyone else have insight?   In any event, a
foundation _is_ an individual, legally speaking, which is why the
_legal_ issues are so much easier.  Decisions... well, those will still
be hard and should be community driven.  

With a non-profit means of contributing support (i.e. tax-deductable),
the community could use money to buy new targets for developers -- and
much more.  I have  laid out the benefits in fairly comprehensive vision
based on my past experience in the area of non-profit entities, but my
ideas need the community's input and support to succeed.

Without biasing the community further than this, what would you expect
from such an entity? As a user? Developer? Contributor? Vendor? Founder?

Please provide feedback to this thread.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[Zach Welch]

Dominic,

Since this followed your very constructive and friendly reply to my
summary of the options and willingness to swear off profits, I have
tried to interpret your response herein in the best possible light.
Likewise, I hope you will grant me the same consideration, just in case
it is needed. ;)

On Wed, 2009-06-24 at 19:35 +0200, Dominic wrote:
> On Wednesday 24 June 2009 19:04:37 Zach Welch wrote:
> > Are you any of those things, today? Is he contributing, today?
> >
> > > Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004
> (with
> > > 1-2 years or more of intensive coding)
> >
> > I do want to be clear that I do value and respect his contributions
> and
> > his copyrights, and I welcome both of you to continue contributing
> to
> > the OpenOCD community in the future.
> >
> > However, neither he nor you have contributed much constructive
> lately,
> > which means you have effectively abdicated your authority in the
> > community. In an open source community, that authority derives from
> > being a responsible and active contributor. Does this seem
> reasonable?
> 
> 
> 
> The OpenOCD was and always will be my project. I'm constantly
> following the list, although I'm not able to read each and every post,
> especially when the number of messages explodes like it did recently.

If you mean it will always be yours in spirit, yes it will.  You will
always be the spiritual leader of the project.  Your willingness to
create this project and release it under the GPL has been appreciated by
countless developers, and I never want to steal that thunder from you.
You deserve to be enshrined in the OpenOCD community forever.

However, you can simultaneously acknowledge that you have not been
active on this list, so the "authority" that I spoke of your abdicating
is of "command authority".  The authority to lead the project to where
the community needs to go, to manage the infrastructure, and to make
executive decisions. 

Clearly, that last item needs to be clarified between the two of us
directly.  You are aware that I have been acting as a pro forma leader
here, and these recent events saw me moving to take executive actions
that I have experience to know were necessary and sufficient to protect
the integrity of the OpenOCD IP for all of its contributors.  [[When it
comes to protecting copyrights, they matter more than users, because the
contributors own their the rights to the code.]]

Unfortunately, this process was complicated when you entered the debate
on the side of an exception.  You are still given tacit command
authority, with the result being that you nearly led the road down an
indefensible legal path.  Your off-list threat to remove all of my
changes from the repository further demonstrated that you still believe
that you can wield absolute power without suffering any consequences.
As I have said before now, that is no longer the case.

When you use your authority, you effectively override other contributors
and maintainers that have been working hard on the project.  The rest of
us must try to earn (or demand) respect from the community on a periodic
basis.  That is not a pure meritocracy; this status quo needs to change,
with you accepting the same means of attaining privilege: by working on
the trunk (or current release branches) and with the user community.

Between multiple copyright holders and the GPL, the _only_ fair way to
describe OpenOCD would be to say that it is *our* project, with the most
active contributors leading the way in authority and responsibilities.
In the face of abdication of command authority, the community should
hold the project leaders accountable -- or replace them with new active
contributors with equivalent authority.  That should hold true for you,
me, or anyone.

Your opinions should always matter and be considered, but you are not as
close to the code today as you once were.  Authority needs to be in the
hands of those who are actively working to improve and maintain the code
for the community.  If you are not reading every message, then I think
those who do should have more authority than you.  Does this sound fair?

> I'm voicing my concerns when I see changes that interfere with some
> key design ideas that were part of the original code I released. The
> last issue was the removal of the asynchronous in handlers, which were
> then reinstalled in a different way but achieving essentially the same
> goal which was fine with me. I do think it is important to point out
> how I wanted some things to be used when this isn't clear from the
> code.
>
> I saw speculations about what I might have intended which is when I
> first responded to the current issue. Being the one who followed the
> project from its very beginning I believe I do know some things that
> others may have missed or never heard about.

I positively did _not_ mean that you have abdicated your "architectural
authority" or knowledge of the system based on your unique experience.
T

[Openocd-development] Question about the driver install structure for libftdi

[Michael Fischer]

Hello List,

from Freddie I know that a "mix mode" installer is working.
Here libftdi is used for the JTAG part of the FT2232 chip, 
and the FTD2XX driver is used for the COM port of the chip.

Now I can confirm that the COM port of the Turtelizer is working.

The installation is a little strange, because the user must point
to two different folders.

-driver
  |-ftdilib
  |-non-gpl
 |-turtelizer

For the JTAG port to ftdilib and for the COM port to turtelizer
under non-gpl.

In the moment I do not know if this is intuitive. Here
we can use one ftdilib file for all of the devices,
but I want to prefer the following structure:

-driver
   |-turtelizer
  |-jtag
  |-com
   |-jtagkey
  |-jtag

and so on. This should be more intuitive for the user.
The disadvantage is that we need for each libftdi device
his own libftdi inf file. But this is easier for the user,
and the user should be the priority.

@Zach,
this is one point for the TODO list.

Best regards,

Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers

[Nico Coesel]

>I'm itching to apply any patches on MIPS4K, but I can't really
>dive into MIPS support and provide useful feedback
>
>Part of my job description in OpenOCD is to be a recruiter
>and we're desperately short on active MIPS target
>experts.

If the PIC32 catches on you should see more MIPS experts.


>So if anyone out there have opinions about MIPS target code,
>you've been warned that I'll give this a cursory look and then commit it
>if I hear nothing in a day or two.

I could give the patches a spin on the MIPS platform I'm working with. I just 
don't know whether 'my' target has the FASTDATA register. I think I could give 
it a try for programming external flash first thing in the morning. I can't 
really promise anything though. 

Nico Coesel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[Øyvind Harboe]

On Wed, Jun 24, 2009 at 10:30 PM, David Brownell wrote:
> On Wednesday 24 June 2009, Dominic wrote:
>>       Being the one who followed the project from
>> its very beginning I believe I do know some things that others may have 
>> missed
>> or never heard about.
>
> So maybe you can answer this ... What does the "arp_" prefix in
> various commands represent?

That's actually "advanced reset process/procedure" or some
such. Duane came up with it.

The idea is to have a prefix to low level fn's that the higher
level tcl reset proc uses.

As such the choice of prefix is arbitrary.

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[David Brownell]

On Wednesday 24 June 2009, Dominic wrote:
>   Being the one who followed the project from 
> its very beginning I believe I do know some things that others may have 
> missed 
> or never heard about.

So maybe you can answer this ... What does the "arp_" prefix in
various commands represent?

"Address Resolution Protocol" was my first reaction ... but
that doesn't seem relevant to JTAG.  ;)


(yep, a non-license question!)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

[Øyvind Harboe]

Interesting that you should bring up eCos.

Look at what happened there. *LOTS* of closed source
packages to eCos exists

I'd hate to have closed source targets + interface drivers
in OpenOCD and if you use the eCos license you'll get that
for sure. I know there are hardware vendors who's aching for it.
Look at the www.vinchip.com guys. Where is the OpenOCD source
code that they wrote?

You'd have to be careful as the devil to make a license
allow FTDI non-GPL compliant code for the purposes of USB
while not mentioning FTDI specifially and avoiding targets
+ interface closed source.

Another stated policy of OpenOCD is that all hardware vendors are
equal. So neither FTDI, nor USB could be mentioned in such
an exception.

It's a million times easier to just fix this technically than to try
to solve this with licensing.

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Ronald Vanschoren]

> Note: Linux kernel modules need to be GPL, too - the only way to have 
> non-GPL drivers in Linux is to have userspace drivers, which are quite 
> limited in capabilities.
>   

This is not correct. GPL v2 talks about "derived work". It's well
accepted (by Linus himself and most of the community except the holier
then pope people) that binary kernel modules (so not releasing source
code) is acceptable IF the original driver was NOT written for Linux. If
it is merely ported to Linux, only the portation layer has to be
released. I think the NVIDIA drivers are an example. I know a company
who uses such binary drivers and was in contact with FSF who approved
the approach.

To stay on topic, following this (FSF approved) interpretation of GPL
v2, FTD2XX is NOT a derived work of OpenOCD so it should not be released
under GPL.

gr.

Ronald
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

[Anders Montonen]

On Jun 24, 2009, at 18:13, Freddie Chopin wrote:

> David Brownell pisze:
>> [so called "full explanation"]
> You are wrong, because I just still don't get it how a
> GPL-with-exception can exist.

For an example of a GPL+exception license, see the eCos license at 
. The use case is different, but it is a functioning license. libstdc 
++-v3 has a similar exception in its license.

Regards,
Anders
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd, ftd2xx

[Thomas A. Moulton]

On Wed, 2009-06-24 at 11:26 -0700, Zach Welch wrote:

> 
> We can raise money to pay for the signing costs; presumably, they don't
> need to be signed during development testing.  
> 

My IT guys said that in Vista unsigned drivers can be loaded if you
enable a boot time option and it only lasts for that boot.

Ok for development, ng for users.

The signing problem is only Vista right?

I have an unsigned driver we use with one of our products that just
gives the warning message... hit continue and all is fine

tom

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd, ftd2xx

[Zach Welch]

On Wed, 2009-06-24 at 20:14 +0100, Ian Guffick wrote:
> 
> > Here is the full list of GPL-compliant solutions for libftd2xx GPL
> > compliance, after further review, consideration, and enumeration:
> >
> > 1) Documentation:  build it yourself!
> > 2) Build-Kit: automate the build on users' machines
> > 3) XXX: to be revealed, if legal
> > 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx
> > 5) sockets: separate ftd2xx into their own process space
> > 6) libusb+libftdi: The Right Thing To Do ;)
> >
> 
> 
> Just a thought on option 2 - the build kit.
> This would be a large download, and quite a lot of work for someone to put 
> together.
> If the GPL violation happens in distributing code that is linked to FTD2XX, 
> could the build kit have pre-compiled objects for openocd - that are then 
> linked on the users machine. The pre-compiled objects, as distributed, would 
> not be linked to FTD2XX. This would reduce the complexitiy of the build kit 
> down to a much simpler 'link-kit'. It's function would be no different to 
> the build kit.
> I haven't looked into it but maybe this could be as simple as a few object 
> files, LD and a few MingW libraries along with a batch file.

I think it will take a little bit more effort than this (some autotools
magic to ensure users can build different configurations), but this is a
great idea for reducing the download sizes.  In many ways, it sounds a
bit like using ccache; once the cache is populated, you only ever link.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd, ftd2xx

[Ian Guffick]

> Here is the full list of GPL-compliant solutions for libftd2xx GPL
> compliance, after further review, consideration, and enumeration:
>
> 1) Documentation:  build it yourself!
> 2) Build-Kit: automate the build on users' machines
> 3) XXX: to be revealed, if legal
> 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx
> 5) sockets: separate ftd2xx into their own process space
> 6) libusb+libftdi: The Right Thing To Do ;)
>


Just a thought on option 2 - the build kit.
This would be a large download, and quite a lot of work for someone to put 
together.
If the GPL violation happens in distributing code that is linked to FTD2XX, 
could the build kit have pre-compiled objects for openocd - that are then 
linked on the users machine. The pre-compiled objects, as distributed, would 
not be linked to FTD2XX. This would reduce the complexitiy of the build kit 
down to a much simpler 'link-kit'. It's function would be no different to 
the build kit.
I haven't looked into it but maybe this could be as simple as a few object 
files, LD and a few MingW libraries along with a batch file.

BR,
Ian.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd, ftd2xx

[Zach Welch]

On Wed, 2009-06-24 at 19:20 +0200, Dominic wrote:
> Hello Zach,
> 
> 
> 
> thank you for this posting. I was just formulating a reply to some of
> your last emails, but it's probably better if what I had to say
> remains in the privacy of my harddrive.

Since you have said that, I am intensely curious.  Too many of mine die
a similar death, and it could be something to share a laugh over... in a
year or two. ;)

> On Wednesday 24 June 2009 18:30:09 Zach Welch wrote:
> > Hi all,
> >
> > Here is the full list of GPL-compliant solutions for libftd2xx GPL
> > compliance, after further review, consideration, and enumeration:
> >
> > 1) Documentation: build it yourself!
> > 2) Build-Kit: automate the build on users' machines
> 
> 
> 
> I fear those aren't options for the average Windows user of the
> OpenOCD. Michael's packages were extremely popular because they were
> very easy to use.

I am not convinced; I really feel that a build-kit is doable.  I feel
confident, but it is by far not an realistic case for any serious
deployments.  The downloads would be unreasonably large... and all that
wasted CPU time.  And this, coming from a Gentoo user. ;)

> > 3) XXX: to be revealed, if legal
> 
> 
> 
> Is this some particular solution or a placeholder for things we
> haven't yet thought of?

Very specific.  I just thought of it as a result of these threads, but I
do not want to get the community's hopes up in the event that it turns
out to be false hope.  However, I will warn that it is build-kit related
and remains difficult to scale reasonably well; again, far from ideal.

> > 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx
> 
> 
> 
> How would ftd2xx be linked here? Via LoadLibrary (dlopen) and friends?
> I'd volunteer to create such a solution.

We build and distribute: OpenOCD -> libftdi

Users would download and install libftdi-ftd2xx *instead* of libftdi.

Since they have the same ABI, the application cannot tell the difference
between the open and closed versions.

OpenOCD binaries cannot legally be distributed with the wrapper, only
with the the normal libftdi.  They should behave the same in all outward
function ways; there cannot be any conditional code in OpenOCD to enable
the wrapper library.

I think that will work.  I am not _entirely_ sure, but others can ACK.

> > 5) sockets: separate ftd2xx into their own process space
> 
> 
> 
> I dislike this idea, and I seem to remember that you disliked it, too,
> because it opens doors for all kinds of GPL circumventions that we
> don't want. We may not be able to prevent someone from creating such a
> solution, but we can deny its upstream inclusion.

The genie is out of the bottle.  We can create a GPL implementation, and
force the proprietary versions to re-implement the driver-side handling
themselves.  It would be "nicer" to the FTD2XX folk if we licensed the
driver-side bits under LGPL... but it appears that neither of us want to
be "nice" on this matter.  Hurray!  We're on the same team. :)  Go team!

> > 6) libusb+libftdi: The Right Thing To Do ;)
> 
> 
> 
> Is this something that's future proof with Microsoft's
> signed-drivers-only policy coming up?

We can raise money to pay for the signing costs; presumably, they don't
need to be signed during development testing.  

Personally, I think the broader community will end up footing these
bills; however, these factors need to be considered by the community in
complete detail once the technical details are worked out.  

After hearing all of the reports induced by the licensing threads, I am
afraid that we may have a bit of work to do before we need to worry
about signed drivers, sadly; however, I cannot judge the actual status
-- our Windows developers need to do that.

I asked Michael Fischer in a private e-mail to send me a patch for the
TODO list to include all of the things we need to finish this support,
but others on the list may have been more appropriate to ask. :)

[snip]
> > To reiterate, I am now no longer willing to accept offers to do the
> work
> > that I actually need to survive, to demonstrate that my motives here
> > have no profit in them anymore. All previous offers for me to do
> paid
> > work are now off the table, until all hostilities from the community
> > have been ameliorated. I hope this action helps resolve some
> tensions.
> 
> 
> 
> This is for you to decide. I'd actually appreciate if you were to
> rethink your position, because a developer whose able to make at least
> part of his living out of the project is definitely going to provide
> high qualtiy contributions.
> 

I appreciate you allowing me to do so.  I will post another message to
restate my position in a way that should both better clarify my original
intent but still allow me to survive.

And it will take things to a whole... other level ;) :)

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.be

Re: [Openocd-development] proposed FASTDATA bulk write optimization for mips_m4k file transfers

[Øyvind Harboe]

I'm itching to apply any patches on MIPS4K, but I can't really
dive into MIPS support and provide useful feedback

Part of my job description in OpenOCD is to be a recruiter
and we're desperately short on active MIPS target
experts.

So if anyone out there have opinions about MIPS target code,
you've been warned that I'll give this a cursory look and then commit it
if I hear nothing in a day or two.


-- 
Ø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

[Openocd-development] proposed FASTDATA bulk write optimization for mips_m4k file transfers

[David Claffey]

Attached is a proposed bulk write optimization for mips_m4k file transfers. The
motivation was to speed-up image loading on the mips_m4k target to reach similar
transfer times as the xscale target.

Files modified:
M2399   src/target/mips32.h
M2399   src/target/mips_ejtag.c
M2399   src/target/mips32_pracc.c
M2399   src/target/mips_ejtag.h
M2399   src/target/mips32_pracc.h
M2399   src/target/mips_m4k.c

Summary:

Bulk transfers are currently done with word accesses using the PrAcc data
register.  This optimization uses a working-area, if available, to load a
download routine into ram.  The download routine uses EJTAG FASTDATA transfers
to transfer the data.  This greatly decreases load times because:
 - code fetches are no longer through the PrAcc register, the code is executing
in ram.
 - stack is also in the working-area
 - Use of only the FASTDATA register minimizes JTAG access.
 - the call to jtag_execute_queue() is made only after building the entire
buffer transfer queue.

The idea is taken from the xscale debug_handler loaded into a mini instruction
cache. The mips_m4k does not have a convenient place to load a download routine
like the xscale's mini IC.  Instead this patch has been tested with a
working-area in system ram. This requires that the external memory controller be
initialized, most commonly in a board script. The alternative is to lock enough
ways in the instruction cache to make an internal code area.  But the system ram
approach is simpler and allows full use of the cache for the program under
debugging.

If a working area is not defined, the code will work as before; bulk writes will
issue a series of word writes that uses the PrAcc data register.

This only affects bulk memory writes; byte, short and word accesses still use
the PrAcc data register.

There is support for FASTDATA bulk reads. However, there is currently no
bulk_read_memory equivalent for bulk_write_memory.

I have probably missed some problems with this approach or it's methods.  Still
this code builds and runs and the result is file transfers times decrease
dramatically.

> load_image boot-ram.bin 0xa050
mips32_pracc_fastdata_xfer using 0xa0001000 for write handler

253424 byte written at address 0xa050
downloaded 253424 byte in 3.110119s

- David

Index: src/target/mips32.h
===
--- src/target/mips32.h (revision 2399)
+++ src/target/mips32.h (working copy)
@@ -78,6 +78,7 @@
 #define MIPS32_OP_ADDI 0x08
 #define MIPS32_OP_AND  0x24
 #define MIPS32_OP_COP0 0x10
+#define MIPS32_OP_JR   0x08
 #define MIPS32_OP_LUI  0x0F
 #define MIPS32_OP_LW   0x23
 #define MIPS32_OP_LBU  0x24
@@ -104,6 +105,7 @@
 #define MIPS32_B(off)  MIPS32_BEQ(0, 0, off)
 #define MIPS32_BEQ(src,tar,off)MIPS32_I_INST(MIPS32_OP_BEQ, 
src, tar, off)
 #define MIPS32_BNE(src,tar,off)MIPS32_I_INST(MIPS32_OP_BNE, 
src, tar, off)
+#define MIPS32_JR(reg) MIPS32_R_INST(0, reg, 0, 0, 0, 
MIPS32_OP_JR)
 #define MIPS32_MFC0(gpr, cpr, sel) MIPS32_R_INST(MIPS32_OP_COP0, 
MIPS32_COP0_MF, gpr, cpr, 0, sel)
 #define MIPS32_MTC0(gpr,cpr, sel)  MIPS32_R_INST(MIPS32_OP_COP0, 
MIPS32_COP0_MT, gpr, cpr, 0, sel)
 #define MIPS32_LBU(reg, off, base) MIPS32_I_INST(MIPS32_OP_LBU, base, reg, 
off)
Index: src/target/mips_ejtag.c
===
--- src/target/mips_ejtag.c (revision 2399)
+++ src/target/mips_ejtag.c (working copy)
@@ -4,6 +4,8 @@
  * *
  *   Copyright (C) 2008 by David T.L. Wong *
  * *
+ *   Copyright (C) 2009 by David N. Claffey   *
+ * *
  *   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 *
@@ -146,6 +148,46 @@
return ERROR_OK;
 }
 
+int mips_ejtag_fastdata_scan(mips_ejtag_t *ejtag_info, int write, uint32_t 
*data)
+{
+   jtag_tap_t *tap;
+   tap  = ejtag_info->tap;
+
+   if (tap==NULL)
+   return ERROR_FAIL;
+
+   scan_field_t fields[2];
+   uint8_t spracc = 0;
+   uint8_t t[4] = { 0,0,0,0 };
+
+   /* fastdata 1-bit register */
+   fields[0].tap = tap;
+   fields[0].num_bits = 1;
+   fields[0].out_value = &spracc;
+   fields[0].in_value = NULL;
+   
+   /* processor access data register 32 bit */
+   fields[1].tap = tap;
+   fields[1].num_bits = 32;
+   fields[1].out_value = t;
+
+   if (write)
+   {
+   fields[1].in_value = NULL;
+   buf_set_u32

Re: [Openocd-development] Creative summary of options for OpenOCD distros

[Michael Schwingen]

Freddie Chopin wrote:
> 2. Modular OpenOCD which would allow binary "drivers" to be used (just 
> as the drivers are used in Linux kernel)
>
> PRO - possibility to use closed-source drivers (same as above), no need 
> for running additional software other than OpenOCD, no speed penalty of 
> the medium
>   
What kind of module interface do you envision that would avoid the 
problems which we currently have with the FTD2XX library?

The drivers would have to run in a separate process space, which means

Note: Linux kernel modules need to be GPL, too - the only way to have 
non-GPL drivers in Linux is to have userspace drivers, which are quite 
limited in capabilities.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[Dominic]

On Wednesday 24 June 2009 19:04:37 Zach Welch wrote:
> Are you any of those things, today?  Is he contributing, today?
>
> > Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004 (with
> > 1-2 years or more of intensive coding)
>
> I do want to be clear that I do value and respect his contributions and
> his copyrights, and I welcome both of you to continue contributing to
> the OpenOCD community in the future.
>
> However, neither he nor you have contributed much constructive lately,
> which means you have effectively abdicated your authority in the
> community.  In an open source community, that authority derives from
> being a responsible and active contributor.  Does this seem reasonable?

The OpenOCD was and always will be my project. I'm constantly following the 
list, although I'm not able to read each and every post, especially when the 
number of messages explodes like it did recently.

I'm voicing my concerns when I see changes that interfere with some key design 
ideas that were part of the original code I released. The last issue was the 
removal of the asynchronous in handlers, which were then reinstalled in a 
different way but achieving essentially the same goal which was fine with me. 
I do think it is important to point out how I wanted some things to be used 
when this isn't clear from the code.

I saw speculations about what I might have intended which is when I first 
responded to the current issue. Being the one who followed the project from 
its very beginning I believe I do know some things that others may have missed 
or never heard about.

Regards,

Dominic
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Wookey]

+++ Freddie Chopin [2009-06-24 16:56 +0200]:
> David Brownell pisze:
> > Under the GPL.  From the very first public release, that has been
> > part of it.  You download it, and the GPL is there.  That brings
> > along with it certain rules.
> 
> GPL. GPL. GPL... How about Users, Users, Users? Again - The Most 
> Important Qestion - Is OpenOCD meant for users to use, or just to be 
> "100%-GPL-at-any-cost"?

The GPL protects _users_ rights (even over developer's rights, if you
want to make a distinction) over the long term - that's why it's
so popular. 

> > You're the ONLY one advocating a "we-don't-care-for-X" mindset.
> 
> Damn, I see that the opposite way - 5-10 ppl are "100% GPL" (that's 
> where you are) while everyone else is like "why create artificial 
> problems?".

I am 'just a user' of openOCD (I've contributed a good 6 lines of
code/docs so far), and I think the GPL is important too. David
Brownell has put the arguments very clearly and correctly (amongst
others). So please don't count all users in your camp, and I think
you'll find it's a lot more than 5-10.

We need to just fix the problem for users (by getting a
licence-compatible USB driver for windows people who currently don't
have one).

Please stop trying to pretend there isn't a problem and be grateful
that there has been some laxness in the past - that's a benefit you've
had to date. Now it's been noticed (perhaps an understatement!) you
and others will find things slightly less convenient for a while,
until a proper permanent fix is in place. That will happen a lot
quicker if a) this discuession dies down and b) there is some
incentive to get it fixed (i.e. using free code is more conventient
than using non-free code).

Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] openocd, ftd2xx

[Dominic]

Hello Zach,

thank you for this posting. I was just formulating a reply to some of your 
last emails, but it's probably better if what I had to say remains in the 
privacy of my harddrive.

On Wednesday 24 June 2009 18:30:09 Zach Welch wrote:
> Hi all,
>
> Here is the full list of GPL-compliant solutions for libftd2xx GPL
> compliance, after further review, consideration, and enumeration:
>
> 1) Documentation:  build it yourself!
> 2) Build-Kit: automate the build on users' machines

I fear those aren't options for the average Windows user of the OpenOCD. 
Michael's packages were extremely popular because they were very easy to use.

> 3) XXX: to be revealed, if legal

Is this some particular solution or a placeholder for things we haven't yet 
thought of?

> 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx

How would ftd2xx be linked here? Via LoadLibrary (dlopen) and friends? I'd 
volunteer to create such a solution.

> 5) sockets: separate ftd2xx into their own process space

I dislike this idea, and I seem to remember that you disliked it, too, because 
it opens doors for all kinds of GPL circumventions that we don't want. We may 
not be able to prevent someone from creating such a solution, but we can deny 
its upstream inclusion.

> 6) libusb+libftdi: The Right Thing To Do ;)

Is this something that's future proof with Microsoft's signed-drivers-only 
policy coming up?

> I have lost track of who is doing what.  Please check in here. :)
>
> Furthermore, I had originally hoped to make some money by volunteering
> here, then finding sponsors for further work.  I now have serious doubt.
>
> I will not take any money for the current compliance effort.  Sadly, I
> no longer think it would be safe to accept any compensation for such
> work, even if it were going to be offered to me.  Sorry.  Such could
> only aid others in baseless accusations of "extortive" motives being
> part of my intentions for enforcing the GPL at this juncture.  That is
> simply not true, and I would point out that I did not even raise the
> original issue.  Still, I will fall on my sword to do the right thing.
>
> To reiterate, I am now no longer willing to accept offers to do the work
> that I actually need to survive, to demonstrate that my motives here
> have no profit in them anymore.  All previous offers for me to do paid
> work are now off the table, until all hostilities from the community
> have been ameliorated.  I hope this action helps resolve some tensions.

This is for you to decide. I'd actually appreciate if you were to rethink your 
position, because a developer whose able to make at least part of his living 
out of the project is definitely going to provide high qualtiy contributions.

Best Regards,

Dominic
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[Zach Welch]

On Wed, 2009-06-24 at 14:27 +0200, Laurent Gauch wrote:
> >
> > On Wed, 2009-06-24 at 12:20 +0200, Dominic Rath wrote:
> > >/ This goes inentionally to you alone, feel free to bring it up on the 
> > >list if you want...
> > />/ 
> > />/ > You have made me start to wonder if it would be possible to bring some
> > />/ > sort of claim of "misrepresentation" against the project authors, were
> > />/ > your suggestion to be taken by others.  The COPYING file is the 
> > standard
> > />/ > way of notifying potential authors of a project's license, so I think
> > />/ > that I would have a good chance of proving that the authors neglected 
> > to
> > />/ > inform authors -- whether by intention or accident.
> > />/ 
> > />/ I suppose that means I have to remove all code you've contributed from
> > />/ the repository in order to protect myself from what you might or might
> > />/ not do. I will also have to ask all distributors to remove any version
> > />/ since january 2009.
> > /
> > Actually, that would no longer be acceptable; you are welcome to fork
> > the code, but I ask that you avoid making such changes.  The license is
> > and was GPL, and I am now a copyright holder, maintainer, and active
> > contributor to the project.  You would be taking a unilateral action
> > that would not be uniformly supported by the OpenOCD community, whereas
> > I am asserting my individual copyrights.  I can do what I have done, but
> > the community should vote to exile my changes.
> >   
> 
> You maybe are holder, maintainer, contributor ... but you are not the 
> CREATOR / AUTHOR !

Are you any of those things, today?  Is he contributing, today?

> Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004 (with 
> 1-2 years or more of intensive coding)

I do want to be clear that I do value and respect his contributions and
his copyrights, and I welcome both of you to continue contributing to
the OpenOCD community in the future.

However, neither he nor you have contributed much constructive lately,
which means you have effectively abdicated your authority in the
community.  In an open source community, that authority derives from
being a responsible and active contributor.  Does this seem reasonable?

Tying back into copyright, your authority over the copyrights for your
own respective contributions will continue to be respected, in so far as
it was expressly written into the repository -- they were released under
the GPL without any exceptions.  If you or anyone provides sound legal
arguments that can refute this claim, I will back off on this assertion.

>From what I now understand, you had been enjoying dual-licensing by the
original author.  Unfortunately, that arrangement appears to have ceased
to have a legal foundation once the repository accepted contributions
from others -- without securing copyright assignments.  At that point,
any binaries that were produced from those derived works appear to have
violated the GPL.  This is how it appears to me.

As I have been trying to do for others for whom the OpenOCD project
provides part of your revenue stream, I encourage you to discuss these
matters with your legal counsel.  I would be very interested if any
responses from these individuals conflict with the assessment that I
have been making of the situation; I will be asking the FSF for their
opinions on these matters.

> I was myself a contributor to the project, but before there ais SVN ! 
> Yes, strange for you.
>
> But I am a contributor too.

I understand that you presently sell dongles and make money from them.
Do you plan to contribute directly (with patches) or indirectly (with
funding) to help the community solve the current problems?  To be clear,
you have no obligation to do so, just as we have no obligation to help
commercial distributors fix the problems that this licensing SNAFU may
have caused.

However, I _am_ willing to help those who show an effort to work toward
constructive solutions, as I do feel terrible for the angst that this
situation has caused the community.  I will be sure that we provide a
solution for the community, but it may not be good enough for you to use
in terms of delivery schedule or performance.

> What 'project contribution' means for you?
> - Adding a lot of patches
> - Donating hardware to end-users
> - Building binary for easy-of-use
> - Reading the forum
> - Writing to the forum
> - Documenting the project
> - ...

Yup.  All those things, and copyright protects all "fixed" works.  

> All these tasks were needed to bring OpenOCD as it is actually.

I have done all of those tasks myself to bring up free software
communities.  I know it is generally a lot of thankless work, so I do
want to generously thank you and all those that helped the community
make the project what it is today.  Your work has been appreciated.

> Each project/products needs manager - developer - tester - distributor - 
> end-userS
> The end-users know what they need.

Not always, but 

Re: [Openocd-development] Summer coding project proposal

[Zach Welch]

On Wed, 2009-06-24 at 17:53 +0100, John Devereux wrote:
> Zach Welch  writes:
> 
> > On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote:
> >> Simple project for a CS student.
> >> 
> >> A wrapper with a libftdi interface calling libftd2xx, as a project using 
> >> a LGPL  license
> >> 
> >> So any user can take their binary copy of OpenOCD linked against libftdi 
> >> and simply replace  the libftdi dll file, no need to play with system 
> >> files or drivers.
> >> 
> >> Is  such a library  illegal ? Who would have standing to complain ?
> >
> > You are doing it to circumvent the GPL.  I think that is illegal.
> 
> IMO "circumvent" is indistinguishable from "comply with". That is, it is
> a way of achieving some goals while remaining within the terms of the
> GPL.
> 
> > You would be contravening this copyright holder's intention, which would
> > make you liable for any possible infringement that I could show.
> 
> Now it you you who wants to ignore the actual terms of the license, and
> substitute your own intentions. 
> 
> > Furthermore, I think individuals can be held liable for "inducing"
> > infringement, which is where IANAL becomes useful in some respects.
> 
> Have you considered a career with the RIAA?...
> 
> [...]

Have you read my further replies to that thread?

I recanted.  Now... are you trolling, or was that an honest mistake? :)

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [patch] openocd.texi - fixes from sam3 update

[Øyvind Harboe]

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] Summer coding project proposal

[John Devereux]

Zach Welch  writes:

> On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote:
>> Simple project for a CS student.
>> 
>> A wrapper with a libftdi interface calling libftd2xx, as a project using 
>> a LGPL  license
>> 
>> So any user can take their binary copy of OpenOCD linked against libftdi 
>> and simply replace  the libftdi dll file, no need to play with system 
>> files or drivers.
>> 
>> Is  such a library  illegal ? Who would have standing to complain ?
>
> You are doing it to circumvent the GPL.  I think that is illegal.

IMO "circumvent" is indistinguishable from "comply with". That is, it is
a way of achieving some goals while remaining within the terms of the
GPL.

> You would be contravening this copyright holder's intention, which would
> make you liable for any possible infringement that I could show.

Now it you you who wants to ignore the actual terms of the license, and
substitute your own intentions. 

> Furthermore, I think individuals can be held liable for "inducing"
> infringement, which is where IANAL becomes useful in some respects.

Have you considered a career with the RIAA?...

[...]


-- 

John Devereux
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] openocd, ftd2xx

[Zach Welch]

Hi all,

Here is the full list of GPL-compliant solutions for libftd2xx GPL
compliance, after further review, consideration, and enumeration:

1) Documentation:  build it yourself!
2) Build-Kit: automate the build on users' machines
3) XXX: to be revealed, if legal
4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx
5) sockets: separate ftd2xx into their own process space
6) libusb+libftdi: The Right Thing To Do ;)

I have lost track of who is doing what.  Please check in here. :)

Furthermore, I had originally hoped to make some money by volunteering
here, then finding sponsors for further work.  I now have serious doubt.

I will not take any money for the current compliance effort.  Sadly, I
no longer think it would be safe to accept any compensation for such
work, even if it were going to be offered to me.  Sorry.  Such could
only aid others in baseless accusations of "extortive" motives being
part of my intentions for enforcing the GPL at this juncture.  That is
simply not true, and I would point out that I did not even raise the
original issue.  Still, I will fall on my sword to do the right thing.

To reiterate, I am now no longer willing to accept offers to do the work
that I actually need to survive, to demonstrate that my motives here
have no profit in them anymore.  All previous offers for me to do paid
work are now off the table, until all hostilities from the community
have been ameliorated.  I hope this action helps resolve some tensions.

Sincerely,

Zach Welch
Corvallis, OR

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Creative summary of options for OpenOCD distros

[Freddie Chopin]

OK - be creative. End the flames, throw some ideas. Here goes another 
summary of REALISTIC and ACCEPTABLE options, if ftd2xx.dll will still be 
"censored" in the distributions.

1. Any kind of network protocol that would talk to "driver".

PRO - Possibilities to use JTAGs over internet to debug remotely, 
possibility to use closed-source drivers (for me that's a pro [; )

CONS - latency of the medium, need to run another program on one's PC, 
someone has to create the program and that has to be more complicated 
than the one from option 2.

2. Modular OpenOCD which would allow binary "drivers" to be used (just 
as the drivers are used in Linux kernel)

PRO - possibility to use closed-source drivers (same as above), no need 
for running additional software other than OpenOCD, no speed penalty of 
the medium

CONS - someone would have to create the "driver" (this would be much 
easier than in option 1)

3. Creating a libftdi replacement dll that would mimic libftdi API but 
use ftd2xx.dll (propsed by Magnus Lundin in a separate thread)

PRO - probably easiest of solutions, no speed penalty, no need for 
additional software

CONS - user has to KNOW about that to use the replacement, APIs of 
ftd2xx.dll and libftdi.dll are probably not 100% compatible (?)

(the PRO and CONS are not complete of course, just as there maybe more 
solutions).

Personally I think that options 1 and 2 should be introduced anyway, 
because they are good (especially option 1 is very interesting!). For 
the short term solution I think option 3 would be quite OK, we can all 
agree to kill that once a better solutions exist.

I'm willing to help with any of those, but - as I'm not a hard-core PC 
programmer, that help would probably by minor compared to others.

Please - don't throw any suggestions like "I'll do it for $$$" here.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Zach Welch]

On Wed, 2009-06-24 at 08:34 -0700, Zach Welch wrote:
> On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote:
> > On Wed, Jun 24, 2009 at 13:29, Zach Welch wrote:
> > > On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote:
> > >> On Wed, Jun 24, 2009 at 11:42, Zach Welch wrote:
> [snip]
> > >> There is no infringement here, so there is nothing to debate. The
> > >> issue gets a bit murky when the replacement dll is bundled with
> > >> OpenOCD, but that is not really necessary, the user can load it from
> > >> elsewhere.
> > >
> > > The intention to design this library for the purpose of circumventing
> > > the GPL is being documented on this list.  Sure, it's murky, but the
> > > discussion only helps to build my case to defend against this option.
> > 
> > Your premise is wrong. The user is not restricted in what he can do
> > with the software on his PC. This is crystal clear from the license
> > and the FAQ. You can do all sorts of kinky stuff with the software in
> > the sanctity of your hard drive, if you want to flip all bits or
> > increment all jump addresses by 13 or replace a DLL, that is your
> > right under the GPL.
> 
> First, thank you!  Yours has been one of the most pleasurable threads to
> engage in among these topics, and you have responded exactly as merited.
> 
> Second, you win!  You presented -- clearly -- the reasonable case for
> why this should be allowed.  I sincerely apologize for taking the
> contrary view on this particular idea; your points above nailed me to
> the tree!  It _is_ okay to produce a libftdi-ftd2xx wrapper package that
> is ABI compatible with the open source libftdi.  Mea culpa.  

To the community:

Just so everyone is absolutely clear: neither my original opinion nor
this one have any legal weight regarding compliance.  In fact, the FSF
may _not_ agree with my interpretation of this very particular
situation, though I would love to hear those arguments too.

Personally, you have me convinced, so that should be enough for the
community to move forward; however, anyone with a serious stake (i.e.
commercial vendors) should assume that other copyright holders may later
chose to try and cause trouble.  My own present willingness to see this
as valid should still be insufficient for the legally cautious.

Others could come along, obtain their own GPL derived-work copyright
claims, and then demand ransom from the community -- because you have
allowed yourself to distribute a solution that cannot be defended in
absolute terms.  Gray areas suck.  I would expect any lawyer working in
your interests to advise you to avoid them.  However, I again think that
Michael made this solution black-and-white to me (or white-and-black?),
but I hope no one simply takes our words for it.  We're not lawyers.
Clearly.  We would be billing hours, not posting here!

There is no defense other than full compliance, which needs to be fully
vetted by your own independent legal counsel.  Not me.  If you want to
protect yourself from future threats fully, you should be sure your
measures will ensure you never have compliance problems again.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Can we get back to forward progress?

[David Brownell]

On Wednesday 24 June 2009, Thomas A. Moulton wrote:
> ps. let's let the old threads die

Good suggestions, all.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

David Brownell pisze:
> "Users" that have only invective to "contribute" aren't
> helping the community.

You have clearly mistaken me for someone else, so I'll just end this 
particular thread.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

[David Brownell]

On Wednesday 24 June 2009, Freddie Chopin wrote:
>  > See ... how your first "no explanation" whine was in fact
>  > fully addressed at the very beginning of the flamewar you
>  > have been feeding.
> 
> Let's not forget who ignited that whole "war". You.

Erm, not at all.  *YOU* have been the primary flame-thrower.
Confrontational, and very unpleasant.

My original post on the question (cripes, only ten days ago) was:

  https://lists.berlios.de/pipermail/openocd-development/2009-June/007971.html

I think that if you read that, you will notice nothing at
all warlike ... just the simple observation -- which nobody
has disproved -- that one distribution scheme violates the
current license, so we should probably remove some text that
suggests otherwise.  Not confrontational.

It was *your* contributions to that thread, and later ones,
which started a flamefest from a simple doc bugfix.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD license

[Ronald Vanschoren]

> Having said this I don't understand how you (or anyone sensible)
could support 
> violating licenses. Do you have the habit of breaking laws for the
sake of it?

Please show me the exact lines in GPL v2 that _clearly_ say linking
FTD2xx with OpenOCD is a violation of the license. If one binary
version of OpenOCD can work without the library (using the other
interfaces) and only enable FTD2XX support when the library is present
there is NO issue. FTD2XX is NOT a derived work of OpenOCD so it should
NOT be licensed as GPL, end of story! How did Java GPL applications
work in the past then (before Java was open source)? It links to DLL's,
a VM,... I couldn't  make modifications to standard Java classes either.

This has nothing to do with breaking the law for the sake of it, this
has to do with people having hidden agendas and trying to hide behind
the most gray are in software history. Be honest and tell us what this
is all about.

> This is not a theoretic issue

I really don't understand how this is not a theoretic issue. Is someone
getting sued? If not, it's theoretic.

> GPL is the license and it states that whatever you link 
> against and distribute should respect GPL freedom

Again: show me the line in GPL v2. The whole license doesn't use the
word "link" once. Don't even try to send a link to the FAQ, that's ONE
interpretation, not legally binding whatsoever.

> You can do things about this, for instance persuading FTDI to free
the 
> FTD2xx driver source and relicense it with GPL


Good luck, they don't care.

> You wouldn't be able to do modifications on the FTD2xx library, so
no point 
> for this.


You also wouldn't be able to modify it using any of the options in the
various threads. If you can live with working around the violation (at
least what you interpret as a violation) then why bother? The end
result will be the same: People will use OpenOCD and FTD2xx and FTD2xx
will NOT be GPL. Why make it more difficult for people to do this?

> If you (or others) are so interested in a license change, then
answer this 
> questions:


Personally I'm not asking for a license change. My interpretation of
GPL says linking to FTD2xx is not a violation.

> What I don't understand so far is why it is so important to add an
exception 
> to the license instead of:
>
> Improving free FTDI library

Please do, it'll take a long time as far as I understand the people who
could know.

> Asking FTDI to release and free the FTD2xx library

Never gonna happen...

> Make people interested in running FTD2xx build his own copy/binary
of openocd

That's actually what I do, I personally don't care about this
discussion as worst case I'll build my own version. What does bother me
is that other people will have to do the same and might not be able to.
Also the risk is real that FTD2xx support will get lost over the years
because nobody actively maintains/tests it as it's not an official
feature.

gr.

Ronald







 Original Message  
Subject: [Openocd-development] OpenOCD license
From: Raúl Sánchez Siles 
To: openocd-development@lists.berlios.de
Date: Wed Jun 24 2009 16:55:32 GMT+0200 (Romance Standard Time)

Hello:

   I'll just participate in this horrible flame once.

On Wednesday 24 June 2009 14:02:26 Ronald Vanschoren wrote:
  
  

  it sucks to have to be the one to push for license
compliance like this
  

Then don't! I'm just a user of OpenOCD so you have all right to ignore what
I'm saying as you'll find that I'm less important, but it's about time
people here start to realize the real "clients" are users and not
developers and users don't give a sh*t about GPL violations.

  
  
  You are not less important, you are just another kind. "Clients" are 
important as well, just that you (we) don't pay for using the software. Having 
said this I don't understand how you (or anyone sensible) could support 
violating licenses. Do you have the habit of breaking laws for the sake of it?

  
  
Why would anyone want to waste time and effort on fixing this purely
theoretic issue? Use the time to implement useful features like SWD or
threadsupport instead.

You're acting like you have no choice but to point out this issue and write
700 mails about it. You of all people can fix it easily. Give up your
copyright or allow relicensing it under anything that is not as gray and
debatable as GPL.

  
  
  I don't think enforcing one's rights is loosing time. This is not a 
theoretic issue. GPL is the license and it states that whatever you link 
against and distribute should respect GPL freedom, among others, being able to 
get the source code.

  You can do things about this, for instance persuading FTDI to free the 
FTD2xx driver source and relicense it with GPL or any other compatible license 
for the issue: adm...@ftdichip.com

  
  
As a sidenote I still don't see the issue. The spirit of GPL is to allow to
make modifications to an application that is distributed in b

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Wednesday 24 June 2009, Freddie Chopin wrote:
> > Notice the complete disregard of technical arguments here.
> > 
> > That's a good sign that the person making the argument has no real
> > contribution to make, beyond invective.
> 
> That's probably because I'm a USER, not a contributor. Quite simple.

"Users" that have only invective to "contribute" aren't
helping the community.  They make things be unpleasant;
which makes some people leave, or otherwise help less.

On the other hand, some of the best development partners
I've ever had were from the "user" side of the relationship.

Needless to say, invective wasn't a primary contribution;
nor were demands that all giving be onesided (me to them).


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Zach Welch]

On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote:
> On Wed, Jun 24, 2009 at 13:29, Zach Welch wrote:
> > On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote:
> >> On Wed, Jun 24, 2009 at 11:42, Zach Welch wrote:
[snip]
> >> There is no infringement here, so there is nothing to debate. The
> >> issue gets a bit murky when the replacement dll is bundled with
> >> OpenOCD, but that is not really necessary, the user can load it from
> >> elsewhere.
> >
> > The intention to design this library for the purpose of circumventing
> > the GPL is being documented on this list.  Sure, it's murky, but the
> > discussion only helps to build my case to defend against this option.
> 
> Your premise is wrong. The user is not restricted in what he can do
> with the software on his PC. This is crystal clear from the license
> and the FAQ. You can do all sorts of kinky stuff with the software in
> the sanctity of your hard drive, if you want to flip all bits or
> increment all jump addresses by 13 or replace a DLL, that is your
> right under the GPL.

First, thank you!  Yours has been one of the most pleasurable threads to
engage in among these topics, and you have responded exactly as merited.

Second, you win!  You presented -- clearly -- the reasonable case for
why this should be allowed.  I sincerely apologize for taking the
contrary view on this particular idea; your points above nailed me to
the tree!  It _is_ okay to produce a libftdi-ftd2xx wrapper package that
is ABI compatible with the open source libftdi.  Mea culpa.  

I am sorry to Magnus, you and the community for this unintentional
oversight; I _really_ hope that I did not miss this suggestion from
someone else, much earlier in these threads.  You now have me second
guessing myself on that!  There has been too much action, and too many
intentions to avoid the GPL entirely.  Lacking such clear arguments, I
may have shot them down prematurely, but I hope that is not the case.

To be truthful, I think my original replies involved my continuing to
think about the ftd2xx ABI, its restrictions, and a wrapper for that ABI
(which doesn't even make sense, in hindsight).  I am very glad that you
pursued this matter to its fullest and kept my attention on it in a
respectful way, and I am sorry if my earlier messages failed to return
those favors.  It was after 2am when I got the first message in this
thread; it's 8am now.  It has been a full day, and my desire to be
highly responsive to the community has started to become a double-edged
sword at this point.  Even as such, you managed to help resolve this.

I _really_ wish everyone would come at these issues with the same kind
of lucidity as you have demonstrated.  So, again, thank you.  There is
now another option for the community to consider, which is lower hanging
and probably more appealing for most distributors.

[snip]
> > In addition to that solution, I have pointed out that libusb and libftdi
> > features and performance can be improved.  The community can try to get
> > FTDI to go LGPL with their code.  There is also a "build kit", which
> > creates user-built binaries; this should produce the same binaries they
> > were getting before this "problem", so there would be zero performance
> > impact to users (other than a longer install process).
> >
> > Altogether, this puts four options on the table, all of which still seem
> > realistic to me.  Can you show me concrete evidence to the contrary?
> > The build kit solves the problem completely, and that kind of tool does
> > not seem like a difficult challenge for an experienced developer.
> 
> Having to build OpenOCD yourself is a significant obstacle to wider
> distribution.
> 
> The libusb improvements certainly sound interesting, however no one
> has stepped forward to implement them or to pay someone to implement
> them. They may or may not also require some reverse engineering plus
> extensive profiling that would make them more time-consuming than the
> wrapper. So they don't seem like a near-term solution at the moment.

Others have stated emphatically that the specifications are open and
available for the developers to take a whack at replacing their library.
Unless it is incomplete or inaccurate, the matter should be
straightforward enough.  :)  Heh.

I would love to help fix it, but I am constrained in ways that I have
previously expressed but will not repeat out of modesty and respect.

> > I have come up with another new idea, but I need to vet it with the FSF
> > before I suggest it here.  I _may_ have found a new loophole (related to
> > the build kit), but I am very uncertain about its legality.  Heck, I may
> > ask the FSF to pay me to bury it forever, if it is truly novel!  ;)
> > While it would improve things a little, I do not want to get hopes up.
> 
> Given that you are in the USA you could probably patent it as a
> business method and prevent anyone from using it or collecting money
> for it.

Good idea.  Thanks  Heh, just kiddin

Re: [Openocd-development] FT2232 & Windows - summary of options

[Thomas A. Moulton]

On Wed, 2009-06-24 at 16:56 +0200, Freddie Chopin wrote:

> GPL. GPL. GPL... How about Users, Users, Users? Again - The Most 
> Important Qestion - Is OpenOCD meant for users to use, or just to be 
> "100%-GPL-at-any-cost"?
> 
> > You're the ONLY one advocating a "we-don't-care-for-X" mindset.
> 
> Damn, I see that the opposite way - 5-10 ppl are "100% GPL" (that's 
> where you are) while everyone else is like "why create artificial 
> problems?".

Freddie,

I have been involved with a number of distributed group projects and GPL
is the best way to go to insure the collective work will survive the
longest.

Case and point.

I wrote a Wireless X.25 packet switch in the 1980s, it was used world
wide on Amateur Packet Radio. It was called The ROSE X.25 Packet Switch.

It was not open source, I sold rights to it, ended up working on it for
a year and then the project was flushed.

I was burned out by this and no longer developed the switch and ROSE
died.

I was a core developer on osCommerce (aka The Exchange Project) that
project seems to be all but dead as well, but there are many forks and
some of them are still alive. Personally I still use it for one of my
websites. (GPL)

I have made a few changes to GNUBG (GNU Backgammon), nothing big, but
every little bit helps. (GPL)

I also play backgammon on FIBS (First Internet Backgammon Server) and
for a while tried to get the clients used there modernized. Sadly none
of them are really open source, I did get a few copies of source, but
the most popular one the author will not allow it to be converted to GPL
and they demand rights to any code I develop, with no rights to me (or
others). (closed)

I also took over a dead project that was a Tourney Robot for FIBS.
The original author long lost interest, but because it was GPL and
posted in a public place I was able to get the code and make
improvements, after seeing those updates the author did get responsive
to my questions, etc.

The fact that I was able to get the source and do something without
asking anyone for anything made it possible.

As a developer I DO care about the license. If it is not GPL (or
compatible) I will not waste my time. Now as a USER I also check the
license, if it is GPL then I know I can become a developer, if needed.

Could it be that the 5-10 people that are GPL 110% might just be the
active developers?

Tom



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

[Freddie Chopin]

David Brownell pisze:
> [so called "full explanation"]

You are wrong, because I just still don't get it how a 
GPL-with-exception can exist. If the GPL-chain has to end on the system 
libs, what is the purpose of having GPL-with-exception? Such code 
clearly cannot be used in ANY GPL project, because such project would 
also have to have an exception for that GPL-with-exception. So what - 
now we would have an endless chain of exceptions? Either I'm too stupid 
to understand that, or the license is too stupid for normal person to 
understand this nonsense.

Moreover - you are quoting the INTERPRETATION of the license found on 
the site, that has huge interest in the most extreme interpretation of 
all... Where does that say that in the license? The text alone, not "The 
most extreme FAQ about GPL on this planet".

 > See ... how your first "no explanation" whine was in fact
 > fully addressed at the very beginning of the flamewar you
 > have been feeding.

Let's not forget who ignited that whole "war". You.

> Are you a distributor?  If so, why aren't you having this
> conversation with your own legal team?

Again - I do not own a company, nor do I work for one that would make 
any money on OpenOCD. I'm just a Windows USER who wishes OpenOCD to be 
popular. That's it - nothing more, nothing less. While you see no 
problems with lack of installer with ftd2xx.dll, I see quite a lot. So 
our lack of understanding is mutual - I just don't get GPL, you just 
don't get libftdi+Windows problems.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

David Brownell pisze:
> Notice the complete disregard of technical arguments here.
> 
> That's a good sign that the person making the argument has no real
> contribution to make, beyond invective.

That's probably because I'm a USER, not a contributor. Quite simple.

> Under the GPL.  From the very first public release, that has been
> part of it.  You download it, and the GPL is there.  That brings
> along with it certain rules.

GPL. GPL. GPL... How about Users, Users, Users? Again - The Most 
Important Qestion - Is OpenOCD meant for users to use, or just to be 
"100%-GPL-at-any-cost"?

> You're the ONLY one advocating a "we-don't-care-for-X" mindset.

Damn, I see that the opposite way - 5-10 ppl are "100% GPL" (that's 
where you are) while everyone else is like "why create artificial 
problems?".

> You're also *falsely attributing* a mindset to other people.
> That's often called "lying".

Whatever.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD license

[Raúl Sánchez Siles]

  Hello:

   I'll just participate in this horrible flame once.

On Wednesday 24 June 2009 14:02:26 Ronald Vanschoren wrote:
> >it sucks to have to be the one to push for license
> >compliance like this
>
> Then don't! I'm just a user of OpenOCD so you have all right to ignore what
> I'm saying as you'll find that I'm less important, but it's about time
> people here start to realize the real "clients" are users and not
> developers and users don't give a sh*t about GPL violations.

  You are not less important, you are just another kind. "Clients" are 
important as well, just that you (we) don't pay for using the software. Having 
said this I don't understand how you (or anyone sensible) could support 
violating licenses. Do you have the habit of breaking laws for the sake of it?

>
> Why would anyone want to waste time and effort on fixing this purely
> theoretic issue? Use the time to implement useful features like SWD or
> threadsupport instead.
>
> You're acting like you have no choice but to point out this issue and write
> 700 mails about it. You of all people can fix it easily. Give up your
> copyright or allow relicensing it under anything that is not as gray and
> debatable as GPL.

  I don't think enforcing one's rights is loosing time. This is not a 
theoretic issue. GPL is the license and it states that whatever you link 
against and distribute should respect GPL freedom, among others, being able to 
get the source code.

  You can do things about this, for instance persuading FTDI to free the 
FTD2xx driver source and relicense it with GPL or any other compatible license 
for the issue: adm...@ftdichip.com

>
> As a sidenote I still don't see the issue. The spirit of GPL is to allow to
> make modifications to an application that is distributed in binary form.
> OpenOCD with FTD2xx allows this, no discussion! So stop using the FAQ of
> people holier then the pope to argument OpenOCD can't be released on
> Windows.

  You wouldn't be able to do modifications on the FTD2xx library, so no point 
for this.

>
> I really don't get it. If OpenOCD were my "baby" I would like to see it get
> popular and loved around the world. What's the use of having a super-great
> application that nobody will use because some people are stubborn and don't
> see further then idealistic BS.

  If OpenOCD or whatever other is my "baby", I would do what I would like with 
it. Trying to get it popular, maybe not, give it for free, get paid for it or 
even license it under GPL terms. In this case rules were dictated from the 
beginning.

>
> Just my 2 cents but I'm quite sure a lot more people are getting tired of
> this. Change the license or ignore the theoretic violation and get the next
> version out there in binary form for Windows using FTD2xx.
>

  If you (or others) are so interested in a license change, then answer this 
questions:

  · Have you contacted every copyright holder and ask for his opinion?
  · if (s)he is reluctant to change license what will give you in 
compensation?
  · Are you willing to pay money for the work they have done to change 
license?
  · Are you willing to accept anyone is not going to admit a license change?

  License is not democracy, not even meritocracy, is consensus. License is 
what it is and only an agreement of all copyright holders can change that.

> If I had something to say I would ask every contributor to state if they
> allow a relicense. If not, strip out their code and rewrite it. That can't
> take longer then making the workarounds people are discussing now. While
> we're at it, demand that contributors donate their copyright to the OpenOCD
> foundation or whatever, so these discussions are a thing of the past. I
> don't want to run a 2nd application to be able to use FTD2xx on windows. I
> already have to run OpenOCD and gdb, more then enough to keep track off.
>
> gr.
>
> Ronald

  What I don't understand so far is why it is so important to add an exception 
to the license instead of:

  · Improving free FTDI library
  · Asking FTDI to release and free the FTD2xx library
  · Make people interested in running FTD2xx build his own copy/binary of 
openocd

  Most of this options requires less work than tirelessly quarreling on the 
list. It is possible not using FTD2xx, it is also possible using it. Whoever 
is interested enough on any of those aspects should care for it, but not 
putting pressure or insulting(*) developers to do what they claim. Why is it 
easier to put pressure on developers who actually does a great job and not on 
a company that should encourage its products to be sell?

(*) I don't refer you, Ronald.

  Regards,

Pd: This e-mail express a strictly individual position.

-- 
Raúl Sánchez Siles

Departamento de Montaje

INFOGLOBAL, S. A.

* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01


___
Openocd-development mailing list
Openoc

[Openocd-development] [patch] openocd.texi - fixes from sam3 update

[David Brownell]

Fix formatting bug in at91sam7 doc added with the at91sam3 support;
and some formatting issues with sam7 and stm32 keyword params.

Tweak at91sam3 docs.  Remove ninth nibble from flash bank addresses,
clarify "at91sam3 show" variants and that the flash bank layout is
not needed as a parameter (unlike with sam7); formatting fixes.
---
 doc/openocd.texi |   62 +
 1 file changed, 35 insertions(+), 27 deletions(-)

Fix formatting bug in at91sam7 doc added with the at91sam3 support;
and some formatting issues with sam7 and stm32 keyword params.

Tweak at91sam3 docs.  Remove ninth nibble from flash bank addresses,
clarify "at91sam3 show" variants and that the flash bank layout is
not needed as a parameter (unlike with sam7); formatting fixes.
---
 doc/openocd.texi |   62 +
 1 file changed, 35 insertions(+), 27 deletions(-)

--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -3376,57 +3376,66 @@ flash bank aduc702x 0 0 0 0 $_TARGETNAME
 
 @deffn {Flash Driver} at91sam3
 @cindex at91sam3
-All members of the AT91SAM3 (cortex-M3) microcontroller family from
-atmel include internal flash and use the Cortex-M3 core. The driver
+All members of the AT91SAM3 microcontroller family from
+Atmel include internal flash and use ARM's Cortex-M3 core. The driver
 currently (6/22/09) recognizes the AT91SAM3U[1/2/4][C/E] chips. Note
 that the driver was orginaly developed and tested using the
 AT91SAM3U4E, using a SAM3U-EK eval board. Support for other chips in
-the family where cribbed from the data sheet [Note to future
+the family was cribbed from the data sheet. @emph{Note to future
 readers/updaters: Please remove this worrysome comment after other
-chips are confirmed].
+chips are confirmed.}
 
 The AT91SAM3U4[E/C] (256K) chips have 2 flash banks, the other chips
-(3U[1/2][E/C]) have 1 flash bank, in all cases the flash banks are at
-the following fixed locations. 
+(3U[1/2][E/C]) have 1 flash bank.  In all cases the flash banks are at
+the following fixed locations:
 
 @example
 # Flash bank 0 - all chips
-flash bank at91sam3 0x8 0 1 1 $_TARGETNAME
+flash bank at91sam3 0x0008 0 1 1 $_TARGETNAME
 # Flash bank 1 - only 256K chips
-flash bank at91sam3 0x00010 0 1 1 $_TARGETNAME
+flash bank at91sam3 0x0010 0 1 1 $_TARGETNAME
 @end example
 
-Internally, the AT91SAM3 flash memory is organized as follows:
+Internally, the AT91SAM3 flash memory is organized as follows.
+Unlike the AT91SAM7 chips, these are not used as parameters
+to the @command{flash bank} command:
 
 @itemize
-...@item @var{N-Banks:} 256K chips have 2 banks, others have 1 bank.
-...@item @var{Bank Size:}  128K/64K Per flash bank
-...@item @var{Sectors:} 16 or 8 per bank
-...@item @var{SectorSize:} 8K Per Sector
-...@item @var{PageSize:} 256 bytes per page. Note that OpenOCD operates on 'sector' sizes, not page sizes.
+...@item @emph{N-Banks:} 256K chips have 2 banks, others have 1 bank.
+...@item @emph{Bank Size:}  128K/64K Per flash bank
+...@item @emph{Sectors:} 16 or 8 per bank
+...@item @emph{SectorSize:} 8K Per Sector
+...@item @emph{PageSize:} 256 bytes per page. Note that OpenOCD operates on 'sector' sizes, not page sizes.
 @end itemize
 
-The AT91SAM3 driver adds an additional command:
+The AT91SAM3 driver adds some additional commands:
 
-...@deffn Command {at91sam3 gpnvm set|clear|show all|NUMBER}
-This command allows you to set, clear, or show the state of the GPNVM bits.
+...@deffn Command {at91sam3 gpnvm}
+...@deffnx Command {at91sam3 gpnvm clear} number
+...@deffnx Command {at91sam3 gpnvm set} number
+...@deffnx Command {at91sam3 gpnvm show} [...@option{all}|number]
+With no parameters, @command{show} or @command{show all},
+shows the status of all GPNVM bits.
+With @command{show} @var{number}, displays that bit.
+
+With @command{set} @var{number} or @command{clear} @var{number},
+modifies that GPNVM bit.
 @end deffn
 
 @deffn Command {at91sam3 info}
 This command attempts to display information about the AT91SAM3
-chip. @b{First} it read the @var{CHIPID_CIDR} [address 0x400e0740, see
+chip. @emph{First} it read the @code{CHIPID_CIDR} [address 0x400e0740, see
 Section 28.2.1, page 505 of the AT91SAM3U 29/may/2009 datasheet,
-document id: doc6430A] and decodes the values. @b{Second} it reads the
+document id: doc6430A] and decodes the values. @emph{Second} it reads the
 various clock configuration registers and attempts to display how it
 believes the chip is configured. By default, the SLOWCLK is assumed to
-be 32768 Hz, see the command @b{at91sam3 slowclk}.
+be 32768 Hz, see the command @command{at91sam3 slowclk}.
 @end deffn
 
-...@deffn Command {at91sam3 slowclk [VALUE]}
+...@deffn Command {at91sam3 slowclk} [value]
 This command shows/sets the slow clock frequency used in the
-...@b{at91sam3 info} command calculations above.
+...@command{at91sam3 info} command calculations above.
 @end deffn
-
 @end deffn
 
 @deffn {Flash D

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[Zach Welch]

On Wed, 2009-06-24 at 07:28 -0700, Zach Welch wrote:
> On Wed, 2009-06-24 at 09:56 -0400, Duane Ellis wrote:
> > David Brownell wrote:
> >  >> I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
> >  >> [snip]
> >  >> .bank[0] = { ... },
> > 
> > duane>  i thought the bank[0] = {  } was valid C99 initialization.
> > 
> > zach>   I just realized that I left out the '.bank = ' bits.
> > zach>  Sorry for that minor mess, but it compiled. :)
> > 
> > Huh? What do you mean? Confused.
> 
> Well, I changed 
> 
>  .bank[0] = { ... },
>  .bank[1] = { ... },
> 
> to 
> 

{ { ... }, { ... } }.

but it should have been:

.bank = { { ... }, { ... } }

See?  I missed the '.bank =' part  and I hit send accidentally
before finishing this message.   Sorry.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[Zach Welch]

On Wed, 2009-06-24 at 09:56 -0400, Duane Ellis wrote:
> David Brownell wrote:
>  >> I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
>  >> [snip]
>  >> .bank[0] = { ... },
> 
> duane>  i thought the bank[0] = {  } was valid C99 initialization.
> 
> zach>   I just realized that I left out the '.bank = ' bits.
> zach>  Sorry for that minor mess, but it compiled. :)
> 
> Huh? What do you mean? Confused.

Well, I changed 

 .bank[0] = { ... },
 .bank[1] = { ... },

to 

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[David Brownell]

On Wednesday 24 June 2009, Duane Ellis wrote:
> > I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
> > chip details banks get initialized.  The errors made no sense to
> > me, and they went away when I changed the
> >
> >   .bank[0] = { ... },
> >   .bank[1] = { ... },
> >
> > to be
> >
> >   .bank = {{ ... }, { ... }},
> >
> 
> i thought the bank[0] = {  } was valid C99 initialization.

Me too.  Which is most of why those errors made no sense to me.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Michael Bruck]

> Given that you are in the USA you could probably patent it as a
> business method and prevent anyone from using it or collecting money
> for it.

This should have read:
"... or you could collect money for it."
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Michael Bruck]

On Wed, Jun 24, 2009 at 13:29, Zach Welch wrote:
> On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote:
>> On Wed, Jun 24, 2009 at 11:42, Zach Welch wrote:
>> > On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote:
>> >> Simple project for a CS student.
>> >>
>> >> A wrapper with a libftdi interface calling libftd2xx, as a project using
>> >> a LGPL  license
>> >>
>> >> So any user can take their binary copy of OpenOCD linked against libftdi
>> >> and simply replace  the libftdi dll file, no need to play with system
>> >> files or drivers.
>> >>
>> >> Is  such a library  illegal ? Who would have standing to complain ?
>> >
>> > You are doing it to circumvent the GPL.  I think that is illegal.
>> >
>> > You would be contravening this copyright holder's intention, which would
>> > make you liable for any possible infringement that I could show.
>>
>> If a third party develops a libftdi.dll replacement then there is no
>> reason a user can not use that replacement. The GPL license that
>> applies to the user does not restrict at all what he does with the
>> code or binary as long as he does not distribute binaries of it.
>>
>> Obviously to put the dll wrapper wrapper under a GPL+exceptions
>> license it would have to be written from scratch rather than just
>> copy&pasting GPLed libftdi header files (although one could ask the
>> libfti author to re-license his/her files).
>
> No matter how you want to call the legality of the situation, I hope
> that you will admit there is something clearly unethically about what
> you are proposing.  I hope the libftdi author(s) would never allow
> re-licensing for such dubious efforts.

I don't see what is unethical here. The ethical discussion might have
more weight if it wasn't directed at a solution that in the eyes of
many people has helped the open source software project OpenOCD to
become more popular on the Windows platform.

I corrected myself in a later mail on the relicensing. No relicensing
is necessary because the use of headers is permitted under the LGPL.
Even if it were not it would be only a minor obstacle that can be
easily circumnavigated legally by recreating them from scratch.

> Since it remains a legal gray area, it seems silly to go down this road
> when solutions exist that are compliant, without any kind of effective
> subterfuge.

I don't see a legal gray area there at all. The gray area might be
when distributing the replacement DLL *with* the package.

>> > Furthermore, I think individuals can be held liable for "inducing"
>> > infringement, which is where IANAL becomes useful in some respects.
>> >
>> > I have been repeatedly warning _against_ infringement and to consult
>> > with an attorney on any possible solutions that you intend to distribute
>> > in binary form.  You should be too.
>>
>> There is no infringement here, so there is nothing to debate. The
>> issue gets a bit murky when the replacement dll is bundled with
>> OpenOCD, but that is not really necessary, the user can load it from
>> elsewhere.
>
> The intention to design this library for the purpose of circumventing
> the GPL is being documented on this list.  Sure, it's murky, but the
> discussion only helps to build my case to defend against this option.

Your premise is wrong. The user is not restricted in what he can do
with the software on his PC. This is crystal clear from the license
and the FAQ. You can do all sorts of kinky stuff with the software in
the sanctity of your hard drive, if you want to flip all bits or
increment all jump addresses by 13 or replace a DLL, that is your
right under the GPL.

> The problem you will face: can anyone in this community show they were
> working on that option for us, before all of these issues came to light?
> Lacking a paper trail, how can you explain your motive for doing this?
> If there _is_ shown to be infringement, it will be plainly intentional,
> and that may mean some cash will be left over after paying the lawyers.

This is not necessary. Your copyright on parts of OpenOCD does not
preclude a third party or in fact this project from developing a
libftdi.dll replacement for whatever purpose and under whatever
license.

> By all means, show me this evidence and I will permit this option.  If
> you cannot, then please drop it from further consideration, for the
> ethical considerations alone.  Or are "ethics" an unrealistic position
> from which to make such a plea?  Certainly, you _are_ free to ignore my
> ethical stance; likewise, do not expect me to help you in those efforts.
> I see them as sabotaging the free software community.

FTD2XX.dll is not the enemy, OpenOCD has used it to great advantage.

My company's contribution to this project was not based on ethics but
on the calculation that contributions from other users would feed back
into the program and be of benefit to us. The potential for such
additions is greatest when the quality/performance/usability of the
product is at its maximum so as to attract more u

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[Duane Ellis]

David Brownell wrote:
 >> I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
 >> [snip]
 >> .bank[0] = { ... },

duane>  i thought the bank[0] = {  } was valid C99 initialization.

zach>   I just realized that I left out the '.bank = ' bits.
zach>  Sorry for that minor mess, but it compiled. :)

Huh? What do you mean? Confused.

-Duane.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[Zach Welch]

On Wed, 2009-06-24 at 09:13 -0400, Duane Ellis wrote:
> David Brownell wrote:
> > I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
> > chip details banks get initialized.  The errors made no sense to
> > me, and they went away when I changed the
> >
> > .bank[0] = { ... },
> > .bank[1] = { ... },
> >
> > to be
> >
> > .bank = {{ ... }, { ... }},
> >
> >   
> i thought the bank[0] = {  } was valid C99 initialization.
> 
> I've been using cygwin, by default uses:
> 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
> 
> Perhaps something has changed I am unaware of .

I just realized that I left out the '.bank = ' bits.

Sorry for that minor mess, but it compiled.  :)

--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[Zach Welch]

On Wed, 2009-06-24 at 09:09 -0400, Duane Ellis wrote:
> Zach Welch wrote:
> > Fixed.  There were a few "could be used uninitialized" warnings too.
> > These seem like they should have been covered by --enable-werror.
> >
> > Duane, are you building with that option before committing changes?
> >   
> 
> I normally build with optimization disabled so that I can *debug* the 
> code - with the optimizer disabled, the uninitialized errors will not occur.

Thank you!  That explains it completely.  I was a bit confused.

--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper

[Duane Ellis]

Spencer Oliver wrote:
> strok_r is not available on win32 - strok is said to be reentrant on win32.
> Not near a dev pc at the moment so i thought i would point it out - i can
> make the change later if you do not have time.
>   

Hmm...  Perhaps we should add "strtok_r()" to the replacments.c file.

We could take an instance from Newlib - it has a BSD licensed 
implimentation.

What do you think?

-Duane.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[Duane Ellis]

David Brownell wrote:
> I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
> chip details banks get initialized.  The errors made no sense to
> me, and they went away when I changed the
>
>   .bank[0] = { ... },
>   .bank[1] = { ... },
>
> to be
>
>   .bank = {{ ... }, { ... }},
>
>   
i thought the bank[0] = {  } was valid C99 initialization.

I've been using cygwin, by default uses:

/usr/lib/gcc/i686-pc-cygwin/3.4.4/specs

Perhaps something has changed I am unaware of .

-Duane.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[Duane Ellis]

Zach Welch wrote:
> Fixed.  There were a few "could be used uninitialized" warnings too.
> These seem like they should have been covered by --enable-werror.
>
> Duane, are you building with that option before committing changes?
>   

I normally build with optimization disabled so that I can *debug* the 
code - with the optimizer disabled, the uninitialized errors will not occur.

-Duane.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[Zach Welch]

On Wed, 2009-06-24 at 14:08 +0200, Øyvind Harboe wrote:
> Hi Dominic,
> 
> first of all: there is every evidence that the technical problems
> that USB are encountering these days will be resolved *LONG*
> before any change in license could be effecuated.
> 
> I even believe that USB problems will be fixed before the community will have
> finished debating the ramifications of a specific license change
> proposal(none has been posted so far).
> 
> About GPL that was there from the start:
> 
> One of the *main* reasons I decided to get into OpenOCD at revision 214 (or
> was it before?) was that I felt confident that the GPL license protected
> my interests and that a pure GPL license *without* any exceptions was
> the least of evils. I saw downsides and upsides, but overall I felt that
> pure GPL was a good choice. There was/is lots of non-GPL alternatives
> out there that I would have considered instead of OpenOCD.
> 
> Even more important, I knew that the license could not be changed
> after I and others had made non-trivial changes without me & the
> community having an oportunity to veto it.
> 
> After a while I saw that enough work was put down into the GPL license
> that changing it became impractical for better or worse.
> 
> One of the nice things about GPL is that it is impossible to put GPL on
> a project first, then a couple of years later say "Ha! I really intended not
> GPL but some other license...". Nobody will sue you if you stick to
> the GPL license that you put down in the first place, but if you start
> to say "I really intended something else than I wrote down", then you're
> on a slippery slope.

This is an excellent point regarding the invalidity of "I actually meant
for the license to X".  Would everyone be so keen to accept this if it
were put into terms where X was "take freedoms from all of you chumps?"
Coincidentally, that is exactly how I interpret the attempt to relicense
the changes to allow an exception for proprietary linkage.

At this point, there do not appear to exist any reasonable basis for
arguing against this fact: the GPL was always the license for OpenOCD.
Arguments to dispute this fact need to provide convincing evidence, and
I think the repository justifies our position here -- not an exception.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] License

[Laurent Gauch]

>
> On Wed, 2009-06-24 at 12:20 +0200, Dominic Rath wrote:
> >/ This goes inentionally to you alone, feel free to bring it up on the list 
> >if you want...
> />/ 
> />/ > You have made me start to wonder if it would be possible to bring some
> />/ > sort of claim of "misrepresentation" against the project authors, were
> />/ > your suggestion to be taken by others.  The COPYING file is the standard
> />/ > way of notifying potential authors of a project's license, so I think
> />/ > that I would have a good chance of proving that the authors neglected to
> />/ > inform authors -- whether by intention or accident.
> />/ 
> />/ I suppose that means I have to remove all code you've contributed from
> />/ the repository in order to protect myself from what you might or might
> />/ not do. I will also have to ask all distributors to remove any version
> />/ since january 2009.
> /
> Actually, that would no longer be acceptable; you are welcome to fork
> the code, but I ask that you avoid making such changes.  The license is
> and was GPL, and I am now a copyright holder, maintainer, and active
> contributor to the project.  You would be taking a unilateral action
> that would not be uniformly supported by the OpenOCD community, whereas
> I am asserting my individual copyrights.  I can do what I have done, but
> the community should vote to exile my changes.
>   

You maybe are holder, maintainer, contributor ... but you are not the 
CREATOR / AUTHOR !

Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004 (with 
1-2 years or more of intensive coding)

I was myself a contributor to the project, but before there ais SVN ! 
Yes, strange for you.
But I am a contributor too.

What 'project contribution' means for you?
- Adding a lot of patches
- Donating hardware to end-users
- Building binary for easy-of-use
- Reading the forum
- Writing to the forum
- Documenting the project
- ...

All these tasks were needed to bring OpenOCD as it is actually.

Each project/products needs manager - developer - tester - distributor - 
end-userS
The end-users know what they need.

OpenOCD has a success story as open source from 2004. Please respect the 
story !

Until now, the success story says D2XX is needed ! Sorry, it is.

I am sure there will be better GPL code to push the D2XX out from the 
source.
You will have a better GPL but a lot of regression regarding final speed.

This is  my opinion.



-
> You have abdicated your authority in this community, and I resent your
> showing up here and making threats to remove my code.  I have asserted
> my rights after making a clear case that I have earned the privilege to
> do so.  You have effectively admitted to your own negligence with
> regards to licensing, which you must now accept like a grown-up.  Sorry.
>
> I am trying to work with the community.  What are you trying to do?
> Who is the totalitarian dictator here?
>
> >/ Not that I think that any remotely sane court would consider your
> />/ claim, but I certainly wont take this chance. You've been threatening
> />/ me personally with potential legal actions at least twice, and this is
> />/ nothing I'm willing to accept.
> /
> I am threatening violators with action.  Are you a violator?  No, and I
> would not take action against you unless you violated my copyrights,
> which I have no reason to believe is the case or would be.  Right?
>
> I will also say again that I am not interested in taking action for any
> past violations, but I am willing to defend my rights in the future.
> This position was made clear by me from the outset.  Your opinion about
> what a "remotely sane court" would or would not consider is exactly
> that, and you need to decide whether you are willing to test it.
>
> Please get legal counsel before taking any action with the repository,
> unless you would like to help constructively move the community out of
> this morass.  That will be my primary intention and focus.
>
> >/ Please think about what you've just suggested and feel free to clarify
> />/ your point.
> /
> Ditto.
>
> Cheers,
>
> Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] License

[Øyvind Harboe]

Hi Dominic,

first of all: there is every evidence that the technical problems
that USB are encountering these days will be resolved *LONG*
before any change in license could be effecuated.

I even believe that USB problems will be fixed before the community will have
finished debating the ramifications of a specific license change
proposal(none has been posted so far).

About GPL that was there from the start:

One of the *main* reasons I decided to get into OpenOCD at revision 214 (or
was it before?) was that I felt confident that the GPL license protected
my interests and that a pure GPL license *without* any exceptions was
the least of evils. I saw downsides and upsides, but overall I felt that
pure GPL was a good choice. There was/is lots of non-GPL alternatives
out there that I would have considered instead of OpenOCD.

Even more important, I knew that the license could not be changed
after I and others had made non-trivial changes without me & the
community having an oportunity to veto it.

After a while I saw that enough work was put down into the GPL license
that changing it became impractical for better or worse.

One of the nice things about GPL is that it is impossible to put GPL on
a project first, then a couple of years later say "Ha! I really intended not
GPL but some other license...". Nobody will sue you if you stick to
the GPL license that you put down in the first place, but if you start
to say "I really intended something else than I wrote down", then you're
on a slippery slope.





-- 
Øyvind Harboe
Embedded software and hardware consulting services
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 license

[Ronald Vanschoren]

>it sucks to have to be the one to push for license
>compliance like this

Then don't! I'm just a user of OpenOCD so you have all right to ignore what I'm 
saying as you'll find that I'm less important, but it's about time people here 
start to realize the real "clients" are users and not developers and users 
don't give a sh*t about GPL violations.

Why would anyone want to waste time and effort on fixing this purely theoretic 
issue? Use the time to implement useful features like SWD or threadsupport 
instead.

You're acting like you have no choice but to point out this issue and write 700 
mails about it. You of all people can fix it easily. Give up your copyright or 
allow relicensing it under anything that is not as gray and debatable as GPL.

As a sidenote I still don't see the issue. The spirit of GPL is to allow to 
make modifications to an application that is distributed in binary form. 
OpenOCD with FTD2xx allows this, no discussion! So stop using the FAQ of people 
holier then the pope to argument OpenOCD can't be released on Windows.

I really don't get it. If OpenOCD were my "baby" I would like to see it get 
popular and loved around the world. What's the use of having a super-great 
application that nobody will use because some people are stubborn and don't see 
further then idealistic BS.

Just my 2 cents but I'm quite sure a lot more people are getting tired of this. 
Change the license or ignore the theoretic violation and get the next version 
out there in binary form for Windows using FTD2xx.

Please point out EXACTLY why you are so against a GPL exception? What's your 
hidden agenda cause I refuse to believe this is pure idealism.

If I had something to say I would ask every contributor to state if they allow 
a relicense. If not, strip out their code and rewrite it. That can't take 
longer then making the workarounds people are discussing now. While we're at 
it, demand that contributors donate their copyright to the OpenOCD foundation 
or whatever, so these discussions are a thing of the past. I don't want to run 
a 2nd application to be able to use FTD2xx on windows. I already have to run 
OpenOCD and gdb, more then enough to keep track off.

gr.

Ronald



 Original Message  
Subject: [Openocd-development] OpenOCD license
From: Zach Welch 
To: openocd-development 
Date: Wed Jun 24 2009 13:28:17 GMT+0200 (Romance Standard Time)
> Hi all,
>
> In the face of Rick's abrupt departure, I feel that I need to provide
> more status and summary of the licensing situation.
>
> Each copyright holder has the right to "dictate" whether or not they
> will allow license terms to be changed in their derived works.  That is
> immutable, and I do not feel guilty for asserting my rights here. 
>
> I feel bad if some think that I have been dictating beyond those rights,
> more than just getting stuff done that needs to be done.  Rick won the
> uN versus uintN_t debate by the end of it, so his feedback was always
> being heard and incorporated by me.  I am steering with direction from
> the community, as I have made my clear responsibility since becoming a
> "maintainer".  However, those responsibilities do not affect my rights
> as a copyright holder, and here we see a conflict.
>
> Since my arrival, this OpenOCD list has often preferred talk over action
> too often, and I far prefer to engage in discussion on constructive
> issues like design, devices, and patches.  I do not feel guilty for
> taking actions to fix the problems that seem apparent after inspection,
> because no one has been doing such work for the project
>
> Some decisions may prove to be wrong and need fixing, but others need
> executive order to be carried out while awaiting those fixes.  I intend
> to carry on in this tradition, pro-actively addressing the community's
> needs and defending the terms of the GPL.  Licensing violations are one
> such area where compliance action needs to be demanded immediately by
> the appropriate stakeholders, to preserve the overall legal integrity of
> the project.  By protecting my own rights, I protect the rights of all
> free software users that do not want to see the GPL compromised.
>
> Given that even Rick conceded the past and current repository contents
> have been released under the GPL, further discussion is not a meaningful
> solution to violations of the license.  The means to achieve compliance
> with technical solutions have been outlined and are wholly acceptable;
> any exception would apply only to a fork of the project, branched before
> any GPL-only revisions went into the repository.
>
> Because of my objections to an exception to the GPL, I will not allow a
> change to the license in the trunk of the repository, so compliance
> needs to be sought to ensure that distributors of binaries respect the
> limitations of the GPL.  That seems like straightforward legal logic,
> not totalitarianism.
>
> The totalitarians are the FSF, who designed the legal language of the

Re: [Openocd-development] License

[Zach Welch]

On Wed, 2009-06-24 at 12:20 +0200, Dominic Rath wrote:
> This goes inentionally to you alone, feel free to bring it up on the list if 
> you want...
> 
> > You have made me start to wonder if it would be possible to bring some
> > sort of claim of "misrepresentation" against the project authors, were
> > your suggestion to be taken by others.  The COPYING file is the standard
> > way of notifying potential authors of a project's license, so I think
> > that I would have a good chance of proving that the authors neglected to
> > inform authors -- whether by intention or accident.
> 
> I suppose that means I have to remove all code you've contributed from
> the repository in order to protect myself from what you might or might
> not do. I will also have to ask all distributors to remove any version
> since january 2009.

Actually, that would no longer be acceptable; you are welcome to fork
the code, but I ask that you avoid making such changes.  The license is
and was GPL, and I am now a copyright holder, maintainer, and active
contributor to the project.  You would be taking a unilateral action
that would not be uniformly supported by the OpenOCD community, whereas
I am asserting my individual copyrights.  I can do what I have done, but
the community should vote to exile my changes.

You have abdicated your authority in this community, and I resent your
showing up here and making threats to remove my code.  I have asserted
my rights after making a clear case that I have earned the privilege to
do so.  You have effectively admitted to your own negligence with
regards to licensing, which you must now accept like a grown-up.  Sorry.

I am trying to work with the community.  What are you trying to do?
Who is the totalitarian dictator here?

> Not that I think that any remotely sane court would consider your
> claim, but I certainly wont take this chance. You've been threatening
> me personally with potential legal actions at least twice, and this is
> nothing I'm willing to accept.

I am threatening violators with action.  Are you a violator?  No, and I
would not take action against you unless you violated my copyrights,
which I have no reason to believe is the case or would be.  Right?

I will also say again that I am not interested in taking action for any
past violations, but I am willing to defend my rights in the future.
This position was made clear by me from the outset.  Your opinion about
what a "remotely sane court" would or would not consider is exactly
that, and you need to decide whether you are willing to test it.

Please get legal counsel before taking any action with the repository,
unless you would like to help constructively move the community out of
this morass.  That will be my primary intention and focus.

> Please think about what you've just suggested and feel free to clarify
> your point.

Ditto.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Can we get back to forward progress?

[Thomas A. Moulton]

As far as I can see there are two solutions being worked on:

USB (winusb, libusb) and libftdi

and

tcpip/Sockets/pipes/ipc

Can the person who is heading up each task start a NEW thread and 
identify who else is working with you and the state of the work.

I for one will be willing to test anything.

Tom
ps. let's let the old threads die
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Zach Welch]

On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote:
> On Wed, Jun 24, 2009 at 11:42, Zach Welch wrote:
> > On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote:
> >> Simple project for a CS student.
> >>
> >> A wrapper with a libftdi interface calling libftd2xx, as a project using
> >> a LGPL  license
> >>
> >> So any user can take their binary copy of OpenOCD linked against libftdi
> >> and simply replace  the libftdi dll file, no need to play with system
> >> files or drivers.
> >>
> >> Is  such a library  illegal ? Who would have standing to complain ?
> >
> > You are doing it to circumvent the GPL.  I think that is illegal.
> >
> > You would be contravening this copyright holder's intention, which would
> > make you liable for any possible infringement that I could show.
> 
> If a third party develops a libftdi.dll replacement then there is no
> reason a user can not use that replacement. The GPL license that
> applies to the user does not restrict at all what he does with the
> code or binary as long as he does not distribute binaries of it.
> 
> Obviously to put the dll wrapper wrapper under a GPL+exceptions
> license it would have to be written from scratch rather than just
> copy&pasting GPLed libftdi header files (although one could ask the
> libfti author to re-license his/her files).

No matter how you want to call the legality of the situation, I hope
that you will admit there is something clearly unethically about what
you are proposing.  I hope the libftdi author(s) would never allow
re-licensing for such dubious efforts.

Since it remains a legal gray area, it seems silly to go down this road
when solutions exist that are compliant, without any kind of effective
subterfuge.  

> > Furthermore, I think individuals can be held liable for "inducing"
> > infringement, which is where IANAL becomes useful in some respects.
> >
> > I have been repeatedly warning _against_ infringement and to consult
> > with an attorney on any possible solutions that you intend to distribute
> > in binary form.  You should be too.
> 
> There is no infringement here, so there is nothing to debate. The
> issue gets a bit murky when the replacement dll is bundled with
> OpenOCD, but that is not really necessary, the user can load it from
> elsewhere.

The intention to design this library for the purpose of circumventing
the GPL is being documented on this list.  Sure, it's murky, but the
discussion only helps to build my case to defend against this option.

The problem you will face: can anyone in this community show they were
working on that option for us, before all of these issues came to light?
Lacking a paper trail, how can you explain your motive for doing this?
If there _is_ shown to be infringement, it will be plainly intentional,
and that may mean some cash will be left over after paying the lawyers.

By all means, show me this evidence and I will permit this option.  If
you cannot, then please drop it from further consideration, for the
ethical considerations alone.  Or are "ethics" an unrealistic position
from which to make such a plea?  Certainly, you _are_ free to ignore my
ethical stance; likewise, do not expect me to help you in those efforts.
I see them as sabotaging the free software community.

Legal gray areas do not have GPL-compliant solutions.  They take risks
of being compliant or not.  Risks are unacceptable for OpenOCD vendors,
when there may exist potential threats.  These risks can be avoided,
because they disappear by embracing full and unarguable GPL-compliance.

> >> -  FTDI ?   no their libray and driver is called in accordance with
> >> their documentation.
> >> - OpenOCD ?  nobody has touched a single line of OpenOCD code
> >> - Copyright holders of libftdi, Intra2Net AG ?  no,  libftdi is LGPL and
> >> the new library would only use the header file in accordance with LGPL
> >> section 3.
> >>
> >> Would  it work? with a bit of tweaking I would think so.
> >>
> >> Is this a blatant attempt just to work around the problems with OpenOCD,
> >> GPL and libftd2xx ?  What do I know ? Maybe yes, but that does not make
> >> it illegal.
> >
> > It might.  This is a very gray area.  For the love of all that is sane,
> > why do you want to keep pressing these fronts, when other options have
> > been presented that will solve the problems without any objections?
> 
> TCP/IP will impose a speed penalty. It may be a nice extension for
> other purposes, but for daily work it is most likely not the best
> solution.

In addition to that solution, I have pointed out that libusb and libftdi
features and performance can be improved.  The community can try to get
FTDI to go LGPL with their code.  There is also a "build kit", which
creates user-built binaries; this should produce the same binaries they
were getting before this "problem", so there would be zero performance
impact to users (other than a longer install process).

Altogether, this puts four options on the table, all of which still seem
re

[Openocd-development] OpenOCD license

[Zach Welch]

Hi all,

In the face of Rick's abrupt departure, I feel that I need to provide
more status and summary of the licensing situation.

Each copyright holder has the right to "dictate" whether or not they
will allow license terms to be changed in their derived works.  That is
immutable, and I do not feel guilty for asserting my rights here. 

I feel bad if some think that I have been dictating beyond those rights,
more than just getting stuff done that needs to be done.  Rick won the
uN versus uintN_t debate by the end of it, so his feedback was always
being heard and incorporated by me.  I am steering with direction from
the community, as I have made my clear responsibility since becoming a
"maintainer".  However, those responsibilities do not affect my rights
as a copyright holder, and here we see a conflict.

Since my arrival, this OpenOCD list has often preferred talk over action
too often, and I far prefer to engage in discussion on constructive
issues like design, devices, and patches.  I do not feel guilty for
taking actions to fix the problems that seem apparent after inspection,
because no one has been doing such work for the project

Some decisions may prove to be wrong and need fixing, but others need
executive order to be carried out while awaiting those fixes.  I intend
to carry on in this tradition, pro-actively addressing the community's
needs and defending the terms of the GPL.  Licensing violations are one
such area where compliance action needs to be demanded immediately by
the appropriate stakeholders, to preserve the overall legal integrity of
the project.  By protecting my own rights, I protect the rights of all
free software users that do not want to see the GPL compromised.

Given that even Rick conceded the past and current repository contents
have been released under the GPL, further discussion is not a meaningful
solution to violations of the license.  The means to achieve compliance
with technical solutions have been outlined and are wholly acceptable;
any exception would apply only to a fork of the project, branched before
any GPL-only revisions went into the repository.

Because of my objections to an exception to the GPL, I will not allow a
change to the license in the trunk of the repository, so compliance
needs to be sought to ensure that distributors of binaries respect the
limitations of the GPL.  That seems like straightforward legal logic,
not totalitarianism.

The totalitarians are the FSF, who designed the legal language of the
license to be this way; however, I think that is tantamount to saying
the Founding Fathers were totalitarians seeking liberty, justice, and
the American way.  Sadly, those same people would be called "terrorists"
in the US today; indeed, this should draw some meaningful parallels.

These are the facts as I have come to understand them, and no one has
given me any solid evidence to refute these points.  I wish there were,
because I tell you -- it sucks to have to be the one to push for license
compliance like this.  I do not like being seen as the enemy in the eyes
of the community, but I feel it is necessary despite these consequences.

Once the positive consequences have been seen and appreciated fully,
maybe everyone will come around (or even thank me... I can dream).
Until then, please feel free to hate me for sticking to my ideals and
believing in the wisdom of foresight on these matters.  I can take it.

Otherwise, I am looking forward to seeing the community move past these
issues and onto more constructive development matters.

Cheers,

Zach Welch
Corvallis, OR

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Thomas A. Moulton]

Michael Bruck wrote:
> If a third party develops a libftdi.dll replacement then there is no
> reason a user can not use that replacement. The GPL license that
> applies to the user does not restrict at all what he does with the
> code or binary as long as he does not distribute binaries of it.
>
> Obviously to put the dll wrapper wrapper under a GPL+exceptions
> license it would have to be written from scratch rather than just
> copy&pasting GPLed libftdi header files (although one could ask the
> libfti author to re-license his/her files).
>   
Yes, another developer could produce such a library.
There might be GPL Gray areas, etc

But the discussion would need to be some place else, not on this list.

:)

Tom
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Michael Bruck]

On Wed, Jun 24, 2009 at 12:23, Michael Bruck wrote:
> On Wed, Jun 24, 2009 at 11:42, Zach Welch wrote:
>> On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote:
>>> Simple project for a CS student.
>>>
>>> A wrapper with a libftdi interface calling libftd2xx, as a project using
>>> a LGPL  license
>>>
>>> So any user can take their binary copy of OpenOCD linked against libftdi
>>> and simply replace  the libftdi dll file, no need to play with system
>>> files or drivers.
>>>
>>> Is  such a library  illegal ? Who would have standing to complain ?
>>
>> You are doing it to circumvent the GPL.  I think that is illegal.
>>
>> You would be contravening this copyright holder's intention, which would
>> make you liable for any possible infringement that I could show.
>
> If a third party develops a libftdi.dll replacement then there is no
> reason a user can not use that replacement. The GPL license that
> applies to the user does not restrict at all what he does with the
> code or binary as long as he does not distribute binaries of it.
>
> Obviously to put the dll wrapper wrapper under a GPL+exceptions
> license it would have to be written from scratch rather than just
> copy&pasting GPLed libftdi header files (although one could ask the
> libfti author to re-license his/her files).

I missed the part where it's LGPL, then it seems to fall under the
definition of "Application" and the "if the incorporated material is
not limited to numerical parameters, data structure layouts and
accessors, or small macros," clause applies.

Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Michael Bruck]

On Wed, Jun 24, 2009 at 11:42, Zach Welch wrote:
> On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote:
>> Simple project for a CS student.
>>
>> A wrapper with a libftdi interface calling libftd2xx, as a project using
>> a LGPL  license
>>
>> So any user can take their binary copy of OpenOCD linked against libftdi
>> and simply replace  the libftdi dll file, no need to play with system
>> files or drivers.
>>
>> Is  such a library  illegal ? Who would have standing to complain ?
>
> You are doing it to circumvent the GPL.  I think that is illegal.
>
> You would be contravening this copyright holder's intention, which would
> make you liable for any possible infringement that I could show.

If a third party develops a libftdi.dll replacement then there is no
reason a user can not use that replacement. The GPL license that
applies to the user does not restrict at all what he does with the
code or binary as long as he does not distribute binaries of it.

Obviously to put the dll wrapper wrapper under a GPL+exceptions
license it would have to be written from scratch rather than just
copy&pasting GPLed libftdi header files (although one could ask the
libfti author to re-license his/her files).

> Furthermore, I think individuals can be held liable for "inducing"
> infringement, which is where IANAL becomes useful in some respects.
>
> I have been repeatedly warning _against_ infringement and to consult
> with an attorney on any possible solutions that you intend to distribute
> in binary form.  You should be too.

There is no infringement here, so there is nothing to debate. The
issue gets a bit murky when the replacement dll is bundled with
OpenOCD, but that is not really necessary, the user can load it from
elsewhere.

>> -  FTDI ?   no their libray and driver is called in accordance with
>> their documentation.
>> - OpenOCD ?  nobody has touched a single line of OpenOCD code
>> - Copyright holders of libftdi, Intra2Net AG ?  no,  libftdi is LGPL and
>> the new library would only use the header file in accordance with LGPL
>> section 3.
>>
>> Would  it work? with a bit of tweaking I would think so.
>>
>> Is this a blatant attempt just to work around the problems with OpenOCD,
>> GPL and libftd2xx ?  What do I know ? Maybe yes, but that does not make
>> it illegal.
>
> It might.  This is a very gray area.  For the love of all that is sane,
> why do you want to keep pressing these fronts, when other options have
> been presented that will solve the problems without any objections?

TCP/IP will impose a speed penalty. It may be a nice extension for
other purposes, but for daily work it is most likely not the best
solution.


Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Michael Bruck]

On Wed, Jun 24, 2009 at 11:48, Øyvind Harboe wrote:
> On Wed, Jun 24, 2009 at 11:46 AM, Michael Bruck wrote:
>> On Wed, Jun 24, 2009 at 11:30, Øyvind Harboe wrote:
>>> But why should we go for such an inferior and specif solution when a more
>>> general one is proposed and worked on?
>>
>> What are the speed/roundtrip time implications of passing all data
>> through the Windows socket interfaces for the TCP/IP solution?
>
> Possibily neglible as OpenOCD is already highly geared towards
> long latency interfaces. It would have to be measured.

This may be valid for high-speed data transfers (but on arm11 for
example only in the fast memwrite mode that replaces status polling
with fixed delays). I doubt that for single-stepping, where the whole
processor state is fetched register-by-register, the
long-latency-optimizations make much of a difference.


Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Zach Welch]

On Wed, 2009-06-24 at 11:46 +0200, Michael Bruck wrote:
> On Wed, Jun 24, 2009 at 11:30, Øyvind Harboe wrote:
> > But why should we go for such an inferior and specif solution when a more
> > general one is proposed and worked on?
> 
> What are the speed/roundtrip time implications of passing all data
> through the Windows socket interfaces for the TCP/IP solution?

I have posited that they will be unkind to the driver, but I don't know.

> The dll wrappers (there are obviously two approaches which DLL is to
> be wrapped) seem to have the lower performance penalty.

There are options.  But it seems that FTD2XX will be the preferred
solution on Windows, and it may take a performance penalty to do so.
Such is the GPL.

I believe the very best performance will come by fixing libusb+libftdi,
which is another reason that I have lauded it since the start.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3

[Zach Welch]

On Wed, 2009-06-24 at 00:21 -0700, David Brownell wrote:
> On Tuesday 23 June 2009, Duane Ellis wrote:
> > >> Author: duane
> > >> Date: 2009-06-24 04:01:14 +0200 (Wed, 24 Jun 2009)
> > >> New Revision: 2383
> 
> I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
> chip details banks get initialized.  The errors made no sense to
> me, and they went away when I changed the
> 
>   .bank[0] = { ... },
>   .bank[1] = { ... },
> 
> to be
> 
>   .bank = {{ ... }, { ... }},
> 
> Also, that sam3 flash file has lots of whitespace issues; Zach,
> maybe you could run your scripts on it?  My quickie fixes gave
> 
>  src/flash/at91sam3.c | 1139 -
>  1 file changed, 564 insertions(+), 575 deletions(-)
> 
> totalling about 70 KB of fixups on that file.

Fixed.  There were a few "could be used uninitialized" warnings too.
These seem like they should have been covered by --enable-werror.

Duane, are you building with that option before committing changes?

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Øyvind Harboe]

On Wed, Jun 24, 2009 at 11:46 AM, Michael Bruck wrote:
> On Wed, Jun 24, 2009 at 11:30, Øyvind Harboe wrote:
>> But why should we go for such an inferior and specif solution when a more
>> general one is proposed and worked on?
>
> What are the speed/roundtrip time implications of passing all data
> through the Windows socket interfaces for the TCP/IP solution?

Possibily neglible as OpenOCD is already highly geared towards
long latency interfaces. It would have to be measured.

>
> The dll wrappers (there are obviously two approaches which DLL is to
> be wrapped) seem to have the lower performance penalty.
>
> Michael
>



-- 
Ø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] Summer coding project proposal

[Michael Bruck]

On Wed, Jun 24, 2009 at 11:30, Øyvind Harboe wrote:
> But why should we go for such an inferior and specif solution when a more
> general one is proposed and worked on?

What are the speed/roundtrip time implications of passing all data
through the Windows socket interfaces for the TCP/IP solution?

The dll wrappers (there are obviously two approaches which DLL is to
be wrapped) seem to have the lower performance penalty.

Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Zach Welch]

On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote:
> Simple project for a CS student.
> 
> A wrapper with a libftdi interface calling libftd2xx, as a project using 
> a LGPL  license
> 
> So any user can take their binary copy of OpenOCD linked against libftdi 
> and simply replace  the libftdi dll file, no need to play with system 
> files or drivers.
> 
> Is  such a library  illegal ? Who would have standing to complain ?

You are doing it to circumvent the GPL.  I think that is illegal.

You would be contravening this copyright holder's intention, which would
make you liable for any possible infringement that I could show. 

Furthermore, I think individuals can be held liable for "inducing"
infringement, which is where IANAL becomes useful in some respects.

I have been repeatedly warning _against_ infringement and to consult
with an attorney on any possible solutions that you intend to distribute
in binary form.  You should be too.

> -  FTDI ?   no their libray and driver is called in accordance with 
> their documentation.
> - OpenOCD ?  nobody has touched a single line of OpenOCD code
> - Copyright holders of libftdi, Intra2Net AG ?  no,  libftdi is LGPL and 
> the new library would only use the header file in accordance with LGPL 
> section 3.
> 
> Would  it work? with a bit of tweaking I would think so.
> 
> Is this a blatant attempt just to work around the problems with OpenOCD, 
> GPL and libftd2xx ?  What do I know ? Maybe yes, but that does not make 
> it illegal.

It might.  This is a very gray area.  For the love of all that is sane,
why do you want to keep pressing these fronts, when other options have
been presented that will solve the problems without any objections?

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper

[Spencer Oliver]

 
> > Added:
> >trunk/src/helper/membuf.c
> >trunk/src/helper/membuf.h
> > Modified:
> >trunk/src/helper/Makefile.am
> > Log:
> > Add a growable sprintf memory buffer library
> > 
> > Modified: trunk/src/helper/Makefile.am
> 
> strok_r is not available on win32 - strok is said to be 
> reentrant on win32.
> Not near a dev pc at the moment so i thought i would point it 
> out - i can make the change later if you do not have time.
> 

I meant to say strtok not strok

Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Summer coding project proposal

[Øyvind Harboe]

But why should we go for such an inferior and specif solution when a more
general one is proposed and worked on?



-- 
Ø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