2010/8/13 Stefano Babic <[email protected]>: > Frans Meulenbroeks wrote: >> I've build the code from git as I needed gpio jtag for my project. >> > > Hi Frans, > >> Code builds with a few minor issues, using openembedded. >> I had to make sure autoconf was run with -s. Root cause seems to be >> that a symlink is made to tools before the actual data is there. With >> symlinks this works. With hard copy it does not. >> Guess ideally something could change in the order of the tests so the >> tools stuff is there. >> >> Also somehow MKINSTALLDIRS got not detected properly, I just added >> MKINSTALLDIRS=tools/mkinstalldirs when doing make install >> I guess this is also caused by mkinstalldirs not being there when the >> test is run. >> >> Of course these things are not gpio related. > > I cannot confirm these issues. I ompiled for both i386 and ARM > architecture, using in the last case the ELDK toolchain. I have no > problem at all with the production. It seems to me the problems you > reported are related to the host system on in the environment you build.
Well the -s was simply added. However as I also stated in the email to Mike, -s tells autoconf to use soft links. If it fails without -s it just tells that the file that one is linking to does not exist yet. No big deal but in my humble opinion it means the order is a little bit illogical (but you may think differently about it). For the autotools I could not find the reason so just invoked make install overriding MKINSTALLDIRS > >> >> With these patches I managed to compile the code. When running on my >> target and setting the cable, detect did not work. >> It reported that TDO was stuck. > > It reads always the same value... Yes, it was always reading 1, despite my oscilloscope showing that the value changed. > >> I guess the cause is some initialisation weirdness or inconsistency in >> the kernel. By default all ports were reported as input by the kernel, >> but perhaps the hw is defaulting to output. > > The gpio cable driver makes no assumption, and try to set the pins as > output or input as it is required, using the sysfs interface. > However, on most processors including the Freescale i.MX where I tested, > it is required to setup the multiplex controller, if any. If this is not > correct (I do not know if it could be an issue with your processor), we > can always set the direction with sysfs, but nothing happens. > >> The gpio cable code sets the port to input, but that did not resolve >> things. I managed to get things going by explicitly toggling the TDO >> direction to output and back to input (either before starting urjtag >> or after starting urjtag but before doing anything. >> If I do that urjtag works like a charm using gpio. > > It seems to me there is an inconsistency in the kernel, as in the stored > structure the pin is set as output, but the hardware is programmed as > input. Howver, you could explicitely sets the direction in your machine > startup (I mean, in arch/powerpc/platforms/85xx/mpc8536_ds.c) and see if > it helps. I agree wrt your reasoning. I had expected the explict set to In to rewrite the register but apparently it does not. WIll try to peek at the mpc8536_ds.c file to see what is happening. Didn't get to it today. > >> It might be considered to toggle the gpio lines when initialising the cable. >> Otherwise perhaps add a small note somewhere in the documentation. > > Well, I do not think it is correct. As I said, I use another processor > that has not this issue, so it is not strictly related to urjtag. > Probably it is required to investigate further to check how the gpios > are initialized in kernel. Agree, will do. > >> >> Thanks urjtag developers for this nice piece of code and Stefano for >> the gpio support. > > You're welcome, > > Stefano Best regards, Fans ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
