Re: [Openocd-development] Replace "script" with "source"
Looks good to me! On Thu, Aug 11, 2011 at 4:13 AM, Steve Bennett wrote: > On 11/08/2011, at 11:39 AM, Jie Zhang wrote: > >> On Wed, Aug 10, 2011 at 8:27 PM, Steve Bennett >> wrote: >>> On 09/08/2011, at 11:18 PM, Jie Zhang wrote: >>> Hi, Since we are in merge window now, how about merge this patch to replace script with source: https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html If there is any issue, we still have enough time to revert this change. >>> >>> I don't see any advantage to removing 'script'. >>> I think it is better to have script evaluate in global scope. >>> >> Then could you make a patch and merge it. I have no strong opinion on >> this. Thank you! > > Please try the attached. > If there are no problems we can ask for it to me merged. > > Cheers, > Steve > > -- > µWeb: Embedded Web Framework - http://uweb.workware.net.au/ > WorkWare Systems Pty Ltd > W: www.workware.net.au P: +61 434 921 300 > E: ste...@workware.net.au F: +61 7 3391 6002 > > > > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > > -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Replace "script" with "source"
On 11/08/2011, at 11:39 AM, Jie Zhang wrote: > On Wed, Aug 10, 2011 at 8:27 PM, Steve Bennett wrote: >> On 09/08/2011, at 11:18 PM, Jie Zhang wrote: >> >>> Hi, >>> >>> Since we are in merge window now, how about merge this patch to >>> replace script with source: >>> >>> https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html >>> >>> If there is any issue, we still have enough time to revert this change. >> >> I don't see any advantage to removing 'script'. >> I think it is better to have script evaluate in global scope. >> > Then could you make a patch and merge it. I have no strong opinion on > this. Thank you! Please try the attached. If there are no problems we can ask for it to me merged. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 0001-Evaluate-script-in-the-global-scope.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Replace "script" with "source"
On Wed, Aug 10, 2011 at 8:27 PM, Steve Bennett wrote: > On 09/08/2011, at 11:18 PM, Jie Zhang wrote: > >> Hi, >> >> Since we are in merge window now, how about merge this patch to >> replace script with source: >> >> https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html >> >> If there is any issue, we still have enough time to revert this change. > > I don't see any advantage to removing 'script'. > I think it is better to have script evaluate in global scope. > Then could you make a patch and merge it. I have no strong opinion on this. Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On Wed, Aug 10, 2011 at 11:40 PM, Vit Mares wrote: > The FTD2232 can be used not only as a JTAG dongle but it is also > very big helper for embedded developer. It can be used as a I2C or SPI > bridge between your PC and uC board, it can be used for Lattice FPGA > programming etc. and many of us use it on Windows with native FTDI driver > support. The speed is not so important the drivers are. You can continue to use the FTDI drivers and those I2C/SPI/UART functions and at the same time libftdi/OpenOCD. The solution here is to use libusb-win32 filter driver. Install libusb-win32 and then launch the GUI filter wizard. Install the filter for the particular device (eg: J-Link, for FT2232x, usually interface 0 of the device) you have, then you can use OpenOCD built on top of libftdi and libusb-win32. And you can still use the existing driver based application (like IAR, Keil or Rowley), and your serial port for FT2232x's 2nd interface if that is used as a USB virtual serial port. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0 for Windows
On Thu, Aug 11, 2011 at 1:59 AM, Freddie Chopin wrote: > Hi! > > I've just posted Windows packages with OpenOCD 0.5.0 on my website - > http://www.freddiechopin.info/ - enjoy (; This is great. Thanks. > Below I post the news article associated with this files > > > OpenOCD 0.5.0 finally published! > > Almost one and a half year passed since last stable OpenOCD release... > During this time 0.4.0 Windows installer was downloaded from this website > over 16000 times and packages with development versions from this period - > over 5000 times. This proves that a Windows binary is quite important for Windows users. > This time Windows version of the application was published - just as > development versions - as a compressed .zip archive, not as .msi installer - > I hope this won't be a problem for you, it's easier and faster to create > such package instead of playing with installers (; . In Download > Software >> OpenOCD you can download 32- and 64-bit version. Extract anywhere and you > are ready to go (; I agree that zip archive is fine. The msi installer is sleek but I think most Windows users of OpenOCD can handle zip file. :-) > You can find highlights of major changes in NEWS file associated with this > release in OpenOCD repository. There are not many of them, because this > release should be treated as a stable update, without any revolutionary > changes. > > What next? The most anticipated feature - SWD (Serial Wire Debug) interface > support, two-wire interface used in most recent Cortex chips - is in > advanced stage. While you could use both "classic" JTAG and "modern" SWD in > "bigger" chips like STM32 or LPC17xx, the smallest chips - like LPC11xx - > can be debugged only via SWD. You can find more details on OpenOCD mailing > list. Let's hope that test versions will be available soon! Stay tuned! > SWD would be nice to have now that Cortex M0 device are getting quite some attentions. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Replace "script" with "source"
On 09/08/2011, at 11:18 PM, Jie Zhang wrote: > Hi, > > Since we are in merge window now, how about merge this patch to > replace script with source: > > https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html > > If there is any issue, we still have enough time to revert this change. I don't see any advantage to removing 'script'. I think it is better to have script evaluate in global scope. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][PULL Request][MIPS32] Fixed single byte memory write
Hi Drasko > Solution is more common, but the commit history is not clearer. You > are fixing several bugs in one patch... Serveral? Just one and a half :-) However, I stripped the alignment fix to a seperate patch file. Please find the three new patches attached. > Besides, I have an impression that you know what you are doing. Really? My previous patch breaks byte :-) access for mips_m4k_read_memory. Stefan 0002-mips-fix-reading-uint32-and-uint16-when-running-on-b.patch Description: 0002-mips-fix-reading-uint32-and-uint16-when-running-on-b.patch 0003-mips-fix-potential-alignment-error.patch Description: 0003-mips-fix-potential-alignment-error.patch 0001-target-add-helper-functions-to-get-set-u16-or-u32-ar.patch Description: 0001-target-add-helper-functions-to-get-set-u16-or-u32-ar.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10/08/2011 14:41, Jie Zhang wrote: On Wed, Aug 10, 2011 at 9:29 AM, Xiaofan Chen wrote: On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver wrote: Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Yes --disable-werror is necessary. If not the following errors will come out. I remember Jie Zheng has some proposals to fix this. ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_write': ../../../../src/jtag/drivers/ft2232.c:518:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' Yes. And Spencer said he would fix it if he got a chance. Jie http://repo.or.cz/w/openocd/ntfreak.git ftdi Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [pull request] dsp5680xx - naming changes and error propagation fix
On Wed, Aug 10, 2011 at 1:55 PM, Rodrigo Rosa wrote: > On Wed, Aug 10, 2011 at 1:54 PM, Rodrigo Rosa > wrote: >> i'm not sure i'm doing the cherry pick + pull stuff correctly >> >> i have >> remote.upstream.url=git://openocd.git.sourceforge.net/gitroot/openocd/openocd >> remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/* >> i did this >> // Get the openocd master stuff >> git fetch upstream/master >> git checkout -b dsp5680xx_cherry upstream/master >> // Pick the commits i want to be pulled from my stuff >> git cherry-pick 56b8cda472eb54bc9119a502e156cff23eb287dc >> git cherry-pick 34c877179535cce39774e6a206aca66c6b9031e1 >> // Put this new branch on my fork >> git push ssh://repo.or.cz/srv/git/openocd/dsp568013.git dsp5680xx_cherry >> // Create the pull request >> git request-pull HEAD git://repo.or.cz/openocd/dsp568013.git >> >> dsp5680xx_cherry_pull >> // Send it to here >> git send-email --compose --subject="[pull request] dsp5680xx - naming > > the send line was actually > git send-email --subject="[pull request] dsp5680xx - naming changes > and error propagation fix" --compose dsp5680xx_cherry_pull > without the "compose" part: git send-email --subject="[pull request] dsp5680xx - naming changes and error propagation fix" dsp5680xx_cherry_pull sorry for the noise >> changes and error propagation fix" dsp5680xx_cherry_pull >> >> is this ok? >> thanks >> >> On Wed, Aug 10, 2011 at 1:43 PM, Rodrigo L. Rosa >> wrote: >>> are available in the git repository at: >>> >>> git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry >>> >>> Rodrigo L. Rosa (1): >>> fix return code from dsp5680xx_read >>> >>> src/target/dsp5680xx.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> The following changes since commit 7675db7e92bff595dbddce1f7b5f1181424522f2: >>> Rodrigo L. Rosa (1): >>> fix return code from dsp5680xx_read >>> >>> are available in the git repository at: >>> >>> git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry >>> >>> >> >> >> >> -- >> Rodrigo. >> > > > > -- > Rodrigo. > -- Rodrigo. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [pull request] dsp5680xx - naming changes and error propagation fix
On Wed, Aug 10, 2011 at 1:54 PM, Rodrigo Rosa wrote: > i'm not sure i'm doing the cherry pick + pull stuff correctly > > i have > remote.upstream.url=git://openocd.git.sourceforge.net/gitroot/openocd/openocd > remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/* > i did this > // Get the openocd master stuff > git fetch upstream/master > git checkout -b dsp5680xx_cherry upstream/master > // Pick the commits i want to be pulled from my stuff > git cherry-pick 56b8cda472eb54bc9119a502e156cff23eb287dc > git cherry-pick 34c877179535cce39774e6a206aca66c6b9031e1 > // Put this new branch on my fork > git push ssh://repo.or.cz/srv/git/openocd/dsp568013.git dsp5680xx_cherry > // Create the pull request > git request-pull HEAD git://repo.or.cz/openocd/dsp568013.git >> > dsp5680xx_cherry_pull > // Send it to here > git send-email --compose --subject="[pull request] dsp5680xx - naming the send line was actually git send-email --subject="[pull request] dsp5680xx - naming changes and error propagation fix" --compose dsp5680xx_cherry_pull > changes and error propagation fix" dsp5680xx_cherry_pull > > is this ok? > thanks > > On Wed, Aug 10, 2011 at 1:43 PM, Rodrigo L. Rosa > wrote: >> are available in the git repository at: >> >> git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry >> >> Rodrigo L. Rosa (1): >> fix return code from dsp5680xx_read >> >> src/target/dsp5680xx.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> The following changes since commit 7675db7e92bff595dbddce1f7b5f1181424522f2: >> Rodrigo L. Rosa (1): >> fix return code from dsp5680xx_read >> >> are available in the git repository at: >> >> git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry >> >> > > > > -- > Rodrigo. > -- Rodrigo. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [pull request] dsp5680xx - naming changes and error propagation fix
i'm not sure i'm doing the cherry pick + pull stuff correctly i have remote.upstream.url=git://openocd.git.sourceforge.net/gitroot/openocd/openocd remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/* i did this // Get the openocd master stuff git fetch upstream/master git checkout -b dsp5680xx_cherry upstream/master // Pick the commits i want to be pulled from my stuff git cherry-pick 56b8cda472eb54bc9119a502e156cff23eb287dc git cherry-pick 34c877179535cce39774e6a206aca66c6b9031e1 // Put this new branch on my fork git push ssh://repo.or.cz/srv/git/openocd/dsp568013.git dsp5680xx_cherry // Create the pull request git request-pull HEAD git://repo.or.cz/openocd/dsp568013.git >> dsp5680xx_cherry_pull // Send it to here git send-email --compose --subject="[pull request] dsp5680xx - naming changes and error propagation fix" dsp5680xx_cherry_pull is this ok? thanks On Wed, Aug 10, 2011 at 1:43 PM, Rodrigo L. Rosa wrote: > are available in the git repository at: > > git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry > > Rodrigo L. Rosa (1): > fix return code from dsp5680xx_read > > src/target/dsp5680xx.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > The following changes since commit 7675db7e92bff595dbddce1f7b5f1181424522f2: > Rodrigo L. Rosa (1): > fix return code from dsp5680xx_read > > are available in the git repository at: > > git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry > > -- Rodrigo. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [pull request] dsp5680xx - naming changes and error propagation fix
are available in the git repository at: git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry Rodrigo L. Rosa (1): fix return code from dsp5680xx_read src/target/dsp5680xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) The following changes since commit 7675db7e92bff595dbddce1f7b5f1181424522f2: Rodrigo L. Rosa (1): fix return code from dsp5680xx_read are available in the git repository at: git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [pull request] dsp5680xx - naming changes and error propagation fix
are available in the git repository at: git://repo.or.cz/openocd/dsp568013.git dsp5680xx_cherry Rodrigo L. Rosa (1): fix return code from dsp5680xx_read src/target/dsp5680xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove useless pxref to SMP subsection
Any objections? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] remove useless pxref to SMP subsection
Hi,
I believe that pxref is useless. Please review and merge if OK. Thank you!
Jie
>From a78298da35c10a45136fdae0caede2860d30bbf5 Mon Sep 17 00:00:00 2001
From: Jie Zhang
Date: Wed, 10 Aug 2011 15:32:09 -0400
Subject: [PATCH] remove useless pxref to SMP subsection
---
doc/openocd.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index e3934e8..8b7e588 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1677,7 +1677,7 @@ Again using the at91sam7 as an example, this can look like:
$_TARGETNAME configure -work-area-phys 0x0020 \
-work-area-size 0x4000 -work-area-backup 0
@end example
-@pxref{Define CPU targets working in SMP}
+
@anchor{Define CPU targets working in SMP}
@subsection Define CPU targets working in SMP
@cindex SMP
--
1.7.5.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
>> Then when I pull to push to the repository, then without rebasing on >> my end I will not get a linear history. > this is the key point linear history make is lose the information on which > commit the code was bsed and tested before the merge. So for bisect point of > view it's not good An objection I have to patches is that they do not contain any information about which commit they were tested against. git pull w/merge preserves that information. It is possible to make a linear history later on if required. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On 2011-08-10 20:04, Freddie Chopin wrote: I don't know whether an IT admin would refuse to install completely free driver in the system. I meant: I don't know any reason why IT admin would refuse to install completely free driver in the system. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On 2011-08-10 18:13, Manuel Borchers wrote: The point he was trying to make is, that one _may_ need (or want to stick to) the "native" FTDI drivers. This may be because one wants to use the other channel as a normal UART (speak use the virtual com port) You can use normal UART on the second channel without any problems! This myth is going on forever! You can install two completely separate drivers for two channels of FT2232 - libusb-win32 for JTAG channel and ftd2xx for UART channel. OpenOCD does not care about second channel (yet). or some other closed source tools or there may even be no possibility to install libftdi drivers to the machines (due to firm policies) and one _must_ stick to the FTDI drivers. Such policies are usually made as a protection from proprietary illegal (cracked) software. I don't know whether an IT admin would refuse to install completely free driver in the system. (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD 0.5.0 for Windows
Hi! I've just posted Windows packages with OpenOCD 0.5.0 on my website - http://www.freddiechopin.info/ - enjoy (; Below I post the news article associated with this files OpenOCD 0.5.0 finally published! Almost one and a half year passed since last stable OpenOCD release... During this time 0.4.0 Windows installer was downloaded from this website over 16000 times and packages with development versions from this period - over 5000 times. This time Windows version of the application was published - just as development versions - as a compressed .zip archive, not as .msi installer - I hope this won't be a problem for you, it's easier and faster to create such package instead of playing with installers (; . In Download > Software > OpenOCD you can download 32- and 64-bit version. Extract anywhere and you are ready to go (; You can find highlights of major changes in NEWS file associated with this release in OpenOCD repository. There are not many of them, because this release should be treated as a stable update, without any revolutionary changes. What next? The most anticipated feature - SWD (Serial Wire Debug) interface support, two-wire interface used in most recent Cortex chips - is in advanced stage. While you could use both "classic" JTAG and "modern" SWD in "bigger" chips like STM32 or LPC17xx, the smallest chips - like LPC11xx - can be debugged only via SWD. You can find more details on OpenOCD mailing list. Let's hope that test versions will be available soon! Stay tuned! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
On 15:20 Wed 10 Aug , Øyvind Harboe wrote: > > I think it's very reasonable to require any pull request to apply > > cleanly to current tree. > > Say we have 2 outstanding pull requests, both impeccable. > > Then when I pull to push to the repository, then without rebasing on > my end I will not get a linear history. this is the key point linear history make is lose the information on which commit the code was bsed and tested before the merge. So for bisect point of view it's not good Best Regards, J. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
If we don't constantly show that some work has been done by open-source some people will tend to think it was done for free, no effort and they start to demand more results with less funds in shorter time. This is why we should tell to develop open-source instead buy expensive closed solutions-per-problem because investing in open-source in fact can bring better results with smaller cost... Creating open-source is not free and it is time consuming. Some people does not understand this fact. If some laboratory or company use closed source solutions but for some reason they want use open-source they cannot at the same time block support for open-source, or they should consequently purchase _everything_ commercial and closed source and even don't touch the open-source to see how bad things will get with their work and funding :-) Closed source applications are also full of bugs and limited functionalities. There is nothing good with that except you get working solution instantly... but you cannot change or develop it anyway. If anyone wants to use additional channels of FTDI I would recommend creating that support in open-source rather than mix open-source with proprietary stuff. The same with transfer efficiency and everything else. People start to integrate open-source in their commercial products with nothing in return. This is not fair and we should not support such actions. This is why I fully support decision to give preference for open-source libftdi rather than libftd2xx (please not that there is no libftd2xx for my system). Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On Wed, Aug 10, 2011 at 4:13 PM, Manuel Borchers wrote: > The point he was trying to make is, that one _may_ need (or want to > stick to) the "native" FTDI drivers. This may be because one wants to > use the other channel as a normal UART (speak use the virtual com port) > or some other closed source tools or there may even be no possibility to > install libftdi drivers to the machines (due to firm policies) and one > _must_ stick to the FTDI drivers. Hello Manuel :-) This policy looks like "must install Adobe Flash Player to view this image or table", but on some systems there is no flash player (nor libftd2xx) and so this is why we should stick to the open-source and promote open-source where possible. People don't even know that open-source alternative exist, or that some proprietary solutions only work on selected platforms, this is why we should change such ignorant policies where possible :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
Hi all, Am Mittwoch, den 10.08.2011, 15:47 + schrieb Tomek CEDRO: > Hello Vit, I have implemented bitbang functionality that allows > scripting high level buses (such as I2C, SPI, ...) in external > scripts, so they are not hardcoded into binary and it works fine with > open libftdi :-) No need to have closed source libftd2xx :-) You can > check it out at http://repo.or.cz/w/openocd/libswd.git The point he was trying to make is, that one _may_ need (or want to stick to) the "native" FTDI drivers. This may be because one wants to use the other channel as a normal UART (speak use the virtual com port) or some other closed source tools or there may even be no possibility to install libftdi drivers to the machines (due to firm policies) and one _must_ stick to the FTDI drivers. That's how the situation is with our lab PCs at the university. Cheers, Manuel -- Manuel Borchers Web: http://www.matronix.de eMail: man...@matronix.de ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On Wed, Aug 10, 2011 at 3:40 PM, Vit Mares wrote: > The FTD2232 can be used not only as a JTAG dongle but it is also > very big helper for embedded developer. It can be used as a I2C or SPI > bridge between your PC and uC board, it can be used for Lattice FPGA > programming etc. and many of us use it on Windows with native FTDI driver > support. The speed is not so important the drivers are. Hello Vit, I have implemented bitbang functionality that allows scripting high level buses (such as I2C, SPI, ...) in external scripts, so they are not hardcoded into binary and it works fine with open libftdi :-) No need to have closed source libftd2xx :-) You can check it out at http://repo.or.cz/w/openocd/libswd.git Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
The FTD2232 can be used not only as a JTAG dongle but it is also very big helper for embedded developer. It can be used as a I2C or SPI bridge between your PC and uC board, it can be used for Lattice FPGA programming etc. and many of us use it on Windows with native FTDI driver support. The speed is not so important the drivers are. Best regards Vit Mares 2011/8/10 Xiaofan Chen : > BTW, based on my tests a whole ago, FTD2xx does not actually > offer any significant speed advantages compare to libftdi/libusb-win32 > for openocd under Windows. So you may want to try out libftdi build. > http://comments.gmane.org/gmane.comp.debugging.openocd.devel/17877 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] "Code review" and "git pull"
On Wed, Aug 10, 2011 at 11:00 AM, Øyvind Harboe wrote: > On Wed, Aug 10, 2011 at 4:21 PM, Jie Zhang wrote: >> Hi, >> >> Just to make sure that we still do code review with "git pull", right? >> The developer still need to post all his/her patches for review before >> he/she asks for pull, right? > > I think inline for review and a pull request once all issues have been > settled for patch series works well. > Good. I was a little worried that patch would be pulled without review. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] "Code review" and "git pull"
On Wed, Aug 10, 2011 at 4:21 PM, Jie Zhang wrote: > Hi, > > Just to make sure that we still do code review with "git pull", right? > The developer still need to post all his/her patches for review before > he/she asks for pull, right? I think inline for review and a pull request once all issues have been settled for patch series works well. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] "Code review" and "git pull"
Hi, Just to make sure that we still do code review with "git pull", right? The developer still need to post all his/her patches for review before he/she asks for pull, right? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 9:29 AM, Xiaofan Chen wrote: > On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver wrote: >> Just tested building native windoze under cygwin and working fine here. >> I used the release tarball and the following configure line: >> ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 >> --disable-shared --disable-werror --enable-ft2232_ftd2xx >> > > Yes --disable-werror is necessary. If not the following errors > will come out. I remember Jie Zheng has some proposals to > fix this. > > ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_write': > ../../../../src/jtag/drivers/ft2232.c:518:3: error: format '%u' > expects type 'unsigned int', but argument 6 has type 'FT_STATUS' Yes. And Spencer said he would fix it if he got a chance. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver wrote: > Just tested building native windoze under cygwin and working fine here. > I used the release tarball and the following configure line: > ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 > --disable-shared --disable-werror --enable-ft2232_ftd2xx > Yes --disable-werror is necessary. If not the following errors will come out. I remember Jie Zheng has some proposals to fix this. libtool: compile: i686-pc-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. /../src/jtag/drivers -I../../.. -I../../../../src -I../../../src -DPKGDATADIR=\" /usr/local/share/openocd\" -DPKGLIBDIR=\"/usr/local/lib/openocd\" -I../../../../ jimtcl -I../../../jimtcl -g -O2 -D__USE_MINGW_ANSI_STDIO -Wall -Wstrict-prototyp es -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT ft2232.lo -MD -MP -MF .deps/ft2232.Tp o -c ../../../../src/jtag/drivers/ft2232.c -o ft2232.o cc1: warnings being treated as errors ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_write': ../../../../src/jtag/drivers/ft2232.c:518:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_read': ../../../../src/jtag/drivers/ft2232.c:561:4: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_init_ftd2xx': ../../../../src/jtag/drivers/ft2232.c:2218:4: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c::3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:2238:5: error: format '%u' expects type 'unsigned int', but argument 6 has type 'DWORD' ../../../../src/jtag/drivers/ft2232.c:2257:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:2268:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:2285:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:2291:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:2297:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:2307:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_DEVICE' ../../../../src/jtag/drivers/ft2232.c:2308:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'DWORD' ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_purge_ftd2xx': ../../../../src/jtag/drivers/ft2232.c:2322:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c: In function 'signalyzer_h_led_set': ../../../../src/jtag/drivers/ft2232.c:3643:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3651:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3659:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3666:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c: In function 'signalyzer_h_init': ../../../../src/jtag/drivers/ft2232.c:3755:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3765:4: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3779:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3786:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3793:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3801:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3808:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3815:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3822:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3831:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' ../../../../src/jtag/drivers/ft2232.c:3845:5: e
Re: [Openocd-development] rebase vs. merge
> I think it's very reasonable to require any pull request to apply > cleanly to current tree. Say we have 2 outstanding pull requests, both impeccable. Then when I pull to push to the repository, then without rebasing on my end I will not get a linear history. Should I as a maintainer rebase or not? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On Tue, Aug 9, 2011 at 11:20 PM, Vit Mares wrote: > I also vote for Freddie, he is the sureness where everybody finds > usable binary release for Windows. > It is very important for embedded developers (not only for beginners) > to have the possibility of using running version instead of the only > you-can-build-it-though-but-first-install-Cygwin-then-find-etc. > I would bet that most of OpenOCD users are working on Windows > and belaud to the skies this wonderful tool. I agree. > The sing would be even louder if they have binary Windows release > with FTD2XX.dll support :-) That has been shot down because of potential GPL licensing issues. I think we all have to respect that decision. BTW, based on my tests a whole ago, FTD2xx does not actually offer any significant speed advantages compare to libftdi/libusb-win32 for openocd under Windows. So you may want to try out libftdi build. http://comments.gmane.org/gmane.comp.debugging.openocd.devel/17877 I was hoping to see some counter-examples from others to show that D2xx is really much faster in some cases but nobody has yet to come out with the examples. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
Jean-Christophe PLAGNIOL-VILLARD wrote: > When you rebase you do not known against which commit the current > pull request was tested I think there may be a little bit of confusion. As I understood it, Øyvind asked which of the following two flows we should use: a. "rebase" 1. developer makes a branch locally 2. git commit locally 3. does git pull --rebase to ensure the local changes apply cleanly on top of public master 4. git send-email 5. maintainer does git pull, which will always be a fast-forward merge, no matter if git pull is used with or without --rebase is used, because the developer has already done a rebase in (3) onto the latest commit b. "merge" identical to above, except that (3) is skipped. Flow a. will generate a single linear history in the main repo. Flow b. will create a merge commit whenever a merge is not fast-forward, ie. when commits have been made in the public repo after the branch was created in (1). Flow a. loses information about where the branch was created, but results in a simple linear history. Flow b. keeps information about where the branch was created, but results in merge commits. > If a pul conflit we try to resolve it but if it's too complex at that > time we ask the one that send the pull request to rebase it's patches > against the current tree I think it's very reasonable to require any pull request to apply cleanly to current tree. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 6:05 PM, Xiaofan Chen wrote: > On Wed, Aug 10, 2011 at 5:12 PM, Olivier Schonken > wrote: >> Could you try building with >> >> ../configure --host=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi >> in stead of >> >> ../configure --build=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi >> >> Afaik, --host specifies the cross-compiler i.e. the target system, while >> --build specifies the system it is being built on - cygwin etc. Remember to >> do a make clean beforehand to clear any old object files. >> >> This might solve the path errors with building JimTCL. > > You are absolutely right. I made a mistake here and I will try again. Yes it works now. Thanks. I also need to make sure that I use fresh build source tree. mcuee@AcerPC /cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cross $ ../configure --host=i686-pc-mingw32 --build=i686-pc-cygwin --enable-jlink --enable-ft2232_libftdi checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for i686-pc-mingw32-strip... i686-pc-mingw32-strip checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for i686-pc-mingw32-gcc... i686-pc-mingw32-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether i686-pc-mingw32-gcc accepts -g... yes checking for i686-pc-mingw32-gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of i686-pc-mingw32-gcc... gcc3 checking for i686-pc-mingw32-gcc option to accept ISO C99... -std=gnu99 checking whether i686-pc-mingw32-gcc -std=gnu99 and cc understand -c and -o together... yes checking for i686-pc-mingw32-ranlib... i686-pc-mingw32-ranlib checking build system type... i686-pc-cygwin checking host system type... i686-pc-mingw32 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by i686-pc-mingw32-gcc -std=gnu99... /usr/i686-pc-mingw32/bin/ld.exe checking if the linker (/usr/i686-pc-mingw32/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/i686-pc-mingw32-nm -B checking the name lister (/usr/bin/i686-pc-mingw32-nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert i686-pc-cygwin file names to i686-pc-mingw32 format... func_convert_file_cygwin_to_w32 checking how to convert i686-pc-cygwin file names to toolchain format... func_convert_file_noop checking for /usr/i686-pc-mingw32/bin/ld.exe option to reload object files... -r checking for i686-pc-mingw32-objdump... i686-pc-mingw32-objdump checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL checking for i686-pc-mingw32-dlltool... i686-pc-mingw32-dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_implib checking for i686-pc-mingw32-ar... i686-pc-mingw32-ar checking for archiver @FILE support... @ checking for i686-pc-mingw32-strip... (cached) i686-pc-mingw32-strip checking for i686-pc-mingw32-ranlib... (cached) i686-pc-mingw32-ranlib checking command to parse /usr/bin/i686-pc-mingw32-nm -B output from i686-pc-min gw32-gcc -std=gnu99 object... ok checking for sysroot... no checking for i686-pc-mingw32-mt... no checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... i686-pc-mingw32-gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... no checking for objdir... .libs checking if i686-pc-mingw32-gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for i686-pc-mingw32-gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC checking if i686-pc-mingw32-gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes checking if i686-pc-mingw32-gcc -std=gnu99 static flag -static works... yes checking if i686-pc-mingw32-gcc -std=gnu99 supports -c -o file.o... yes checking if i686-pc-mingw32-gcc -std=gnu99 supports -c -o file.o... (cached) yes checkin
Re: [Openocd-development] 0.5.0 MinGW configure failure
The problem with jimsh, jimsh0 on MinGW build is probably somewhere in the script chain jimtcl/configure jimtcl/autosetup/find-tclsh jimtcl/autosetup/test-tclsh BTW it will not accept jimsh version lesser than 0.70 as can be seen in test-tclsh script. Best regards Vit ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10 August 2011 13:26, Xiaofan Chen wrote: > On Tue, Aug 9, 2011 at 11:11 PM, Spencer Oliver wrote: >> On 9 August 2011 16:01, Xiaofan Chen wrote: >>> On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver >>> wrote: >>> Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx >>> >>> Try build in a separate build directory and see if that is okay >>> or not. >>> >> >> works fine in/out of src tree. >> Just to be sure i also deleted the release src tree between builds. > > This is the key here. It seems to me that jimtcl build is a bit strange > that it creates a jimsh0.exe under the source distribution (jimtcl\autosetup > directory) even though I am building out of source tree. And that > seems to cause problems for subsequent build if I change the build > type. > > You are correct about the location of jimsh0 and it was pointed out to Steve a while back. However i have not seen any issues caused by this under cygwin. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10 August 2011 13:30, Xiaofan Chen wrote: > On Wed, Aug 10, 2011 at 6:35 PM, Spencer Oliver wrote: >> On 10 August 2011 11:15, Steve Bennett wrote: for me jimtcl has never built under msys since the update. log is attached below, for info jimsh0.exe is built ok. No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. autosetup/system.tcl:150: Error: in procedure 'use' called at file "auto.def", line 5 in procedure 'use' called at file "autosetup/cc.tcl", line 29 in procedure 'config_guess' called at file "autosetup/system.tcl", line 150 Try: 'configure --debug' for a full stack trace configure: error: ./configure.gnu failed for jimtcl >>> >>> It is failing while trying to run config.guess. >>> >>> What do you get when you run: >>> >>> sh jimtcl/autosetup/config.guess >>> >> >> i686-pc-mingw32 >> just installed a fresh copy of msys/mingw - still same error. > > I can reproduce here at a Vista 32bit installation of MinGW/MSys. It is > a myth now that I have the other PC working (XP SP3). I have updated > both MinGW/MSys installation to the latest. > > === configuring in jimtcl (/d/work/openocd/openocd-0.5.0/build_mingw/jimtcl) > configure: running /bin/sh ../../jimtcl/configure.gnu > --disable-option-checking > '--prefix=/usr/local' '--enable-jlink' '--enable-ft2232_libftdi' > --cache-file=/ > dev/null --srcdir=../../jimtcl > No installed jimsh or tclsh, building local bootstrap jimsh0 > The system cannot find the path specified. > ../../jimtcl/autosetup/system.tcl:150: Error: > in procedure 'use' called at file "../../jimtcl/auto.def", line 5 > in procedure 'use' called at file "../../jimtcl/autosetup/cc.tcl", line 29 > in procedure 'config_guess' called at file > "../../jimtcl/autosetup/system.tcl", > line 150 > Try: 'configure --debug' for a full stack trace > configure: error: ../../jimtcl/configure.gnu failed for jimtcl > we are currently working on this issue offlist, hopefully soon resolved. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 6:35 PM, Spencer Oliver wrote: > On 10 August 2011 11:15, Steve Bennett wrote: >>> for me jimtcl has never built under msys since the update. >>> log is attached below, for info jimsh0.exe is built ok. >>> >>> No installed jimsh or tclsh, building local bootstrap jimsh0 >>> The system cannot find the path specified. >>> autosetup/system.tcl:150: Error: >>> in procedure 'use' called at file "auto.def", line 5 >>> in procedure 'use' called at file "autosetup/cc.tcl", line 29 >>> in procedure 'config_guess' called at file "autosetup/system.tcl", line 150 >>> Try: 'configure --debug' for a full stack trace >>> configure: error: ./configure.gnu failed for jimtcl >> >> It is failing while trying to run config.guess. >> >> What do you get when you run: >> >> sh jimtcl/autosetup/config.guess >> > > i686-pc-mingw32 > just installed a fresh copy of msys/mingw - still same error. I can reproduce here at a Vista 32bit installation of MinGW/MSys. It is a myth now that I have the other PC working (XP SP3). I have updated both MinGW/MSys installation to the latest. === configuring in jimtcl (/d/work/openocd/openocd-0.5.0/build_mingw/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--enable-jlink' '--enable-ft2232_libftdi' --cache-file=/ dev/null --srcdir=../../jimtcl No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. ../../jimtcl/autosetup/system.tcl:150: Error: in procedure 'use' called at file "../../jimtcl/auto.def", line 5 in procedure 'use' called at file "../../jimtcl/autosetup/cc.tcl", line 29 in procedure 'config_guess' called at file "../../jimtcl/autosetup/system.tcl", line 150 Try: 'configure --debug' for a full stack trace configure: error: ../../jimtcl/configure.gnu failed for jimtcl -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 11:11 PM, Spencer Oliver wrote: > On 9 August 2011 16:01, Xiaofan Chen wrote: >> On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver wrote: >> >>> Just tested building native windoze under cygwin and working fine here. >>> I used the release tarball and the following configure line: >>> ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 >>> --disable-shared --disable-werror --enable-ft2232_ftd2xx >> >> Try build in a separate build directory and see if that is okay >> or not. >> > > works fine in/out of src tree. > Just to be sure i also deleted the release src tree between builds. This is the key here. It seems to me that jimtcl build is a bit strange that it creates a jimsh0.exe under the source distribution (jimtcl\autosetup directory) even though I am building out of source tree. And that seems to cause problems for subsequent build if I change the build type. mcuee@AcerPC /cygdrive/d/work/openocd/openocd-0.5.0/build_cygwin $ ls -la ../jimtcl/autosetup/jimsh0.exe -rwxr-xr-x+ 1 mcuee None 242820 Aug 10 20:10 ../jimtcl/autosetup/jimsh0.exe mcuee@AcerPC /cygdrive/d/work/openocd/openocd-0.5.0/build_cygwin $ ls -la ./jimtcl/jimsh.exe -rwxr-xr-x+ 1 mcuee None 724407 Aug 10 20:11 ./jimtcl/jimsh.exe My strange problem with the Cygwin native built was caused by this problem. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
Hi, in the kernel and barebox we avoid as much as possible the rebase as you loose information when you do so. When you rebase you do not known against which commit the current pull request was tested This histary is important specially when you apply multiple pull request. If a pul conflit we try to resolve it but if it's too complex at that time we ask the one that send the pull request to rebase it's patches against the current tree Best Regards, J. On 06:53 Wed 10 Aug , Øyvind Harboe wrote: > I am genuinely interested in hearing the pros and cons of rebasing > vs. merging pull requests. > > rebasing yields a nice linear history, which I like. Perhaps I'm just > old fashioned and used to it from Subversion days... > > -- > Øyvind Harboe - Can Zylin Consulting help on your project? > US toll free 1-866-980-3434 / International +47 51 87 40 27 > http://www.zylin.com/ > ___ > 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] rebase vs. merge
On Wed, Aug 10, 2011 at 11:49 AM, Drasko DRASKOVIC wrote: > What I'd like to avoid is this situation : you do development on your > independent branch, making many temporary commits which leave > temporary logs. These temporary logs should not be seen in the > official master's history, but only one commit/merge done by the > official maintainer. I think that merging a branch would show all your > temporary steps arriving to the final result... Yes, you should rebase and clean up your commits (using squash for instance) before sending a pull request. And you should rebase it against the current master head, to reduce the risk of conflicts due to other commits applied to master since you created your commits. That is, you take care of any conflicts instead of handing them to the poor maintainer. If nothing has been committed to master in between, there will be no difference in the maintainer merging (which would then do a fast-forward to your tree) or rebasing them himself (which would then be pointless and just reset the dates of your commits). Or, if other things have been committed in between, at least the risk of conflicts has been minimized, and your commits will also follow each other in the git history after a merge. Cheers, Tormod ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10 August 2011 11:15, Steve Bennett wrote: > On 10/08/2011, at 6:39 PM, Spencer Oliver wrote: > >> On 10 August 2011 07:11, Steve Bennett wrote: >>> On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: >>> On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett wrote: > On 10/08/2011, at 9:43 AM, Xiaofan Chen wrote: >> It was not up to date but very close. Anyway, I just updated it and >> the issue is still there with the release zip file. I will try the git >> tree later. >> >> === configuring in jimtcl >> (/cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cr >> oss/jimtcl) >> configure: running /bin/sh ../../jimtcl/configure.gnu >> --disable-option-checking >> '--prefix=/usr/local' '--build=i686-pc-mingw32' '--enable-jlink' >> '--enable-ft22 >> 32_libftdi' 'build_alias=i686-pc-mingw32' --cache-file=/dev/null >> --srcdir=../../ >> jimtcl >> ../../jimtcl/configure: line 3: >> D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j >> : No such file or directory >> ../../jimtcl/configure: line 3: exec: >> D:/work/openocd/openocd-0.5.0/jimtcl/autos >> : cannot execute: No such file or directory >> configure: error: ../../jimtcl/configure.gnu failed for jimtcl > > You have something weird going on there. Note how the lines are truncated. > For example: > >> ../../jimtcl/configure: line 3: >> D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j >> : No such file or directory Yes I agree that the error message is quite strange. It is directly copy and paste from the Cygwin prompt. I will check again. The other errors under MinGW are also quite strange. I think I will try another setup. >>> >>> Let us know how that goes. >>> > Or is that your cut and paste of the error messages? > If so, please add the errors as an attachment instead. > > FYI: I build the release tarball on windows/mingw without any problems. Glad to know that. As per the previous answer from Spen that MinGW/Msys is not supported by jimtcl. Is that not true? >>> >>> That is *not* true. >>> The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys >>> >> >> for me jimtcl has never built under msys since the update. >> log is attached below, for info jimsh0.exe is built ok. >> >> No installed jimsh or tclsh, building local bootstrap jimsh0 >> The system cannot find the path specified. >> autosetup/system.tcl:150: Error: >> in procedure 'use' called at file "auto.def", line 5 >> in procedure 'use' called at file "autosetup/cc.tcl", line 29 >> in procedure 'config_guess' called at file "autosetup/system.tcl", line 150 >> Try: 'configure --debug' for a full stack trace >> configure: error: ./configure.gnu failed for jimtcl > > It is failing while trying to run config.guess. > > What do you get when you run: > > sh jimtcl/autosetup/config.guess > i686-pc-mingw32 just installed a fresh copy of msys/mingw - still same error. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
Arguments in favor of merge: - what's merged is actually what the pull requestee tested and posted. - if there are digital signatures(we don't use them, but I think git has them), then they are not destroyed. - it's kinda nice to see a development branch as a separate project. When one rebases, this information is lost. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10/08/2011, at 6:39 PM, Spencer Oliver wrote: > On 10 August 2011 07:11, Steve Bennett wrote: >> On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: >> >>> On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett >>> wrote: On 10/08/2011, at 9:43 AM, Xiaofan Chen wrote: > It was not up to date but very close. Anyway, I just updated it and > the issue is still there with the release zip file. I will try the git > tree later. > > === configuring in jimtcl > (/cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cr > oss/jimtcl) > configure: running /bin/sh ../../jimtcl/configure.gnu > --disable-option-checking > '--prefix=/usr/local' '--build=i686-pc-mingw32' '--enable-jlink' > '--enable-ft22 > 32_libftdi' 'build_alias=i686-pc-mingw32' --cache-file=/dev/null > --srcdir=../../ > jimtcl > ../../jimtcl/configure: line 3: > D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j > : No such file or directory > ../../jimtcl/configure: line 3: exec: > D:/work/openocd/openocd-0.5.0/jimtcl/autos > : cannot execute: No such file or directory > configure: error: ../../jimtcl/configure.gnu failed for jimtcl You have something weird going on there. Note how the lines are truncated. For example: > ../../jimtcl/configure: line 3: > D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j > : No such file or directory >>> >>> Yes I agree that the error message is quite strange. It is directly copy >>> and paste from the Cygwin prompt. I will check again. >>> >>> The other errors under MinGW are also quite strange. I think I will >>> try another setup. >> >> Let us know how that goes. >> >>> Or is that your cut and paste of the error messages? If so, please add the errors as an attachment instead. FYI: I build the release tarball on windows/mingw without any problems. >>> >>> Glad to know that. As per the previous answer from Spen that >>> MinGW/Msys is not supported by jimtcl. Is that not true? >> >> That is *not* true. >> The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys >> > > for me jimtcl has never built under msys since the update. > log is attached below, for info jimsh0.exe is built ok. > > No installed jimsh or tclsh, building local bootstrap jimsh0 > The system cannot find the path specified. > autosetup/system.tcl:150: Error: > in procedure 'use' called at file "auto.def", line 5 > in procedure 'use' called at file "autosetup/cc.tcl", line 29 > in procedure 'config_guess' called at file "autosetup/system.tcl", line 150 > Try: 'configure --debug' for a full stack trace > configure: error: ./configure.gnu failed for jimtcl It is failing while trying to run config.guess. What do you get when you run: sh jimtcl/autosetup/config.guess -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
> What I'd like to avoid is this situation : you do development on your > independent branch, making many temporary commits which leave > temporary logs. These temporary logs should not be seen in the > official master's history, but only one commit/merge done by the > official maintainer. I think that merging a branch would show all your > temporary steps arriving to the final result... The workflow that git defines here is that you do your work, use interactive rebase to rewrite your local branch to look pretty and clear, then you post a pull request. Your clean history, not the mess you had during development, is then merged. Your clean history is visible to others after the merge. Clean history helps debugging and documentation. Commits should do small logical step-by-step changes as much as possible. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 5:12 PM, Olivier Schonken wrote: > Could you try building with > > ../configure --host=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi > in stead of > > ../configure --build=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi > > Afaik, --host specifies the cross-compiler i.e. the target system, while > --build specifies the system it is being built on - cygwin etc. Remember to > do a make clean beforehand to clear any old object files. > > This might solve the path errors with building JimTCL. You are absolutely right. I made a mistake here and I will try again. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
On Wed, Aug 10, 2011 at 11:25 AM, Tormod Volden wrote: > On Wed, Aug 10, 2011 at 10:09 AM, Drasko DRASKOVIC > wrote: >> On Wed, Aug 10, 2011 at 6:53 AM, Øyvind Harboe >> wrote: >>> I am genuinely interested in hearing the pros and cons of rebasing >>> vs. merging pull requests. >>> >>> rebasing yields a nice linear history, which I like. Perhaps I'm just >>> old fashioned and used to it from Subversion days... >> >> Hi Øyvind, >> as I understand, merging would merge in all ones personal commits to a >> personal git tree in a OpenOCD log history once it is is merged on the >> master branch. >> >> Rebase will leave just one commit on the top of the master. > > No, I think you are talking about squashing all your new commits into > one commit (which /can/ be done during a rebase). Rebasing itself just > reorders all commits so that your added commits are nicely on top of > the latest head, whereas a merge would possibly have your commits > spread down the git history between other commits. Yes, I was thinking about this... >> I am opting for the rebase - why do we need many personal commit logs >> in the official OpenOCD tree. > > If you are correcting one of your commits in a second commit (both not > applied to master yet) then squashing these together make sense before > sending your pull requests. If your work consists of many small, > relatively independent (builds and runs at each step) then they should > be kept separately, for the sake of later review and bisecting. I agree. What I'd like to avoid is this situation : you do development on your independent branch, making many temporary commits which leave temporary logs. These temporary logs should not be seen in the official master's history, but only one commit/merge done by the official maintainer. I think that merging a branch would show all your temporary steps arriving to the final result... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
On Wed, Aug 10, 2011 at 10:09 AM, Drasko DRASKOVIC wrote: > On Wed, Aug 10, 2011 at 6:53 AM, Øyvind Harboe > wrote: >> I am genuinely interested in hearing the pros and cons of rebasing >> vs. merging pull requests. >> >> rebasing yields a nice linear history, which I like. Perhaps I'm just >> old fashioned and used to it from Subversion days... > > Hi Øyvind, > as I understand, merging would merge in all ones personal commits to a > personal git tree in a OpenOCD log history once it is is merged on the > master branch. > > Rebase will leave just one commit on the top of the master. No, I think you are talking about squashing all your new commits into one commit (which /can/ be done during a rebase). Rebasing itself just reorders all commits so that your added commits are nicely on top of the latest head, whereas a merge would possibly have your commits spread down the git history between other commits. > I am opting for the rebase - why do we need many personal commit logs > in the official OpenOCD tree. If you are correcting one of your commits in a second commit (both not applied to master yet) then squashing these together make sense before sending your pull requests. If your work consists of many small, relatively independent (builds and runs at each step) then they should be kept separately, for the sake of later review and bisecting. Cheers, Tormod ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 4:22 PM, Steve Bennett wrote: > On 10/08/2011, at 6:15 PM, Xiaofan Chen wrote: >> But I am happy now since direct MinGW build works and direct Cygwin >> build also works. > > Thanks. That's good enough for me. > Just for those who can not wait for Freddie Chopin's binary, here is a test binary build of OpenOCD-0.5.0. http://code.google.com/p/picusb/downloads/detail?name=openocd_0.5.0_mingw.zip This is a test build of OpenOCD-0.5.0 release under MinGW. YMMV. Take note that OpenOCD is licensed under GPL. The source codes of OpenOCD-0.5.0 can be downloaded from the project website. http://sourceforge.net/projects/openocd/files/openocd/0.5.0/ The build is configured with the following option so that only J-Link and FT2232_libftdi hardware are supported. ../configure --enable-jlink --enable-ft2232_libftdi I also include relevant files for libftdi-0.19 and libusb-win32 1.2.5.0 release. Please refer to the Readme.txt file within the libftdi_libusb-win32 directory. In particular, it talks about driver installation options for FTDI based hardware. * I include this one in the zip file as well. http://code.google.com/p/picusb/downloads/detail?name=libftdi_0.19_devkit_MinGW32_26July2011.zip ** This is for developers who want to use libftdi-0.19 under Windows using MinGW. It includes libusb-win32 (1.2.5.0 release) driver installer from libusb-win32 project. It includes the following. 1) include file for libftdi-0.19 and libusb-win32 2) MinGW 32bit dll for libftdi-0.19 3) MinGW import and static library for libftdi-0.19 4) MinGW 32 bit build of libftdi-0.19 examples. 5) libusb-win32 device driver and filter driver installer which work under 32bit/64bit Windows. System requirements: Windows 2000, XP 32bit/64bit, Vista 32bit/64bit, Windows 7 32bit/64bit. 32bit/64bit Windows 2003/2008/2008R2 should also work. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10 August 2011 07:11, Steve Bennett wrote: > On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: > >> On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett >> wrote: >>> On 10/08/2011, at 9:43 AM, Xiaofan Chen wrote: It was not up to date but very close. Anyway, I just updated it and the issue is still there with the release zip file. I will try the git tree later. === configuring in jimtcl (/cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cr oss/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--build=i686-pc-mingw32' '--enable-jlink' '--enable-ft22 32_libftdi' 'build_alias=i686-pc-mingw32' --cache-file=/dev/null --srcdir=../../ jimtcl ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory ../../jimtcl/configure: line 3: exec: D:/work/openocd/openocd-0.5.0/jimtcl/autos : cannot execute: No such file or directory configure: error: ../../jimtcl/configure.gnu failed for jimtcl >>> >>> You have something weird going on there. Note how the lines are truncated. >>> For example: >>> ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory >> >> Yes I agree that the error message is quite strange. It is directly copy >> and paste from the Cygwin prompt. I will check again. >> >> The other errors under MinGW are also quite strange. I think I will >> try another setup. > > Let us know how that goes. > >> >>> Or is that your cut and paste of the error messages? >>> If so, please add the errors as an attachment instead. >>> >>> FYI: I build the release tarball on windows/mingw without any problems. >> >> Glad to know that. As per the previous answer from Spen that >> MinGW/Msys is not supported by jimtcl. Is that not true? > > That is *not* true. > The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys > for me jimtcl has never built under msys since the update. log is attached below, for info jimsh0.exe is built ok. No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. autosetup/system.tcl:150: Error: in procedure 'use' called at file "auto.def", line 5 in procedure 'use' called at file "autosetup/cc.tcl", line 29 in procedure 'config_guess' called at file "autosetup/system.tcl", line 150 Try: 'configure --debug' for a full stack trace configure: error: ./configure.gnu failed for jimtcl Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
> I am in the rebase camp - i like the linear history. > rebase only really effects shared public repos - as our dev's tend to > use their own mirror cannot see an issue. I don't have a problem using merge when rebase fails. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 10/08/2011, at 6:15 PM, Xiaofan Chen wrote: > On Wed, Aug 10, 2011 at 4:11 PM, Xiaofan Chen wrote: >> On Wed, Aug 10, 2011 at 2:11 PM, Steve Bennett >> wrote: >>> On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: > FYI: I build the release tarball on windows/mingw without any problems. Glad to know that. As per the previous answer from Spen that MinGW/Msys is not supported by jimtcl. Is that not true? >>> >>> That is *not* true. >>> The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys >>> >> >> Seems this is true and it works without using Cygwin. >> Thanks for the information. > > Cygwin build of 0.5.0 also works in this PC (XP SP3). > > Cross MinGW build under Cygwin (up to date installation of Cygwin) > still fails but with a different error. > > But I am happy now since direct MinGW build works and direct Cygwin > build also works. > Thanks. That's good enough for me. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
On 10 August 2011 09:13, Øyvind Harboe wrote: > We *do* want all the "personal commit logs" they are crucial documentation > of the system. > > I am in the rebase camp - i like the linear history. rebase only really effects shared public repos - as our dev's tend to use their own mirror cannot see an issue. fetch will keep their public shared repo in sync, performing a rebase may mean that the dev will need to force an update on his shared public repo. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 4:11 PM, Xiaofan Chen wrote: > On Wed, Aug 10, 2011 at 2:11 PM, Steve Bennett wrote: >> On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: FYI: I build the release tarball on windows/mingw without any problems. >>> >>> Glad to know that. As per the previous answer from Spen that >>> MinGW/Msys is not supported by jimtcl. Is that not true? >> >> That is *not* true. >> The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys >> > > Seems this is true and it works without using Cygwin. > Thanks for the information. Cygwin build of 0.5.0 also works in this PC (XP SP3). Cross MinGW build under Cygwin (up to date installation of Cygwin) still fails but with a different error. But I am happy now since direct MinGW build works and direct Cygwin build also works. bash-4.1# ../configure --build=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc -std=gnu99... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32 checking how to convert i686-pc-mingw32 file names to toolchain format... func_c onvert_file_msys_to_w32 checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import| ^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_imp lib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... no checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/i686-pc-cygwin/bin/ld.exe) supp orts shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... -lioperm checking for library containing dlopen... none required checking sys/so
Re: [Openocd-development] rebase vs. merge
We *do* want all the "personal commit logs" they are crucial documentation of the system. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
> I am opting for the rebase - why do we need many personal commit logs > in the official OpenOCD tree. With merge we *do* keep all the individual commits. There is just one extra commit that merges the two paths. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 2:11 PM, Steve Bennett wrote: > On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: >>> FYI: I build the release tarball on windows/mingw without any problems. >> >> Glad to know that. As per the previous answer from Spen that >> MinGW/Msys is not supported by jimtcl. Is that not true? > > That is *not* true. > The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys > Seems this is true and it works without using Cygwin. Thanks for the information. /c/cygwin/home/xfchen/openocd/openocd-0.5.0/build_mingw_direct $ ../configure --enable-jlink --enable-ft2232_libftdi checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc -std=gnu99... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /mingw/bin/nm checking the name lister (/mingw/bin/nm) interface... BSD nm checking whether ln -s works... no, using cp -p checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32 checking how to convert i686-pc-mingw32 file names to toolchain format... func_c onvert_file_msys_to_w32 checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import| ^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_imp lib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /mingw/bin/nm output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... no checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... yes checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (c:/mingw/mingw32/bin/ld.exe) support s shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... no checking for library containing dlopen... no checking sys/socket.h usability... no checking sys/socket.h presence... no checking for sys/socket.h... no checking for arpa/inet.h... no checking elf.h usability... no checking elf.h presence... no checking for elf.h... no checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking fcntl.h usability.
Re: [Openocd-development] rebase vs. merge
On Wed, Aug 10, 2011 at 6:53 AM, Øyvind Harboe wrote: > I am genuinely interested in hearing the pros and cons of rebasing > vs. merging pull requests. > > rebasing yields a nice linear history, which I like. Perhaps I'm just > old fashioned and used to it from Subversion days... Hi Øyvind, as I understand, merging would merge in all ones personal commits to a personal git tree in a OpenOCD log history once it is is merged on the master branch. Rebase will leave just one commit on the top of the master. I am opting for the rebase - why do we need many personal commit logs in the official OpenOCD tree. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] ARM-JTAG-EW verbose debugging fixes 2/2
- Send GDB keep_alive() messages when logging USB communication
- Ticket: #35
---
src/jtag/drivers/arm-jtag-ew.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/jtag/drivers/arm-jtag-ew.c b/src/jtag/drivers/arm-jtag-ew.c
index 20f7c99..e511d71 100644
--- a/src/jtag/drivers/arm-jtag-ew.c
+++ b/src/jtag/drivers/arm-jtag-ew.c
@@ -847,6 +847,9 @@ static void armjtagew_debug_buffer(uint8_t *buffer, int length)
strcat(line, s);
}
LOG_DEBUG("%s", line);
+
+ // Prevent GDB timeout (writing to log might take some time)
+ keep_alive();
}
}
#endif
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] ARM-JTAG-EW fixes 1/2
- Fix setting interface speed:
- CMD_SET_TCK_FREQUENCY message length is 5, not 4
- Interface expects speed in Hz, not kHz
- Provide armjtagew_speed_div() in order to fix interactive use
of `adapter_khz'
- Declare interface as `jtag_only'
- Emit a warning if interface firmware version != 1.6
- In armjtagew_init(), set initial JTAG speed to 32 kHz (before TAP
initialization). This prevents rare communication errors during
startup.
- Ticket: #34
---
src/jtag/drivers/arm-jtag-ew.c | 28 +++-
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/src/jtag/drivers/arm-jtag-ew.c b/src/jtag/drivers/arm-jtag-ew.c
index 44eaeff..20f7c99 100644
--- a/src/jtag/drivers/arm-jtag-ew.c
+++ b/src/jtag/drivers/arm-jtag-ew.c
@@ -184,9 +184,9 @@ static int armjtagew_speed(int speed)
usb_out_buffer[0] = CMD_SET_TCK_FREQUENCY;
- buf_set_u32(usb_out_buffer + 1, 0, 32, speed);
+ buf_set_u32(usb_out_buffer + 1, 0, 32, speed*1000);
-result = armjtagew_usb_message(armjtagew_handle, 4, 4);
+result = armjtagew_usb_message(armjtagew_handle, 5, 4);
if (result < 0)
{
@@ -196,7 +196,7 @@ static int armjtagew_speed(int speed)
usb_out_buffer[0] = CMD_GET_TCK_FREQUENCY;
result = armjtagew_usb_message(armjtagew_handle, 1, 4);
- speed_real = (int)buf_get_u32(usb_in_buffer,0,32);
+ speed_real = (int)buf_get_u32(usb_in_buffer,0,32) / 1000;
if (result < 0)
{
LOG_ERROR("ARM-JTAG-EW getting speed failed (%d)", result);
@@ -204,7 +204,7 @@ static int armjtagew_speed(int speed)
}
else
{
- LOG_INFO("Requested speed %dkHz, emulator reported %dkHz.", speed, speed_real);
+ LOG_INFO("Requested speed %dkHz, emulator reported %dkHz.", speed, speed_real);
}
return ERROR_OK;
@@ -218,6 +218,14 @@ static int armjtagew_khz(int khz, int *jtag_speed)
return ERROR_OK;
}
+static int armjtagew_speed_div(int speed, int* khz)
+{
+ *khz = speed;
+
+ return ERROR_OK;
+}
+
+
static int armjtagew_init(void)
{
int check_cnt;
@@ -248,6 +256,9 @@ static int armjtagew_init(void)
LOG_INFO("ARM-JTAG-EW initial read failed, don't worry");
}
+ // Initial JTAG speed (for reset and initialization): 32 kHz
+ armjtagew_speed(32);
+
LOG_INFO("ARM-JTAG-EW JTAG Interface ready");
armjtagew_reset(0, 0);
@@ -488,6 +499,11 @@ static int armjtagew_get_version_info(void)
usb_in_buffer[1], usb_in_buffer[0], \
isgraph(usb_in_buffer[2]) ? usb_in_buffer[2] : 'X', \
sn, auxinfo);
+
+ if (1 != usb_in_buffer[1] || 6 != usb_in_buffer[0])
+ {
+ LOG_WARNING("ARM-JTAG-EW firmware version %d.%d is untested with this version of OpenOCD. You might experience unexpected behavior.", usb_in_buffer[1], usb_in_buffer[0]);
+ }
return ERROR_OK;
}
@@ -515,9 +531,11 @@ static const struct command_registration armjtagew_command_handlers[] = {
struct jtag_interface armjtagew_interface = {
.name = "arm-jtag-ew",
.commands = armjtagew_command_handlers,
-
+ .transports = jtag_only,
+
.execute_queue = armjtagew_execute_queue,
.speed = armjtagew_speed,
+ .speed_div = armjtagew_speed_div,
.khz = armjtagew_khz,
.init = armjtagew_init,
.quit = armjtagew_quit,
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken wrote: > Hi Xiaofan > > In my case I struggled with the same problem for a day or two. That is why > I need to know if it is the checkout of the version, or the updating of the > mingw32 compiler that fixed the problem. > > After doing the ./bootstrap command, the head revision of JimTCL is cloned > from its repository - afaik. Thus, to get version 0.63 checked out do the > following > cd jimtcl > git tag -l (Gives you a list of the tags for the jimtcl repository) > git checkout 0.63 > > The version of Jimtcl in the directory should now be 0.63. To view the tags > of the openocd source, and checkout for instance 0.5.0-rc2 the same > procedure is used. > > Hopefully this helps, cause I've been trying to replicate the problem > without success for a while now. > This is clear now. I will make sure that my MinGW/Cygwin setup are up to date and see if that helps. If not, I will follow your suggestion and downgrade jimtcl to see if that help. Thanks for the helps! -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
