On Fri, Jan 15, 2021 at 01:46:35PM +0300, Paul Fertser wrote: > Hello, > > This is a multi-part review of the series, with general notes inline > in this message, and specific points raised as replies to the > individual patches. > > On Mon, Apr 13, 2020 at 03:29:14PM -0700, Ernesto Corona wrote: > > We propose to implement general JTAG interface and infrastructure > > to communicate with user layer application. > > Working with a Tioga Pass server platform I needed to use the JTAG > master controller of an ASPEED AST2500 SoC to configure a Lattice > LCMXO2-4000HC CPLD. I'm mentioning these fine details because that's > the only proper runtime testing I performed, but my review is not > limited to that. > > Being a long-time OpenOCD community member, I got familiar with many > different facilities and protocols offered by hardware JTAG adapters, > and of wide range of usecases as I was providing end-user > support. This is my perspective when looking at these patches. > > I have to note that the current v29 version of the series is broken in > several aspects: Is it correct that this series is actually abandoned so far? > 1. The aspeed driver fails probe(), see the driver review for details; > > 2. The uapi include header is unusable; > > 3. The offered userspace implementation wasn't updated to the latest > API, but even with the changes to make it compile it's still a mess > too horrible to be used in production; > > Points 1 and 2 will be addressed in separate mails. To workaround > point 3 I prepared a recipe with an additional patch[0] so that > mlnx_cpldprog can be at least compiled and used for some minimal > testing. > > The shortcomings of mlnx_cpldprog are numerous: > > 1. It doesn't consistently choose between hardware and bitbang modes; > > 2. Even though it checks TDO it doesn't print any errors on mismatch > and continues playing back the SVF as if it's all right; > > 3. It has JTAG speed hardcoded; > > 4. It doesn't implement RUNTEST so with the CPLD I'm using it's always > _not_ working properly, failing silently; > > 5. It is just awfully slow, taking about 40 minutes to play back a > file that takes 1.5 minutes with OpenOCD with the same hardware and > kernel driver. > > So I added support for the proposed API to OpenOCD: patch that applies > to the version in OpenBMC[1], patch for the latest version[2]. And > since it can do much more than just playing back SVF I hope this can > highlight some essential API shortcomings if it's meant to be > generic. My impression is that in its current state it's not adequate > for the purpose. > > [0] https://bitbucket.org/paulfertser/mlnx_cpldprog_bitbake > [1] http://openocd.zylin.com/#/c/5976/ > [2] http://openocd.zylin.com/#/c/5975/ -- With Best Regards, Andy Shevchenko
