On Sat, Nov 13, 2010 at 1:28 AM, Peter Stuge <pe...@stuge.se> wrote: >> There's specific HDR and similar commands in svf to define these >> paddings. > > Can you say more about them? Did you study the SVF output by > FlashPro? It would be interesting to diff a failing SVF with a > working one. >
Yeah I've just been looking into them more. Basically the svf with chain information is exactly the same as non-chain except for a nice header block. They basically just put the lpc into bypass mode which leaves a 1 bit data register in the jtag chain. The header/trailer commands then just specify (to openocd) this extra padding bit on any data command and (in my case) 4 bits of padding on any instruction command. >From Xilinx xapp503: To reduce the size of an SVF file, the SVF specification provides four global padding instructions: Header Instruction Register (HIR), Trailer Instruction Register (TIR), Header Data Register (HDR), and Trailer Data Register (TDR). HIR length TDI(tdi) SMASK(smask) [TDO(tdo) MASK(mask] #Specifies bits to follow subsequent Shift-IR instructions. TIR length TDI(tdi) SMASK(smask) [TDO(tdo) MASK(mask] #Specifies bits to precede subsequent Shift-IR instructions. HDR length TDI(tdi) SMASK(smask) [TDO(tdo) MASK(mask] #Specifies bits to follow subsequent Shift-DR instructions TDR length TDI(tdi) SMASK(smask) [TDO(tdo) MASK(mask] #Specifies bits to precede subsequent Shift-DR instructions. Note: SVF “Header” instructions specify padding bits at the end of a shift pattern, while “Trailer” instructions specify padding bits at the beginning of a shift pattern. This is a common point of confusion and can initially seem counterintuitive. These global commands specify the number of bits to pad the beginning and end of a shift operation, to account for bypassed devices, and provide a simple method of SVF file compression. Once specified, these bits lead or follow every set of bits shifted for the SIR or SDR commands. It's up the the svf parser (ie openocd) to add these specified padding bits to all subsequent commands. Luckily for me support for these commands is already included in openocd's svf module. > >> Some software like UrJtag ignores these commands if they even exist >> and figures them out itself by scanning the chain, this is neat. > > I think this is the only sensible behavior. > > >> The svf player in openocd doesn't have anything like this (and I don't >> have time right now how to figure out how to add it, maybe later), so >> you're left with generating the svf files to be aware of the chain, if >> the software making the svf has this functionality. > > Or maybe OpenOCD can patch in the neccessary stuff into the SVF? > Yeah I would like to add automatic support for this in openocd, it really would be quite trivial. Basically add an optional switch to the svf command to target a specific tap which would then ignore any header/trailer commands in the svf and run the appropriate command before running the supplied svf. > 3 minutes is also really slow imo, but it is what it is because of > how the simple interfaces work. I've ranted enough about that before. > Yep 3 minutes does feel like an eternity if you sit and watch it. To be fair Altium's programmer does take pretty much just as long, it's their own custom hardware based on a LPC2888 (usb 2 high speed) which is supported by Alium and nothing else. Personally I'm not changing my fpga code much currently and I want openocd support primarily for production guys to use, where 3 minutes I'm sure will be annoying but not the end of the world. The fact that it works is the most important aspect. Higher jtag clock speed might help too. > Thanks! Maybe another option would be for you to just submit a patch > with the above board file for your board, with some comments in it? > Yeah I thought about submitting a board file but as it's a completely custom hardware setup (it's composed of 3 pcb's wired together haphazardly) it's not really relevant except as a generic sample. Is this really suitable for inclusion as a board.cfg? For reference here's a svf header for my chain (trimmed and commented by me) >!# Chain header for configuration of: >!# tap 1: jtag newtap lpc3131 cpu -irlen 4 -expected-id 0x07926f0f >!# tap 2: jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf >!# >STATE RESET; >RUNTEST IDLE 5 TCK 200E-6 SEC; >ENDIR IDLE; >SIR 12 TDI(00f) TDO(000) MASK(000); !# put lpc IR = 0xF (bypass mode), and >a3p IR = 0x00 (do nothing?) >ENDIR IRPAUSE; >HDR 1 TDI(0); !# Set 1 bit of data header padding (lpc bypass >register at start of chain) >HIR 4 TDI(f); !# Set 4 bits of instruction header padding (lpc 4 bits >of IR at start of chain) >TDR 0; !# no trailer padding (no taps on chain after a3p) >TIR 0; >!# >!# >!# Continue with rest of original SVF >FREQUENCY 4E6 HZ; >STATE RESET; >RUNTEST IDLE 5 TCK; >ENDIR IRPAUSE; >ENDDR DRPAUSE; >SIR 8 TDI(0F); >SDR 32 TDI(00000000); >STATE IDLE; >RUNTEST IDLE 1 TCK; >SDR 32 TDI(00000000) TDO(03A121CF) MASK(06FFFFFF); >!#.... The original header from actel had a few extra tests than is here, I trimmed it to basically the minimum that works, and these commands would be very easy to auto generate. Not sure if/when I might find time to add this to openocd though. Pretty easy to add these commands to a SVF manually in the mean time. This header is certainly worth having on the wiki page about SVF I feel. Andrew _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
