Re: [Openocd-development] 1.0 or 0.1?
On Jan 13, 2009, at 11:35 PM, Øyvind Harboe wrote: The difference between 0.1 and 0.7 is entirely in perception. The version numbers are effectively arbitrary since we have never made any other versioned release. If we are going to use 0.x (the two responses I got have both suggested that path), we might as well start with the beginning of the minor version number space (0.1) rather than an arbitrary point in the middle. You're contradicting yourself. You say that the version # is about perception, then you say that 0.7 is arbitrary. The two are not mutually exclusive. Since there have been no versioned releases, the first number is entirely arbitrary since we need to pick a number but it has no meaning within the project itself. But it also means that users will perceive a meaning based on comparisons to other projects. 0.7 indicates 70% done to me. Very much workable, but not a finished product. Sure, but 0.1 can just as easily indicate the first release that we feel is acceptable for users to test. The number has no intrinsic meaning at this point since it is the first one. Any meaning attached to the number isn't likely to make any sense to a general user. In fact, choosing something like 0.7 could just as easily cause more confusion than confidence. Someone will ask where versions 0.1-0.6 are. Saying we chose 0.7 because we wanted people to have more confidence that it was stable or because we wanted to give the impression that it was close to a 1.0 feels like an attempt to mislead. A JTAG debugger is 100% done by the time it is obsolete, so it is a product, unlike others that *must* and *should* be used before it is finished. Every software project suffers the same fate. There are always new features to add, bugs to fix, and better architectures. Version 1.0 doesn't mean a project is done, just that it has reached a point where it is good enough for general use. Otherwise, Microsoft Office wouldn't be working on version 14.0. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
> The difference between 0.1 and 0.7 is entirely in perception. The version > numbers are effectively arbitrary since we have never made any other > versioned release. If we are going to use 0.x (the two responses I got have > both suggested that path), we might as well start with the beginning of the > minor version number space (0.1) rather than an arbitrary point in the > middle. You're contradicting yourself. You say that the version # is about perception, then you say that 0.7 is arbitrary. 0.7 indicates 70% done to me. Very much workable, but not a finished product. A JTAG debugger is 100% done by the time it is obsolete, so it is a product, unlike others that *must* and *should* be used before it is finished. -- Ø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] 1.0 or 0.1?
On Jan 13, 2009, at 9:11 PM, Dean Glazeski wrote: I wanted to say that keeping OpenOCD in the 0.x space seems like a bad idea. There's no point in such a system because the x just becomes the version number for the product, so you may want to consider going to version x. I've always thought the kernel was strange for locking at 2.6.x and I found Java even stranger for staying at 1.0.x. I have no experience with version numbers, but I thought I would throw in my two cents. // Dean Many projects use the x.y.z version numbering scheme. X is the major version, Y is the minor, and Z is the patch level. The idea is that a change that breaks compatibility in a major way or an architectural change causes the major version to be incremented. New features and/ or enhancements that don't break compatibility or change the architecture significantly result in the minor version being incremented. Bug fixes with no significant feature set change result in a patch level increment. For OpenOCD, you can think of 0.1 as 0.1.0. The implication is that the code base doesn't have a stable architecture so the major version is 0. It is the first release in the 0.y.z series, so the minor is set to 1 and the patch level to 0. As bugs are fixed, subsequent releases will have the patch level incremented. If a new feature or enhancement is introduced, the minor version is incremented. Once the architecture and config file syntax settles down, the first stable release can be made and the major version will be set to 1. Java actually follows this pattern for their versioning, but it tracks the language rather than the VM or support libraries. Since Java has not had a major design change to the language, the major version is still 1. There have been new features introduced, so the minor version has changed over the years (currently 1.6). The patch level has also been incremented regularly as they do bugfix releases. Where it gets confusing is that they chose a different marketing version from the release version. Java 6 is really release version Java 1.6.z. The Linux kernel has been bad about following their versioning scheme. The major version is stuck at 2.y.z because there has not been a significant major design or architecture change. The minor version does change but they seem to do so when they feel like it rather than when major features are introduced. The patch level changes for each release even if it sometimes contains new features or major enhancements. I would be perfectly happy to use the x.y.z versioning scheme. As I suggested above, I'd start with 0.1.0 and update the numbers as appropriate for each release. We would eventually get to 1.0.0, but only once we are comfortable with declaring the architecture and config syntax are stable. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
Rick Altherr wrote: On Jan 13, 2009, at 11:13 AM, Michael Schwingen wrote: Øyvind Harboe wrote: OpenOCD can *NEVER* be "1.0" in that there will always be a non-trivial effort required on the developers side to get things working. That depends a bit on the feature set that is required for a 1.0 release. If we select platforms that are completely supported (say, ARM7 and XScale?), and get the configuration management to a state where the user only needs to tweak a supplied config file a bit for his board, I think this could be called 1.0 - a 1.0 release does not need to support every device in the world. I think it is just a matter of taste where we draw the line of what needs to be stable for a release. However, having a stable config file syntax that does not change shortly after 1.0 would be good for users. I'd say that 0.9 is as finished as a hardware debugger will ever be if it is to be anything like remotely current w.r.t. hardware out there. So, I vote for 0.7 :-) Fine with me. Now if the development speed stays the same, I do think we should be able to reach something that can be called 1.0 during this year. cu Michael The difference between 0.1 and 0.7 is entirely in perception. The version numbers are effectively arbitrary since we have never made any other versioned release. If we are going to use 0.x (the two responses I got have both suggested that path), we might as well start with the beginning of the minor version number space (0.1) rather than an arbitrary point in the middle. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I wanted to say that keeping OpenOCD in the 0.x space seems like a bad idea. There's no point in such a system because the x just becomes the version number for the product, so you may want to consider going to version x. I've always thought the kernel was strange for locking at 2.6.x and I found Java even stranger for staying at 1.0.x. I have no experience with version numbers, but I thought I would throw in my two cents. // Dean ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
On Jan 13, 2009, at 11:13 AM, Michael Schwingen wrote: Øyvind Harboe wrote: OpenOCD can *NEVER* be "1.0" in that there will always be a non- trivial effort required on the developers side to get things working. That depends a bit on the feature set that is required for a 1.0 release. If we select platforms that are completely supported (say, ARM7 and XScale?), and get the configuration management to a state where the user only needs to tweak a supplied config file a bit for his board, I think this could be called 1.0 - a 1.0 release does not need to support every device in the world. I think it is just a matter of taste where we draw the line of what needs to be stable for a release. However, having a stable config file syntax that does not change shortly after 1.0 would be good for users. I'd say that 0.9 is as finished as a hardware debugger will ever be if it is to be anything like remotely current w.r.t. hardware out there. So, I vote for 0.7 :-) Fine with me. Now if the development speed stays the same, I do think we should be able to reach something that can be called 1.0 during this year. cu Michael The difference between 0.1 and 0.7 is entirely in perception. The version numbers are effectively arbitrary since we have never made any other versioned release. If we are going to use 0.x (the two responses I got have both suggested that path), we might as well start with the beginning of the minor version number space (0.1) rather than an arbitrary point in the middle. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] stm32 primer rlink under ubuntu 8.04
Jörg Krein pisze: > Tried it with Code::Blocks IDE and the Codesourcery gdb but it crashed. codesourcery's gdb is broken in all 2008q3 releases. i wrote about that on their list, but so far no response... http://www.codesourcery.com/archives/arm-gnu/msg02439.html i don't know whether it's the new version of gdb or just the codesourcery bug. slightly older gdb from yagarto works fine for me. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] stm32 primer rlink under ubuntu 8.04
Hi, found the time to do further testing. Was able to flash a hex file and run it. :-) Next will be debugging with gdb. Tried it with Code::Blocks IDE and the Codesourcery gdb but it crashed. Didn't set up gdb for Cortex so far. For the STR7 and older OpenOCD version I used to send some commands like monitor reset, monitor hardware_breakpoints enabled, etc. Is this the case for the STM32 too? Greets, Joerg ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm11 testers
Hi Oyvind, On Mon, Jan 12, 2009 at 8:18 PM, Øyvind Harboe wrote: >> I am not familiar to BSDL file, then I need to study more about it to >> verify if our imx31.cfg file is correct. >> Any material about how to decode this kind of file is welcome. > > The primary information I need at this point is a crisp explanation > of what the JTAG chain contains. Of course I could read this up > in the datasheets, but I'd rather concentrate the time I have available > on OpenOCD specific problems rather than becoming an imx31 expert. > I am searching it, but it is not easy to find. I can validate one device from BSDL: "0010" & -- Version "000110" & -- Design Center Number "010001" & -- Sequence Number "0001110" & -- Manufacturer Identity "1"; -- IEEE 1149.1 Requirement It is exactly the SDMATAPID 0x2190101d. But I think there is some error in your imx31.cfg because the IR Length for this device is 5 not 4 as defined in config file. > Thanks! > Best Regards, > -- > Øyvind Harboe > http://www.zylin.com/zy1000.html > ARM7 ARM9 XScale Cortex > JTAG debugger and flash programmer > Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
Øyvind Harboe wrote: > OpenOCD can *NEVER* be "1.0" in that there will always be a non-trivial > effort required on the developers side to get things working. > That depends a bit on the feature set that is required for a 1.0 release. If we select platforms that are completely supported (say, ARM7 and XScale?), and get the configuration management to a state where the user only needs to tweak a supplied config file a bit for his board, I think this could be called 1.0 - a 1.0 release does not need to support every device in the world. I think it is just a matter of taste where we draw the line of what needs to be stable for a release. However, having a stable config file syntax that does not change shortly after 1.0 would be good for users. > I'd say that 0.9 is as finished as a hardware debugger will ever be if > it is to be anything like remotely current w.r.t. hardware out there. > > So, I vote for 0.7 :-) > Fine with me. Now if the development speed stays the same, I do think we should be able to reach something that can be called 1.0 during this year. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Looks like a typo in configure.in : LDFLAGSis ignored during configure.
> > Looks like a typo in configure.in - the configure process > ignore LDFLAGS in the environment. > > Here is a patch > > > Index: configure.in > === > --- configure.in (revision 1312) > +++ configure.in (working copy) > @@ -464,12 +464,12 @@ ># And calculate the LDFLAGS for the machine >case "$host_cpu" in >i?86|x86_*) > - LDFLAGS="$LFLAGS -L$with_ftd2xx_win32_zipdir/i386" > + LDFLAGS="$LDFLAGS -L$with_ftd2xx_win32_zipdir/i386" > LIBS="$LIBS -lftd2xx" > f=$with_ftd2xx_win32_zipdir/i386/ftd2xx.lib > ;; >amd64) > - LDFLAGS="$LFLAGS -L$with_ftd2xx_win32_zipdir/amd64" > + LDFLAGS="$LDFLAGS -L$with_ftd2xx_win32_zipdir/amd64" > LIBS="$LIBS -lftd2xx" > f=$with_ftd2xx_win32_zipdir/amd64/ftd2xx.lib > ;; > > Regards > > Francois > ___ committed Many Thanks Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
On Tue, Jan 13, 2009 at 8:36 AM, Michael Schwingen wrote: > > Rick Altherr wrote: > > It's been a while since any talk about 1.0 has flown by on the list. > > My take on recent developments is that calling what we have today 1.0 > > is a bit of a stretch. The ToT codebase works on in a few > > interface/target combinations, but there are still lots of mysterious > > errors. My investigations into how to add Cortex-A8 support has led > > down a few thought experiments that would cause major changes to both > > the code base and to the configuration syntax. All of these things > > don't make the current ToT feel like a 1.0. Since the main intent of > > a versioned release is to provide an easy way for users to obtain and > > build a known version, we don't really need to have an extremely solid > > first release. I'd suggest that we clean up the current ToT and > > release a 0.1. That way, the various package maintainers can use a > > known version and hopefully users will focus on using 0.1 instead of > > battling with the current ToT and the bugs it has had introduced. > I think it feels more like at least 0.5, or even 0.9 - depending on > target. However, it is just a number, for me, any will do fine as long > as we *do* a release. OpenOCD can *NEVER* be "1.0" in that there will always be a non-trivial effort required on the developers side to get things working. I'd say that 0.9 is as finished as a hardware debugger will ever be if it is to be anything like remotely current w.r.t. hardware out there. So, I vote for 0.7 :-) -- Ø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