Re: [Openocd-development] JTAG speed limit?
Duane Ellis wrote: What type of jtag dongle are you using that does 20mhz TCK? Perhaps 20mhz works for you - but on my board - the scope says otherwise. Perhaps - it is my board and other boards I've used :-( At those speeds, signal integrity becomes a real issue - I have been bitten by that in the past. However, with proper layout and termination on the JTAG signals, 20MHz does not sound impossible - I have regularly used 16MHz JTAG clock with a BDI2000 and ~10cm bunch-of-single-wires cable. Using flat cable with every second wire grounded, and properly matched series termination, should make this possible at longer cable length, too. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
On Wed, Dec 3, 2008 at 9:28 PM, Rick Altherr [EMAIL PROTECTED] wrote: On Dec 3, 2008, at 12:17 PM, Øyvind Harboe wrote: Either it should be part of the main OpenOCD source base or it should be separate project. If it is just a flash, interface, and target driver, then it should just be part of the mainline source base. If it is more than that, it isn't really part of OpenOCD. It *is* part of the main openocd source base. This is just a technicality w.r.t. avoiding excessive download sizes for those that don't need those bits. It looks like it contains the build environment for the zy1000 firmware which _uses_ OpenOCD but isn't part of OpenOCD. The whole point of a version control system is to be able to go back and *build* some older version. The zy1000 directory contains the prerequisites to build the binary. embedded is different from building for developer operating systems. It is also an embedded version of openocd, so it is built very differently from openocd hosted on a developer OS. Exactly, it isn't part of OpenOCD, but rather a user of OpenOCD. Just because OpenOCD does a release doesn't mean that the zy1000 build environment needs to be changed. For example, OpenOCD might release 1.0.1 that contains a big bug that makes the zy1000 non-functional. It is completely reasonable in that case for the zy1000 build scripts to use OpenOCD 1.0 instead with no real impact. Note that the zy1000 directory also contains *code* for openocd, not only the build scripts. All of that code, combined, is GPL and there is no way to mix and match versions of tools and other code that goes into the final mix. It is not necessary to complicate the life of most developers out there with the nasty bits that goes into building an embedded product and a separate folder solves this. The ZY1000 is a commercial product built on top of OpenOCD. The scripts and files necessary to build the ZY1000 firmware are not part of OpenOCD. They are part of the ZY1000 software. OpenOCD is simply a component of the ZY1000 software. What are you trying to say here? OpenOCD is GPL and ZY1000 uses OpenOCD, so the resulting code is GPL. Where does commerical enter into it? GPL does not mean non-commerical. In fact commercial and non-commerical is equal from GPL's point of view. What's the problem you're trying to address? What are you suggesting? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
One thing though: I expect the release cycle of embedded releases(ZY1000 is the first OpenOCD embedded version) to be different than that of developer operating system hosted OpenOCD. From that point of view the zy1000 folder does not need to be in the release branch and the current arrangment is fine. Leave things as-is, problem solved. :-) Sorry for the confusion. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
Is the zy1000 directory necessary for OpenOCD development? If not, then it should be treated as a separate project and have its own trunk.. If zy1000 needs to track with OpenOCD, that's up to the zy1000 maintainers. Didn't even realise we had a zy1000 trunk? Personally i think it should be a seperate project. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn r1194 - fixing for str9
Can one of you help me with the str9 issues? I'm sort of stuck. I have had a quick look - very broken. I will see if i can get to the problem. trunk is now working with the str9xpec driver. I am going to add a some info in the docs on its correct use. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
On Dec 3, 2008, at 12:38 PM, Øyvind Harboe wrote: On Wed, Dec 3, 2008 at 9:28 PM, Rick Altherr [EMAIL PROTECTED] wrote: On Dec 3, 2008, at 12:17 PM, Øyvind Harboe wrote: Either it should be part of the main OpenOCD source base or it should be separate project. If it is just a flash, interface, and target driver, then it should just be part of the mainline source base. If it is more than that, it isn't really part of OpenOCD. It *is* part of the main openocd source base. This is just a technicality w.r.t. avoiding excessive download sizes for those that don't need those bits. It looks like it contains the build environment for the zy1000 firmware which _uses_ OpenOCD but isn't part of OpenOCD. The whole point of a version control system is to be able to go back and *build* some older version. Correct, and anyone can go build OpenOCD 1.0 once it is tagged without the contents of the zy1000 directory. The zy1000 directory contains the prerequisites to build the binary. To build the zy1000 firmware, not OpenOCD. embedded is different from building for developer operating systems. Yup, but zy1000 is not OpenOCD. It is a separate project. It is also an embedded version of openocd, so it is built very differently from openocd hosted on a developer OS. Exactly, it isn't part of OpenOCD, but rather a user of OpenOCD. Just because OpenOCD does a release doesn't mean that the zy1000 build environment needs to be changed. For example, OpenOCD might release 1.0.1 that contains a big bug that makes the zy1000 non-functional. It is completely reasonable in that case for the zy1000 build scripts to use OpenOCD 1.0 instead with no real impact. Note that the zy1000 directory also contains *code* for openocd, not only the build scripts. All of that code, combined, is GPL and there is no way to mix and match versions of tools and other code that goes into the final mix. If the zy1000 build scripts patch OpenOCD, that's fine, but it doesn't mean that the zy1000 scripts must be tied to OpenOCD releases or that the zy1000 firmware is part of the OpenOCD project. If anything this is more evidence that the zy1000 is a separate project that extends OpenOCD and should be treated as a separate project. It is not necessary to complicate the life of most developers out there with the nasty bits that goes into building an embedded product and a separate folder solves this. Exactly, we shouldn't complicate the state of affairs for the majority of developers. So, the trunk should contain the OpenOCD release. That does not include the patches to build support for the zy1000. The build system and patches for the zy1000 should be maintained separately. The ZY1000 is a commercial product built on top of OpenOCD. The scripts and files necessary to build the ZY1000 firmware are not part of OpenOCD. They are part of the ZY1000 software. OpenOCD is simply a component of the ZY1000 software. What are you trying to say here? That OpenOCD and the ZY1000 are separate projects. OpenOCD is a piece of software designed to run on a variety of OSes and utilize a variety of JTAG interfaces. The ZY1000 is a device containing both hardware and software. The software for the ZY1000 is a specific OS and a modified version of an OpenOCD release. OpenOCD is GPL and ZY1000 uses OpenOCD, so the resulting code is GPL. OpenOCD is an application running on the OS packaged as part of the ZY1000. Not all of the ZY1000 is required to be GPL nor does licensing have anything to do with whether the two projects should be treated as one. Where does commerical enter into it? GPL does not mean non- commerical. In fact commercial and non-commerical is equal from GPL's point of view. That OpenOCD is free and the ZY1000 is not is simply another distinction that they are 2 separate projects with different goals and deliverables. What's the problem you're trying to address? Tying the two into a common directory structure means that when OpenOCD releases version 1.0, the ZY1000 firmware will also become version 1.0. While the two might have release coincide frequently, this links all ZY1000 firmware versions to an corresponding OpenOCD version. If a bug in a non-OpenOCD portion of the ZY1000 firmware was to be fixed but no changes were made in the OpenOCD portion, there is no reason to make a new OpenOCD version, yet the layout of the repository would cause a new version of OpenOCD to be tagged. What are you suggesting? Treat OpenOCD and ZY1000 as separate projects. Lay out the directory structure like: openocd/ trunk/ tags/ branches/ zy1000/ trunk/ tags/ branches/ That way the zy1000 firmware can be versioned independently of OpenOCD. The zy1000 scripts can check out a specific version of OpenOCD so the version locked changes can be handled gracefully when
Re: [Openocd-development] svn needs to be shuffled around a bit
Treat OpenOCD and ZY1000 as separate projects. Lay out the directory structure like: openocd/ trunk/ tags/ branches/ zy1000/ trunk/ tags/ branches/ Super! That will work just fine. The only thing is that when you rearrange trunk into openocd/trunk+tags+branches you will be pulling the rug out from underneath a lot of developers out there. They will have to check out from openocd/trunk, so give advance notice before you do this. SVN has a global version number which solves a lot of problems on synching up trunk of multiple projects. Very nice. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
Treat OpenOCD and ZY1000 as separate projects. Lay out the directory structure like: openocd/ trunk/ tags/ branches/ zy1000/ trunk/ tags/ branches/ Super! That will work just fine. But why not just have a seperate berlios project and svn repo for zy1000? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
I don't see a problem here, if Oyvind wants Branch/Tag/Trunk - under
ZY1000 - just do this:
rename ${REPO}/zy1000 ${REPO}/zy1000.tmp
mkdir${REPO}/zy1000/branch
mkdir${REPO}/zy1000/tag
rename ${REPO}zy1000.tmp ${REPO}/zy1000/trunk
Nobody knows this happens.
It is a modified form of what is in the SVN Book Chapter 4 and/or 5
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn r1194 - fixing for str9
spen trunk is now working with the str9xpec driver. spen I am going to add a some info in the docs on its correct use. Thanks. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA270: can read/write the core registers, but can't read memory and registers of the devices on chip
dswei wrote [pxa270 - I can change cpu regs, not memory, target is in USER mode] Question #1 - Did this work with an older version of OpenOCD or is this the first time you used this? Question #2 - Maybe UBOOT is turning the CPU cache on and configuring the MMU in some special way? Maybe below describes the problem? For example - maybe UBOOT has configured virtual memory to be *NOT*PRESENT* at location 0 (and others). I do not know if there is a virt-phys translation command for the pxa270. :-( I do not have a pxa270 platform to test with sorry. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn r1194 - fixing for str9
spen trunk is now working with the str9xpec driver. spen I am going to add a some info in the docs on its correct use. duane Thanks. FYI - It checks out on my str912-sk (iar starter kit board). I did not flash, I just fiddled with reset/halt/step/etc. Seems just fine. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
On Thu, Dec 4, 2008 at 12:49 AM, Duane Ellis [EMAIL PROTECTED] wrote:
I don't see a problem here, if Oyvind wants Branch/Tag/Trunk - under ZY1000
- just do this:
rename ${REPO}/zy1000 ${REPO}/zy1000.tmp
mkdir${REPO}/zy1000/branch
mkdir${REPO}/zy1000/tag
rename ${REPO}zy1000.tmp ${REPO}/zy1000/trunk
Nobody knows this happens.
Committed.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svn needs to be shuffled around a bit
The OpenOCD and the ZY1000 must be separate projects. openocd/trunk/... zy1000/trunk/... We cannot expect to have in the OpenOCD project any BINARY file as a .bit for the on-board PLD). Also, please move the 'ecos' folder to you new project. Why an eCos folder in OpenOCD ? In the next months we will see other very low-cost TCP/IP + XSCALE + LINUX Embedded platform to run OpenOCD. We cannot expect to get all the stuff of these new embedded debuggers (CPLD .bit, Linux .hex) in the OpenOCD project. OpenOCD is the application, not the platform ! Laurent at amontec . com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
On Thu, Dec 4, 2008 at 8:32 AM, Laurent Gauch [EMAIL PROTECTED] wrote: The OpenOCD and the ZY1000 must be separate projects. openocd/trunk/... zy1000/trunk/... This is the way it is already. There is only the matter of timing w.r.t. when the trunk folder is moved to openocd/trunk to follow this convention so as to minimize the disruption. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svn needs to be shuffled around a bit
why the ecosflash folder in the OpenOCD ? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn needs to be shuffled around a bit
On Thu, Dec 4, 2008 at 8:47 AM, Laurent Gauch [EMAIL PROTECTED] wrote: why the ecosflash folder in the OpenOCD ? All eCos flash drivers can be used by OpenOCD even if the target does not run eCos. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
