If there was a performance regression due to the changes I made, then that's a red herring and it's just a weird side effect of something I broke.
On Thu, May 7, 2009 at 6:38 PM, David Brownell <davi...@pacbell.net> wrote: > One of the patches since the merge of the ti_dm355.cfg line-end > update seems to have broken some aspect of scan chain discovery. > See the openocd server startup transcript below, with "scan_chain" > command debug output. (FWIW, using with an Olimex ft2232 adapter.) Can you do a bisection to figure out which version broke you? Try out a version in the middle between the last known good version and svn head. You can then continue to divide down to the precise version that broke you. > The recent TAP changes forced a slowdown from 3 MHz to 1.5 MHz; > "why" is unclear to me, but the failure mode was similar: it > found just the last of the three TAPs listed (i.e. the one that > is hooked up right next to TDI on the SoC). I believe the slowdown is a red herring... > > Which suggested a potential workaround here: slow TCK down even > more. Sure enough, at 750 KHz the startup doesn't fail... > > I'm hoping that this recent trend of needing to halve the clock > rate after each "svn up" can be halted and then reversed. There > would seem to be some hard limits coming up soon ... ;) I'm pretty confident I can restore full warp power with a bit of debug help from your side... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
