Re: [patch v6 0/3] JTAG driver introduction

[Rick Altherr]

On Fri, Aug 25, 2017 at 1:32 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> On Thu, Aug 24, 2017 at 11:37 PM, Rick Altherr <raltherr@xxxxxxxxxx> wrote:
>> On Thu, Aug 24, 2017 at 2:07 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>>> On Tue, Aug 22, 2017 at 6:10 PM, Oleksandr Shamray
>>> <oleksandrs@xxxxxxxxxxxx> wrote:
>>>
>>>> SoC which are not equipped with JTAG master interface, can be built
>>>> on top of JTAG core driver infrastructure, by applying bit-banging of
>>>> TDI, TDO, TCK and TMS pins within the hardware specific driver.
>>>
>>> I guess you mean it should then use GPIO lines for bit-banging?
>>>
>>> I was wondering about how some JTAG clients like openOCD does
>>> this in some cases.
>>
>> Many common uses of OpenOCD leverage USB devices, such as FTDI FT232R,
>> that have a command queue for bitbanging operations.  Managing these
>> via libusb is ugly but platform-agnostic.
>
> Incidentally, people are sending patches to expose the FTDI
> expanders as common GPIO chips under Linux, so we can
> internally in the kernel or from the usersapce character device
> access them as "some GPIOs".
>

I know my team at Google has an internal patch for exactly that.  FTDI
expanders are complicated as they can be used as UART, GPIO, I2C, SPI
depending on configuration.  Our project was using a mix of I2C and
GPIO so I directly my team to approach it as an MFD.  I'd like to see
all of these use cases handled by the kernel but I understand the
other viewpoint of relying on libusb for cross-platform compatiblity.

>>> In my worst nightmare they export GPIO lines using
>>> the horrid ABI in /sys/gpio/*
>>
>> https://sourceforge.net/p/openocd/code/ci/v0.10.0/tree/src/jtag/drivers/sysfsgpio.c
>
> Gnah!
> Whoever writes a slot-in replacement making the character device
> take precendence wins lots of karma.
>

If they show up at Linux Plumbers or visit San Jose, I'll take them to
dinner.  I didn't see any docs for the chardev in Documentation.  I
_think_ I understand how it works from reading the relevant sections
of gpiolib.c but I can see how users end up using sysfs instead.

>> While that is certainly horrible (and slow), mapping in the GPIO
>> registers via /dev/mem strikes me as worse:
>>
>> https://sourceforge.net/p/openocd/code/ci/v0.10.0/tree/src/jtag/drivers/bcm2835gpio.c
>
> Yeah that is quite horrible.
>
> There were reasons to do things like that, but since we have
> developed .set_multiple() to hammer several lines in a register
> at once, the same efficiency can be achieved using the standard
> character device.

Agreed that that helps with user-space GPIO-based JTAG
implementations.  The problem this patch series is trying to address
is for SoCs like the Aspeed AST2400/2500 that include a hardware
accelerated JTAG master.  It _can_ be run in a pure-software mode
where it acts like GPIOs but the intended use case is to operate an
interrupt-driven state machine.  That requires a higher-level
abstraction for managing the standard JTAG state machine.  Similar to
GPIO .set_multiple, user-space feeding a JTAG kernel API a buffer of
JTAG state changes would be useful.  That's how I recall OpenOCD's
internals working: run short (1-7?) state change sequences to move to
the next decision point.  I know of at least one vendor pushing for
the use of JTAG on BMCs as a way to debug host processors in large
deployments instead of using dongles.  I'm supportive of the adding a
JTAG driver abstraction.  I haven't reviewed this patch series in
detail yet.

>
> Yours,
> Linus Walleij