I am using gnice+ cable with FT4232H and my target is PXA270 (Marvell). With FT2232H/FT4232H, maximum possible TCLK is supposed to be 30MHz, but I had a problem in getting TCLK above 6MHz. I used to get buffer error. after updating the code with latest svn (which is supposed to increase the through put by 6%),things looks very slow and not able to complete the flashing at 6Mhz, working fine with 3Mhz and things are fine.
Is there any changes needs to be implemented in PXA270 specific level? Regards, Ashok [email protected] wrote: > Send UrJTAG-development mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/urjtag-development > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of UrJTAG-development digest..." > > > Today's Topics: > > 1. Re: Shared library conventions (Was: Revert r1748) > (Mike Frysinger) > 2. Re: Shared library conventions (Was: Revert r1748) (CeDeROM) > 3. Re: [RFC] Optimize TMS clocks for FT2232 (Arnim L?uger) > 4. Re: Shared library conventions (Was: Revert r1748) > (Mike Frysinger) > 5. Re: [RFC] Optimize TMS clocks for FT2232 (Jie Zhang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 4 Feb 2010 16:31:30 -0500 > From: Mike Frysinger <[email protected]> > Subject: Re: [UrJTAG-dev] Shared library conventions (Was: Revert > r1748) > To: CeDeROM <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > On Thursday 04 February 2010 15:51:03 CeDeROM wrote: > >> On Thu, Feb 4, 2010 at 8:14 PM, Mike Frysinger wrote: >> >>> i'm more than familiar with shared library policies, but for something >>> that has grown organically like urjtag, i dont think it's reasonable to >>> try and get it "perfect" the first time. if we screw up, we bump the >>> SONAME and then we dont have to keep baggage around. i honestly dont >>> think urjtag is an important enough piece of software atm that bumping >>> the SONAME is going to cause enormous grief. >>> >> Well, to be honest this kind of attitude "we can bump it" made me >> leave Linux in favour of FreeBSD, where almost everything in API and >> config looks the same for years and some new functionalities are >> added/expanded but not replacing the old ones each time they show up >> > > are you sure ? first of all, FreeBSD user<->kernel is the exact opposite of > Linux -- they have evertyhing intertwined so that they can break ABI as they > like. g'luck taking a FreeBSD-4 binary and running it with FreeBSD-7. > however, any Linux userspace binary should continue to work because the > syscall ABI has been set in stone. > > plus, the default FreeBSD library policy is terrible. just look at the > soname > conventions used in libtool. that's why for the Gentoo/FreeBSD port, we > actually change the convention to use Linux SONAME policies. we get sane > upgrade paths. > > as for the "we can bump it" attitude, that really isnt specific to any Linux > distribution. that is coming from the people packaging the software directly > and they're OS independent (just like urjtag). > > >> UrJTAG is pretty mature as for now I think and we can try to >> figure out some generic API that won't have to change with the >> underlying stuff. >> > > yes, UrJTAG as command line software is pretty mature, but that doesnt have > any bearing on the library API/ABI. we havent made a single release with the > library interface in it, so any claims about its maturity is, frankly, > premature. > > >> I do agree that UrJTAG may not the broadway star >> across the world software (for me that is okay), so some screwups can >> happen (as always), but they should not be our assumption - the >> assumption should be interoperability, generic interface, >> expandability and backward compatibility... I am not talking about >> total reorganization of the current API, but also not to changing it >> every bump, possibly to avoid the bumps at all by expanding library >> with some helper functions - maybe by working on these basic >> functions... >> > > i'm not talking about bumping it every time or taking the approach loosely. > i > am talking about the first release or two being "developer previews" without > any stable guarantee. > > we also dont have any symbol versioning support in here, so until that's > done, > i dont think talking about a stable ABI is appropriate. > > >> I dream about UrJTAG library to be a set of functions loadable by a >> nice Python script with GUI that can always work the same way, even >> with the next 10th or 50th release of urjtag library. >> > > sure, but not the 1st or 2nd :P > > >> I think this is a good time to start such discussion and try to >> implement it in one of the next releases - there are many people >> already that I know awaiting for the UrJTAG as a library :-) >> > > here's a concrete statement for you to cut your teeth on: any stable ABI > discussion is completely moot as long as internal storage is directly > accessible and the layout of structures are not hidden completely. the only > thing that may be exported are functions. > -mike > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 836 bytes > Desc: This is a digitally signed message part. > > ------------------------------ > > Message: 2 > Date: Thu, 4 Feb 2010 22:51:36 +0000 > From: CeDeROM <[email protected]> > Subject: Re: [UrJTAG-dev] Shared library conventions (Was: Revert > r1748) > To: Mike Frysinger <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > Hello Mike! > > On Thu, Feb 4, 2010 at 9:31 PM, Mike Frysinger <[email protected]> wrote: > >> are you sure ? ?first of all, FreeBSD user<->kernel is the exact opposite of >> Linux -- they have evertyhing intertwined so that they can break ABI as they >> like. ?g'luck taking a FreeBSD-4 binary and running it with FreeBSD-7. >> however, any Linux userspace binary should continue to work because the >> syscall ABI has been set in stone. >> >> plus, the default FreeBSD library policy is terrible. ?just look at the >> soname >> conventions used in libtool. ?that's why for the Gentoo/FreeBSD port, we >> actually change the convention to use Linux SONAME policies. ?we get sane >> upgrade paths. >> > > Well there is no problem with running release 6 or 7 binaries on 8 > release as I do this for example with OpenOffice - apropriate loaders > are provided with the system. Indeed there are some little issues that > from release a library name changes version ie. libm.so.4 -> libm.so.5 > but that can be easily fixed. There are also tools to upgrade or > install packages that automaticaly resolves conflicts (ie. > portupgrade, portinstall). But the most important thing for me is that > the directory structure, configuration files, parse, etc are the same > - this standard allows me working on my problems not my system and if > I say "do this on your fbsd system" I can be almost sure that this > will work just as on my system :-) There are many different Linux > distros, each one of them use its own tools and configuration scheme, > packaging system etc - its hard to tell wether a program from one > distro will work on the other distro. I understand that new features > requires some changes in Linux and I really liked for instance the > ramfs infrastructure presented recently to the kernel, as I did some > porting stuff recently at work, but these features being added often > breaks compatibility (ie. alsa drivers for ich-sound). > > >> i'm not talking about bumping it every time or taking the approach loosely. >> ?i >> am talking about the first release or two being "developer previews" without >> any stable guarantee. >> >> we also dont have any symbol versioning support in here, so until that's >> done, >> i dont think talking about a stable ABI is appropriate. >> > > Fully agree. Maybe it is a good time to start? :-) There are a lot of > experienced users on the list dealing with many different sorts of > hardware, so maybe we can gather some kind of requests or ideas for > such a generic jtag library interface? :-) > > My first idea is to support JTAG and SWD (and probably others) with > the same function set, so the bus could be easily > initialized/deinitialized for devices using both of them - ie Rlink > cable can do JTAG and SWD, Rlink is installed on STM32Primer 1 and 2 > while Primer1 use JTAG and Primer2 use SWD - it would be nice to > simply select cable, mode and use the same function set to do the > programming... > > Maybe some function should set system default for bitswapping, maybe > this should be done with a separate function on a loaded buffer with > data, maybe this sould be done just when transferring buffer data to > the cable driver... > > Best regards, > Tomek > > > -- ------------------------------------------ Ashokkumar G P | Head - Hardware Geodesic Limited | www.geodesic.com Ph: +91 80 66551000 Mob: +91 98452 44057 ------------------------------------------ ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
