Re: [PATCH v29 0/6] JTAG driver introduction

[Andy Shevchenko <andriy.shevchenko@intel.com>]

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