[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ff739c26-d3b2-3df7-e751-fbf037ae96d1@gmail.com>
Date: Tue, 30 Jan 2018 19:03:29 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Oleksandr Shamray <oleksandrs@...lanox.com>,
gregkh@...uxfoundation.org, arnd@...db.de
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, openbmc@...ts.ozlabs.org,
joel@....id.au, jiri@...nulli.us, tklauser@...tanz.ch,
linux-serial@...r.kernel.org, vadimp@...lanox.com,
system-sw-low-level@...lanox.com, robh+dt@...nel.org,
openocd-devel-owner@...ts.sourceforge.net,
linux-api@...r.kernel.org, davem@...emloft.net, mchehab@...nel.org
Subject: Re: [patch v18 0/4] JTAG driver introduction
On 01/29/2018 06:31 AM, Oleksandr Shamray wrote:
> When a need raise up to use JTAG interface for system's devices
> programming or CPU debugging, usually the user layer
> application implements jtag protocol by bit-bang or using a
> proprietary connection to vendor hardware.
> This method can be slow and not generic.
>
> We propose to implement general JTAG interface and infrastructure
> to communicate with user layer application. In such way, we can
> have the standard JTAG interface core part and separation from
> specific HW implementation.
> This allow new capability to debug the CPU or program system's
> device via BMC without additional devices nor cost.
Oleksandr, you have completed dodged my questions here:
https://lkml.org/lkml/2017/12/25/163
can you try to respond to some of these questions please?
--
Florian
Powered by blists - more mailing lists