Re: [Openocd-development] [patch] openocd.texi - minor fixes
Committed. Thanks! (email me if there are any other outstanding patches that haven't been committed yet) -- Ø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
[Openocd-development] Analog Device AduC70xx support
http://svn.berlios.de/svnroot/repos/openocd/trunk/tcl/target/aduc702x.cfg
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME s3c2410
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
# This config file was defaulting to big endian..
set _ENDIAN little
}
if { [info exists CPUTAPID] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x
}
The _CHIPNAME and _CPUTAPID do not look right at all.
Does OpenOCD support AduC70xx right now?
I just got a demo board from ADI (ADuC7060 with mIDAS-Link).
The following is the output from Segger J-Link Commander V4.06b.
SEGGER J-Link Commander V4.06b ('?' for help)
Compiled Jun 12 2009 13:25:59
Updating firmware: J-Link ARM V7 compiled May 27 2009 17:29:25
Replacing firmware: J-Link ARM V7 compiled May 20 2008 19:32:57
... Firmware update successful. CRC=347C
Waiting for new firmware to boot
New firmware booted successfully
DLL version V4.06b, compiled Jun 12 2009 13:25:42
Firmware: J-Link ARM V7 compiled May 27 2009 17:29:25
Hardware: V7.00
S/N : 7744
OEM : MIDAS
Feature(s) : RDI
VTarget = 3.274V
Info: TotalIRLen = 4, IRPrint = 0x01
Found 1 JTAG device, Total IRLen = 4:
Id of device #0: 0x3F0F0F0F
Found ARM with core Id 0x3F0F0F0F (ARM7)
JTAG speed: 5 kHz
J-Link>st
VTarget=3.274V
ITarget=0mA
TCK=1 TDI=0 TDO=1 TMS=0 TRES=1 TRST=1
Supported JTAG speeds:
- 48 MHz/n, (n>=4). => 12000kHz, 9600kHz, 8000kHz, ...
- Adaptive clocking
J-Link>hwinfo
HWInfo[00] = Target power is disabled
HWInfo[02] = 0mA(ITarget)
HWInfo[03] = 0mA(ITargetPeak)
HWInfo[04] = 0mA(ITargetPeakOperation)
HWInfo[10] = 0ms(ITargetMaxTime0)
HWInfo[11] = 0ms(ITargetMaxTime1)
HWInfo[12] = 0ms(ITargetMaxTime2)
J-Link>is
JTAG scan length: 4
J-Link>ms
Syntax: ms
J-Link>mr
Min: 0ns, Max: 0ns, Average: 0ns
J-Link>ms 0
Length of scan chain [0] = 105
J-Link>ms 1
Length of scan chain [1] = 33
J-Link>ms 2
Length of scan chain [2] = 38
J-Link>ms 3
Length of scan chain [3] = 0
J-Link>ms 4
Length of scan chain [4] = 157
--
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
> The _CHIPNAME and _CPUTAPID do not look right at all. > Does OpenOCD support AduC70xx right now? Yes, but you need to plug in the right values into that script. Patches gladly accepted. I believe the bugs you've spotted are a result of wholesale copy & paste of code into the target config scripts *after* that target script was tested -- Ø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
[Openocd-development] Recipe for Releases
Hi all,
I wanted to share the release process that I have mapped out. Rather
than waste everyone's time writing an e-mail that no one will read in
its entirety, I have attached a patch for new developer documentation to
describe the release processes (and much more). This new section
details what I intend to do to produce the 0.2.0 release.
At this point, I will probably finish this release by hand, but I want
to have the community check the recipe before I start using it. Have I
missed anything important here?
Cheers,
Zach
Index: doc/manual/main.txt
===
--- doc/manual/main.txt (revision 2448)
+++ doc/manual/main.txt (working copy)
@@ -18,6 +18,7 @@
follow when submitting patches to the project.
- The @subpage bugs page contains the content of the BUGS file, which
provides instructions for submitting bug reports to the maintainers.
+- The @subpage releases page describes the project's release process.
@ref primer provide introductory materials for new developers on various
specific topics.
Index: doc/manual/release.txt
===
--- doc/manual/release.txt (revision 0)
+++ doc/manual/release.txt (revision 0)
@@ -0,0 +1,126 @@
+/** @page releases Release Processes
+
+This page provides an introduction to the OpenOCD Release Proceses:
+- @ref releaseswhy
+- @ref releaseswho
+- @ref releaseswhen
+- @ref releaseshow
+
+...@section releaseswhy Why Produce Releases?
+
+The OpenOCD maintainers should produce releases periodically.
+he reasons for several reasons that should be given in detail, before
+explaining who and how the processes occur.
+
+At any time, a "source archives" can be produced by running 'make dist'
+in the OpenOCD project tree. With the 0.2.0 release, this command will
+produce openocd-\.{tar.gz,tar.bz2,zip} archives, which will be
+suitable for being released when produced properly.
+
+When released for users, these archives present several important
+advantages when contrasted to using the Subversion repository:
+
+-# They allow others to package and distribute the code to users.
+-# They build easier for developers, because they contain
+ a working configure script that was produced by the Release Manager.
+-# They prevent users from trying a random HEAD revision of the trunk.
+-# They free developers from answering questions about trunk breakage.
+
+Hopefully, this shows several good reasons to produce regular releases,
+but these release processes were developed with some additional design
+goals in mind. Specifically, the releases processes should have the
+following properties:
+
+-# Produce successive sets of release archives cleanly and consistently.
+ - Implementable as a script that automates the critical release steps.
+-# Prevent human operators from doing it wrong, as much as possible.
+-# Allow scheduling and automation of release process milestones.
+
+The current release processes are documented in the following sections.
+They attempt to meet these design goals, but there are many improvements
+remaining to be made toward automating the process.
+
+...@section releaseswho OpenOCD Release Manager
+
+OpenOCD archive releases will be produced by an individual filling the
+role of Release Manager. This individual determines the schdule
+(@see releaseswhen) and executes the release processes for the
+community. Each release requires one individual to fulfill this role,
+and these processes should survive any such transition gracefully.
+
+...@section releaseswhen OpenOCD Release Schedule
+
+The OpenOCD release process must be carried out on a periodic basis
+in order to realize the benefits outlined above (@see releaseswhy).
+
+Starting with the 0.2.0 release, the OpenOCD project should produce a
+new minor release each month, with a major release once per year. Bug
+fix releases could be provided more frequently; however, these should
+not be a priority for the Release Manager until the processes have been
+fully automated, to use resources most efficiently.
+
+If T is the time of the next release, then the following milestones
+describe the release milestones for each new release cycle.
+
+- T minus one month: start of new development cycle
+- T minus two weeks: announce pending trunk closure to new work
+- T minus one week: close trunk to new work, begin testing phase
+- T minus two days: call for final bug fixes
+- T minus one day: produce -rc packages and distribute to testers
+- T minus one hour: produce final packages and post on-line
+
+The process of scheduling release milestones should be community driven,
+though the Release Manager should attempt to follow these guidelines.
+Specifically, missing features that were scheduled for a release should
+be dropped, rather than delaying the release cycle to wait for them.
+
+...@section releaseshow Release Process: Step-by-Step
+
+The exact process likely requires a few releases to
Re: [Openocd-development] Recipe for Releases
Super! -- Ø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] Recipe for Releases
On Thu, 2009-07-02 at 02:43 -0700, Zach Welch wrote: > Hi all, > > I wanted to share the release process that I have mapped out. Rather > than waste everyone's time writing an e-mail that no one will read in > its entirety, I have attached a patch for new developer documentation to > describe the release processes (and much more). This new section > details what I intend to do to produce the 0.2.0 release. > > At this point, I will probably finish this release by hand, but I want > to have the community check the recipe before I start using it. Have I > missed anything important here? I have committed this patch along with the others outstanding in my queue, except for the version bump. I am going to give another 12 hours without changes to repository and to allow final feedback. This will allow time for the latest changes to get some last minute testing, and I can get a good night's sleep and a solid meal tomorrow before finishing things off. A couple of minor bug fixes have now trickled in; likewise, I do not want to create new problems trying to produce a release at 5am. Users: Please test the repository. Maintainers: Please continue to refrain from committing anything not worthy of 0.2.0. We're close. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Thu, Jul 2, 2009 at 5:19 PM, Øyvind Harboe wrote:
>> The _CHIPNAME and _CPUTAPID do not look right at all.
>> Does OpenOCD support AduC70xx right now?
>
> Yes, but you need to plug in the right values into that
> script. Patches gladly accepted.
>
> I believe the bugs you've spotted are a result of wholesale
> copy & paste of code into the target config scripts *after*
> that target script was tested
>
Here is the patch. With this patch, OpenOCD can talk to my
Analog Device Eval-ADuC7060 eval board.
--- trunk/tcl/target/aduc702x.cfg.orig 2009-05-28 07:51:26.0 +0800
+++ trunk/tcl/target/aduc702x.cfg 2009-07-02 22:55:36.0 +0800
@@ -5,7 +5,7 @@
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
- set _CHIPNAME s3c2410
+ set _CHIPNAME aduc702x
}
if { [info exists ENDIAN] } {
@@ -18,7 +18,7 @@
if { [info exists CPUTAPID] } {
set _CPUTAPID $CPUTAPID
} else {
- set _CPUTAPID 0x
+ set _CPUTAPID 0x3f0f0f0f
}
--
Xiaofan http://mcuee.blogspot.com
--- trunk/tcl/target/aduc702x.cfg.orig 2009-05-28 07:51:26.0 +0800
+++ trunk/tcl/target/aduc702x.cfg 2009-07-02 22:55:36.0 +0800
@@ -5,7 +5,7 @@
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
- set _CHIPNAME s3c2410
+ set _CHIPNAME aduc702x
}
if { [info exists ENDIAN] } {
@@ -18,7 +18,7 @@
if { [info exists CPUTAPID] } {
set _CPUTAPID $CPUTAPID
} else {
- set _CPUTAPID 0x
+ set _CPUTAPID 0x3f0f0f0f
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
2009/6/23 Freddie Chopin :
> I attach the most recent version of "universal .inf file"
>
> As you see, the devices that are "JTAG-only" should have entries for BOTH
> channels, the devices with UART/RS-232 on second channel should have only
> ONE entry.
>
> I took the liberty of adding my own JTAG, which is a modified JTAGkey with
> RS-232/UART [;
>
> More details in:
> https://lists.berlios.de/pipermail/openocd-development/2009-June/008483.html
> https://lists.berlios.de/pipermail/openocd-development/2009-June/008484.html
>
> 4\/3!!
>
> [Version]
> Signature = "$Chicago$"
> provider = %manufacturer%
> DriverVer = 03/20/2007,0.1.12.1
> CatalogFile = libusb-win32_ft2232_driver.cat
> CatalogFile.NT = libusb-win32_ft2232_driver.cat
>
> Class = LibUsbDevices
> ClassGUID = {EB781AAF-9C70-4523-A5DF-642A87ECA567}
>
> [ClassInstall]
> AddReg=libusb_class_install_add_reg
>
> [ClassInstall32]
> AddReg=libusb_class_install_add_reg
>
> [libusb_class_install_add_reg]
> HKR"LibUSB-Win32 Devices"
> HKR,,Icon,,"-20"
>
> [Manufacturer]
> %manufacturer%=Devices,NT
>
> ;--
> ; Files
> ;--
>
> [SourceDisksNames]
> 1 = "Libusb-Win32 Driver Installation Disk",,
>
> [SourceDisksFiles]
> libusb0.sys = 1,,
> libusb0.dll = 1,,
>
> [DestinationDirs]
> libusb_files_sys = 10,system32\drivers
> libusb_files_dll = 10,system32
>
> [libusb_files_sys]
> libusb0.sys
>
> [libusb_files_dll]
> libusb0.dll
>
> ;--
> ; Device driver
> ;--
>
> [LIBUSB_DEV]
> CopyFiles = libusb_files_sys, libusb_files_dll
> AddReg = libusb_add_reg
>
> [LIBUSB_DEV.NT]
> CopyFiles = libusb_files_sys, libusb_files_dll
>
> [LIBUSB_DEV.HW]
> DelReg = libusb_del_reg_hw
> AddReg = libusb_add_reg_hw
>
> [LIBUSB_DEV.NT.HW]
> DelReg = libusb_del_reg_hw
> AddReg = libusb_add_reg_hw
>
> [LIBUSB_DEV.NT.Services]
> AddService = libusb0, 0x0002, libusb_add_service
>
> [libusb_add_reg]
> HKR,,DevLoader,,*ntkern
> HKR,,NTMPDriver,,libusb0.sys
>
> ; Older versions of this .inf file installed filter drivers. They are not
> ; needed any more and must be removed
> [libusb_del_reg_hw]
> HKR,,LowerFilters
> HKR,,UpperFilters
>
> ; Device properties
> [libusb_add_reg_hw]
> HKR,,SurpriseRemovalOK, 0x00010001, 1
>
> ;--
> ; Services
> ;--
>
> [libusb_add_service]
> DisplayName = "LibUsb-Win32 - Kernel Driver 03/20/2007, 0.1.12.1"
> ServiceType = 1
> StartType = 3
> ErrorControl = 0
> ServiceBinary = %12%\libusb0.sys
>
> ;--
> ; Devices
> ;--
>
> [Devices]
> "Amontec JTAGkey (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_00
> "Amontec JTAGkey (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_01
>
> "egnite Turtelizer 2 (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_bdc8&MI_00
>
> "JTAG-lock-pick - USB <=> JTAG adapter"=LIBUSB_DEV,
> USB\VID_0403&PID_cff8&MI_00
>
> [Devices.NT]
> "Amontec JTAGkey (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_00
> "Amontec JTAGkey (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_01
>
> "egnite Turtelizer 2 (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_bdc8&MI_00
>
> "JTAG-lock-pick - USB <=> JTAG adapter"=LIBUSB_DEV,
> USB\VID_0403&PID_cff8&MI_00
>
> ;--
> ; Strings
> ;--
>
> [Strings]
> manufacturer = "Various"
>
I think this universal inf file along with the binary libusb0.sys
(from libusb-win32 svn)
should be bundled in the V0.2 release of OpenOCD to facilitate the
Windows packagers
who want to distribute an GPL compliant OpenOCD binary using
libusb-win32+libftdi.
--
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
Committed. Thanks! You're not running svn head, are you? If you can update to svn when testing then that would be *great*! :-) -- Ø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] Universal ft2232 .inf file for windows/libusb-win32
On Thu, 2009-07-02 at 23:15 +0800, Xiaofan Chen wrote:
> 2009/6/23 Freddie Chopin :
> > I attach the most recent version of "universal .inf file"
> >
> > As you see, the devices that are "JTAG-only" should have entries for BOTH
> > channels, the devices with UART/RS-232 on second channel should have only
> > ONE entry.
> >
> > I took the liberty of adding my own JTAG, which is a modified JTAGkey with
> > RS-232/UART [;
> >
> > More details in:
> > https://lists.berlios.de/pipermail/openocd-development/2009-June/008483.html
> > https://lists.berlios.de/pipermail/openocd-development/2009-June/008484.html
> >
> > 4\/3!!
> >
> > [Version]
> > Signature = "$Chicago$"
> > provider = %manufacturer%
> > DriverVer = 03/20/2007,0.1.12.1
> > CatalogFile = libusb-win32_ft2232_driver.cat
> > CatalogFile.NT = libusb-win32_ft2232_driver.cat
> >
> > Class = LibUsbDevices
> > ClassGUID = {EB781AAF-9C70-4523-A5DF-642A87ECA567}
> >
> > [ClassInstall]
> > AddReg=libusb_class_install_add_reg
> >
> > [ClassInstall32]
> > AddReg=libusb_class_install_add_reg
> >
> > [libusb_class_install_add_reg]
> > HKR"LibUSB-Win32 Devices"
> > HKR,,Icon,,"-20"
> >
> > [Manufacturer]
> > %manufacturer%=Devices,NT
> >
> > ;--
> > ; Files
> > ;--
> >
> > [SourceDisksNames]
> > 1 = "Libusb-Win32 Driver Installation Disk",,
> >
> > [SourceDisksFiles]
> > libusb0.sys = 1,,
> > libusb0.dll = 1,,
> >
> > [DestinationDirs]
> > libusb_files_sys = 10,system32\drivers
> > libusb_files_dll = 10,system32
> >
> > [libusb_files_sys]
> > libusb0.sys
> >
> > [libusb_files_dll]
> > libusb0.dll
> >
> > ;--
> > ; Device driver
> > ;--
> >
> > [LIBUSB_DEV]
> > CopyFiles = libusb_files_sys, libusb_files_dll
> > AddReg= libusb_add_reg
> >
> > [LIBUSB_DEV.NT]
> > CopyFiles = libusb_files_sys, libusb_files_dll
> >
> > [LIBUSB_DEV.HW]
> > DelReg = libusb_del_reg_hw
> > AddReg = libusb_add_reg_hw
> >
> > [LIBUSB_DEV.NT.HW]
> > DelReg = libusb_del_reg_hw
> > AddReg = libusb_add_reg_hw
> >
> > [LIBUSB_DEV.NT.Services]
> > AddService = libusb0, 0x0002, libusb_add_service
> >
> > [libusb_add_reg]
> > HKR,,DevLoader,,*ntkern
> > HKR,,NTMPDriver,,libusb0.sys
> >
> > ; Older versions of this .inf file installed filter drivers. They are not
> > ; needed any more and must be removed
> > [libusb_del_reg_hw]
> > HKR,,LowerFilters
> > HKR,,UpperFilters
> >
> > ; Device properties
> > [libusb_add_reg_hw]
> > HKR,,SurpriseRemovalOK, 0x00010001, 1
> >
> > ;--
> > ; Services
> > ;--
> >
> > [libusb_add_service]
> > DisplayName= "LibUsb-Win32 - Kernel Driver 03/20/2007, 0.1.12.1"
> > ServiceType= 1
> > StartType = 3
> > ErrorControl = 0
> > ServiceBinary = %12%\libusb0.sys
> >
> > ;--
> > ; Devices
> > ;--
> >
> > [Devices]
> > "Amontec JTAGkey (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_00
> > "Amontec JTAGkey (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_01
> >
> > "egnite Turtelizer 2 (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_bdc8&MI_00
> >
> > "JTAG-lock-pick - USB <=> JTAG adapter"=LIBUSB_DEV,
> > USB\VID_0403&PID_cff8&MI_00
> >
> > [Devices.NT]
> > "Amontec JTAGkey (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_00
> > "Amontec JTAGkey (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_01
> >
> > "egnite Turtelizer 2 (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_bdc8&MI_00
> >
> > "JTAG-lock-pick - USB <=> JTAG adapter"=LIBUSB_DEV,
> > USB\VID_0403&PID_cff8&MI_00
> >
> > ;--
> > ; Strings
> > ;--
> >
> > [Strings]
> > manufacturer = "Various"
> >
>
> I think this universal inf file along with the binary libusb0.sys
> (from libusb-win32 svn)
> should be bundled in the V0.2 release of OpenOCD to facilitate the
> Windows packagers
> who want to distribute an GPL compliant OpenOCD binary using
> libusb-win32+libftdi.
I was waiting for someone to post a patch Otherwise, how are the
maintainers supposed to know it's ready? :)
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
> > > > I think this universal inf file I would have thought it should be one with a LOT more IDs... That one omits the Olimex dongles, Sheevaplug, Signalyzer, Flyswatter, the Luminary stuff ... and about a dozen more. > > along with the binary libusb0.sys > > (from libusb-win32 svn) > > should be bundled in the V0.2 release of OpenOCD to facilitate the > > Windows packagers > > who want to distribute an GPL compliant OpenOCD binary using > > libusb-win32+libftdi. That would make it almost be a binary distro. A packager can grab (or make) those binaries. > I was waiting for someone to post a patch Otherwise, how are the > maintainers supposed to know it's ready? :) See above ... I think it's not ready yet. Though it seems to be a decent start. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Recipe for Releases
On Thursday 02 July 2009, Zach Welch wrote: > At this point, I will probably finish this release by hand, but I want > to have the community check the recipe before I start using it. Have I > missed anything important here? Hmm, I think one month between releases puts them kind of into the "noise" level. Too frequent. Folk barely have time to dive in before the next one is there... I'd remove the commitment to once-a-month and leave it open. Sometimes a month might be right. Sometimes more will be appropriate. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting openocd to compile on cygwin III
Try one more time with right e-mail address !! > I did the above experiment as mentioned by Duane Ellis > du...@desk ~ > $ echo $TEMP > /cygdrive/c/DOCUME~1/duane/LOCALS~1/Temp > du...@desk ~ > $ echo $TMP > /cygdrive/c/DOCUME~1/duane/LOCALS~1/Temp > du...@desk ~ > $ echo with-e > $TEMP/foobar1 > du...@desk ~ > $ echo no-e > $TMP/foobar1 > > These pass ok the temporary directories are sent foobar1 as designed. > > I am now on XP, at home, but my problems are the same whether on xp or > vista. > I also tried 'aclocal --verbose' this is where the ./bootstrap fails and > it acts > the same way on xp or on vista. > > One side issue, If I am supposed to use a "patch" to make the program, > work you will need to instruct me how to install a "patch". > > If someone has a certain configuration of cygwin that works, then I need to > know what I need to do to make my configuration like theirs. > > > Best regards, > > Joe > > > On Wed, Jul 1, 2009 at 7:28 PM, Zach Welch wrote: >> >>> On Wed, 2009-07-01 at 19:07 -0700, Joseph Kuss wrote: >>> > Spen, >>> > >>> > I guess I misinterpreted the text on openOCD cited, >>> > but my problem still exists: >>> > >>> > Here is what I did do: >>> > >>> > I do believe I complied with Michael Fischer's instructions about the >>> > cygwin packages: >>> > == >>> > 1) >>> > Install cygwin, but you need some additional tools from the >>> > development package like: >>> > >>> > - autoconf: Wrapper scripts for autoconf commands >>> > - automake: Wrapper scripts for automake and aclocals >>> > - gcc: C compiler upgrade helper >>> > - libtool: A shared library generation tool >>> > - make: The GNU version og the 'make' utility >>> > - subversion: A version control system >>> > == >>> > >>> > I assume after doining this and doing: >>> > = >>> > svn checkout svn://svn.berlios.de/openocd/trunk trunksvn checkout >>> > svn://svn.berlios.de/openocd/trunk trunk >>> > == >>> > >>> > I am ready to roll: >>> > >>> > when do ./bootstrap >>> > >>> > $ ./bootstrap >>> > + aclocal >>> > /usr/bin/m4:configure.in:428: canot create temporary file for >>> > diversion: Permission denied >>> > autom4te-2.6.3: /usr/bin/m4 failed with exit status: 1 >>> > aclocal-1.11: autom4te failed with exit status: 1 >>> > Bootstrap complete; you can './configure -enable-maintainer-mode " >>> > >>> >>> The problems appear to start here. If you run aclocal by hand, I assume >>> it gives you the same output, so try 'aclocal --verbose' and see if you >>> can determine which file it fails to create. Actual CygWin experts may >>> recognize this as a symptom of some unrelated problem, but I can't >>> remember anything like that offhand. >>> >>> By the looks of it, you have a simple permissions problem with your >>> temporary directory, but I have no idea how that that needs to be >>> configured under CygWin. In any case, I hope the output of the >>> --verbose command should prove more enlightening. >>> >>> Cheers, >>> >>> Zach >>> >>> >> > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Recipe for Releases
On Thu, 2009-07-02 at 12:33 -0700, David Brownell wrote: > On Thursday 02 July 2009, Zach Welch wrote: > > At this point, I will probably finish this release by hand, but I want > > to have the community check the recipe before I start using it. Have I > > missed anything important here? > > Hmm, I think one month between releases puts them kind of > into the "noise" level. Too frequent. Folk barely have > time to dive in before the next one is there... > > I'd remove the commitment to once-a-month and leave it > open. Sometimes a month might be right. Sometimes more > will be appropriate. Yeah. I thought about that. At this point, I think it is better to shoot for a one month cycle but allow for it to take two months. ;) Really, the Release Manager should be the one that makes these calls. If a hundred big patches get committed in a week, it might be time to stop and push a new release; if nothing gets committed for two months, then even that might be too frequent. The RM should keep track of these things and use their best judgment, while keeping the community informed of their perspective and decisions as they change over time. Right now, I would rather we produce "noise" than risk producing less volume than users and distributions demand. Presently, we have no way of characterizing these demands, and it seems better to over-deliver in this key area. At worst, users will simply start skipping releases, and I would rather have that happen than see them demanding more releases. Anyone can complain if releases are "too long"; it's hard to make a convincing claim that they are too short (e.g. "nightly snapshots"), particularly if we always list the most recent "stable" release(s). Finally, I still see a considerable volume of patches pending. For this reason alone, one month cycles sound fine for several releases to come; after that, I would be happy to tune this particular policy as needed. Right now, I see a clear and present need for frequent releases, since my own vision can see hundreds of patches waiting to be crafted. Please provide additional feedback on this, if you think this is wrong. Regardless of any plans proposed today, I do not want any release cycle to be decided in advance and followed with mindless rigor. I thought I put something in there to this effect, but I may have missed this idea. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
Xiaofan Chen wrote: > I think this universal inf file along with the binary libusb0.sys > (from libusb-win32 svn) > should be bundled in the V0.2 release of OpenOCD to facilitate the > Windows packagers > who want to distribute an GPL compliant OpenOCD binary using > libusb-win32+libftdi. > I think we should not distribute binaries - especially binaries where we do not provide the sources for. Documentation for packagers (which may include documentation on how to build those binaries) should be fine. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Getting openocd to compile on cygwin III
On Thu, 2009-07-02 at 12:52 -0700, Joseph Kuss wrote: > Try one more time with right e-mail address !! > > I did the above experiment as mentioned by Duane Ellis > > du...@desk ~ > $ echo $TEMP > /cygdrive/c/DOCUME~1/duane/LOCALS~1/Temp > du...@desk ~ > $ echo $TMP > /cygdrive/c/DOCUME~1/duane/LOCALS~1/Temp > du...@desk ~ > $ echo with-e > $TEMP/foobar1 > du...@desk ~ > $ echo no-e > $TMP/foobar1 > > These pass ok the temporary directories are sent foobar1 as > designed. > > I am now on XP, at home, but my problems are the same whether > on xp or vista. > I also tried 'aclocal --verbose' this is where > the ./bootstrap fails and it acts > the same way on xp or on vista. I vaguely wanted to see the output from the --verbose command, not just know that it failed. How did it fail? > One side issue, If I am supposed to use a "patch" to make the > program, > work you will need to instruct me how to install a "patch". Read these pages: - http://openocd.berlios.de/doc/doxygen/patchguide.html - http://openocd.berlios.de/doc/doxygen/primerpatches.html I wrote the Patch Primer, so let me know if it is unclear in any way. > If someone has a certain configuration of cygwin that works, > then I need to > know what I need to do to make my configuration like theirs. When I release the 0.2.0 packages, you should try building with those. You will skip the bootstrap script, which may be sufficient to get you past the problems that you are experiencing with the autotools. If not, I will be much more interested in figuring out what is wrong. Right now, I suspect that you either have a bad environment, or you may be using older versions of the autotools. Either way, I cannot help you solve those problems directly. Can you compile other autotools-based packages in your current CygWin environment? If so, the release will probably solve your problems. If not, then you have problems with your CygWin environment that this community should not be asked to solved. If it turns out to be a problem building from SVN, then you probably have old/bad autotools. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
On Thu, 2009-07-02 at 12:31 -0700, David Brownell wrote: > > > > > > I think this universal inf file > > I would have thought it should be one with a LOT more IDs... > > That one omits the Olimex dongles, Sheevaplug, Signalyzer, > Flyswatter, the Luminary stuff ... and about a dozen more. > > > > > along with the binary libusb0.sys > > > (from libusb-win32 svn) > > > should be bundled in the V0.2 release of OpenOCD to facilitate the > > > Windows packagers > > > who want to distribute an GPL compliant OpenOCD binary using > > > libusb-win32+libftdi. > > That would make it almost be a binary distro. A packager can > grab (or make) those binaries. Yeah. No question about that point: no binaries like this in-tree. That's Not Our Problem. > > > I was waiting for someone to post a patch Otherwise, how are the > > maintainers supposed to know it's ready? :) > > See above ... I think it's not ready yet. Though it seems > to be a decent start. Yup. Just pokin' the bears. :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Error when using correct -expected-id with USBprog
Hi, in the meantime I rebuilt OpenOCD to see if anything changed for the better. Unfortunately not, though the before mentioned bug seems to be gone. The configuration file is the same as before, the -expected-id is now the one that it should be. However now, I can't flash the device at all anymore. This is the log, maybe you can spot some indicators of whats going wrong here: C:\Programme\OpenOCD\0.2.0>openocd -d2 -f usbprog.cfg Open On-Chip Debugger 0.2.0-in-development (2009-07-02-15:45) svn:2458 $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS debug_level: 2 jtag_speed: 10 jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Error: Translation from khz to jtag_speed not implemented Info : USB JTAG Interface ready! Info : JTAG tap: lm3s6950.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0x ba00, ver: 0x3) Info : JTAG Tap/device matched Warn : Unexpected idcode after end of chain: 480 0x80ff Warn : Unexpected idcode after end of chain: 512 0x007f Warn : Unexpected idcode after end of chain: 544 0x00ff Warn : Unexpected idcode after end of chain: 576 0x00ff Warn : Unexpected idcode after end of chain: 608 0x00ff Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Block read error address 0xe000ed00, count 0x1 Warn : Invalid ACK in SWJDP transaction Info : JTAG tap: lm3s6950.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0x ba00, ver: 0x3) Info : JTAG Tap/device matched Warn : Unexpected idcode after end of chain: 480 0x80ff Warn : Unexpected idcode after end of chain: 512 0x007f Warn : Unexpected idcode after end of chain: 544 0x00ff Warn : Unexpected idcode after end of chain: 576 0x00ff Warn : Unexpected idcode after end of chain: 608 0x00ff Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Block read error address 0x400fe000, count 0x1 Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Info : JTAG tap: lm3s6950.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0x ba00, ver: 0x3) Info : JTAG Tap/device matched Warn : Unexpected idcode after end of chain: 480 0x80ff Warn : Unexpected idcode after end of chain: 512 0x007f Warn : Unexpected idcode after end of chain: 544 0x00ff Warn : Unexpected idcode after end of chain: 576 0x00ff Warn : Unexpected idcode after end of chain: 608 0x00ff Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Block read error address 0x400fe000, count 0x1 Error: can't request a halt while in reset if nSRST pulls nTRST Warn : Invalid ACK in SWJDP transaction Runtime error, file "embedded:startup.tcl", line 226: expected return code but got 'TARGET: lm3s6950.cpu - Not halted' Runtime error, file "usbprog.cfg", line 29: I removed "srst_pulls_trst" in the meantime from the configuration file, but this does not change the behaviour at all. All the best, /Markus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Recipe for Releases
One month would be august 6 or so. Meanwhile there is the summer vacation. A working month would be more like sept 1. How about having major releases every 3-6 months and minor releases more often? -- Ø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] Recipe for Releases
On Thursday 02 July 2009, Øyvind Harboe wrote: > One month would be august 6 or so. Meanwhile there > is the summer vacation. A working month would be > more like sept 1. Not everyone has sane vacations. *Someone* has to work during August to support the robber barons, whoops I mean "captains of Wall Street". Sigh. :( > How about having major releases every 3-6 months and > minor releases more often? What's "major" vs "minor"? "Major" as in "allowed to break backward compatibility" ... doesn't apply well here. "Big feature additions", maybe; but those can't be scheduled like that. I still think two months would be a reasonable target for releases. But I'm more concerned about setting fair expectations; committing to any particular schedule seems unwise. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Fri, Jul 3, 2009 at 1:47 AM, Øyvind Harboe wrote: > Committed. > > Thanks! > > You're not running svn head, are you? > > If you can update to svn when testing then that would be *great*! :-) > I am running the latest svn version. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
On Fri, Jul 3, 2009 at 4:45 AM, Michael Schwingen wrote: > Xiaofan Chen wrote: >> I think this universal inf file along with the binary libusb0.sys >> (from libusb-win32 svn) >> should be bundled in the V0.2 release of OpenOCD to facilitate the >> Windows packagers >> who want to distribute an GPL compliant OpenOCD binary using >> libusb-win32+libftdi. >> > I think we should not distribute binaries - especially binaries where we > do not provide the sources for. > > Documentation for packagers (which may include documentation on how to > build those binaries) should be fine. Okay, agreed to your comments. Anyway, I would think V0.2 is not ready without the proper libusb-win32+libftdi related stuff (INF file, documentation to build the latest SVN version of libusb-win32, etc) given that some of your guys are pushing so hard for a GPL compliant solution for Windows users. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
David Brownell wrote: >>> I think this universal inf file >>> > > I would have thought it should be one with a LOT more IDs... > > That one omits the Olimex dongles, Sheevaplug, Signalyzer, > Flyswatter, the Luminary stuff ... and about a dozen more. > > That is *exactly* why I suggested that if some could create a *TEMPLATE* *INF* file - any of us 'script-guys' can easily create a script that can easily generate, and easily update the 'universal inf file' -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
On Thu, 2009-07-02 at 22:18 -0400, Duane Ellis wrote: > David Brownell wrote: > >>> I think this universal inf file > >>> > > > > I would have thought it should be one with a LOT more IDs... > > > > That one omits the Olimex dongles, Sheevaplug, Signalyzer, > > Flyswatter, the Luminary stuff ... and about a dozen more. > > > > > That is *exactly* why I suggested that if some could create a *TEMPLATE* > *INF* file - any of us 'script-guys' can easily create a script that can > easily generate, and easily update the 'universal inf file' Very wise advice. This is definitely the way to go, if possible; I did not look carefully enough at the patch to know one way or the other. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
On Fri, Jul 3, 2009 at 10:45 AM, Zach Welch wrote: > On Thu, 2009-07-02 at 22:18 -0400, Duane Ellis wrote: >> David Brownell wrote: >> >>> I think this universal inf file >> >>> >> > >> > I would have thought it should be one with a LOT more IDs... >> > >> > That one omits the Olimex dongles, Sheevaplug, Signalyzer, >> > Flyswatter, the Luminary stuff ... and about a dozen more. >> > >> > >> That is *exactly* why I suggested that if some could create a *TEMPLATE* >> *INF* file - any of us 'script-guys' can easily create a script that can >> easily generate, and easily update the 'universal inf file' > > Very wise advice. This is definitely the way to go, if possible; I did > not look carefully enough at the patch to know one way or the other. > If you could run inf-wizard of libusb-win32, you will understand better the process of generating the INF file for libusb-win32. But I understand that you may not run Windows at all. The INF Wizard from libusb-win32 is already using kind of a template file. http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb/src/inf_wizard.c?view=markup If you run INF wizard, it takes four parameters to generate the INF file. 1. Vendor ID 2. Product ID 3. Manufacturer name 4. Device name In fact, it automatically detect the 4 parameters and give you the freedom to change them. The default INF file generated for FTDI device may not be so good (USB composite device). Therefore Freddie has already put the correct way to do it (use the individual interface). I kind of agree with Freddie that "I don't see any point in writing a script which parses some kind of table to do such simple task. Adding a new interface is just a matter of entering a few (2-4) lines to the inf file". -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
On Fri, Jul 3, 2009 at 7:46 AM, Xiaofan Chen wrote: > On Fri, Jul 3, 2009 at 4:45 AM, Michael > Schwingen wrote: >> Xiaofan Chen wrote: >>> I think this universal inf file along with the binary libusb0.sys >>> (from libusb-win32 svn) >>> should be bundled in the V0.2 release of OpenOCD to facilitate the >>> Windows packagers >>> who want to distribute an GPL compliant OpenOCD binary using >>> libusb-win32+libftdi. >>> >> I think we should not distribute binaries - especially binaries where we >> do not provide the sources for. >> >> Documentation for packagers (which may include documentation on how to >> build those binaries) should be fine. > > Okay, agreed to your comments. > > Anyway, I would think V0.2 is not ready without the proper > libusb-win32+libftdi > related stuff (INF file, documentation to build the latest SVN version of > libusb-win32, etc) given that some of your guys are pushing so hard for > a GPL compliant solution for Windows users. On a second thoughts, if you only distribute the universal INF file, it is not that useful actually. Windows driver contains not only the INF file, but also the .cat Security Catalog file, the libusb0.sys file and libusb0.dll file. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Recipe for Releases
On Fri, Jul 3, 2009 at 12:12 AM, David Brownell wrote: > On Thursday 02 July 2009, Ųyvind Harboe wrote: >> One month would be august 6 or so. Meanwhile there >> is the summer vacation. A working month would be >> more like sept 1. > > Not everyone has sane vacations. *Someone* has to > work during August to support the robber barons, > whoops I mean "captains of Wall Street". Sigh. :( What I really ment was that all developers was so busy working during the vacation that they would not have time to spare for OpenOCD :-) >> How about having major releases every 3-6 months and >> minor releases more often? > > What's "major" vs "minor"? Good point. > "Major" as in "allowed > to break backward compatibility" ... doesn't apply > well here. "Big feature additions", maybe; but > those can't be scheduled like that. > > I still think two months would be a reasonable > target for releases. But I'm more concerned about > setting fair expectations; committing to any > particular schedule seems unwise. I'm thinking that 2 months to be begin with would make sense. As OpenOCD matures, perhaps every 3-6 months. -- Ø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] Recipe for Releases
> -Original Message- > From: openocd-development-boun...@lists.berlios.de [mailto:openocd- > development-boun...@lists.berlios.de] On Behalf Of David Brownell > Sent: donderdag 2 juli 2009 21:33 > To: openocd-development@lists.berlios.de > Subject: Re: [Openocd-development] Recipe for Releases > > On Thursday 02 July 2009, Zach Welch wrote: > > At this point, I will probably finish this release by hand, but I want > > to have the community check the recipe before I start using it. Have I > > missed anything important here? > > Hmm, I think one month between releases puts them kind of > into the "noise" level. Too frequent. Folk barely have > time to dive in before the next one is there... > > I'd remove the commitment to once-a-month and leave it > open. Sometimes a month might be right. Sometimes more > will be appropriate. I agree. Too frequent releases make it impossible to rely on a release. Also, it might be a good idea to patch bugs both in the svn head and the latest release. This gives a release a longer lifespan. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
