Thread (13 messages) flat view 13 messages, 5 authors, 2018-01-18

Re: [patch v15 0/4] JTAG driver introduction

From: Florian Fainelli <hidden>
Date: 2017-12-25 23:18:00
Also in: linux-api, linux-arm-kernel, linux-serial, lkml, openbmc

Le 12/25/17 à 03:53, Oleksandr Shamray a écrit :
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.
Well, the framework in its current shape is still extremely simplistic,
therefore leaving a lot of room (read: bugs, inconsistencies) within the
hands of the driver, so while the user-space interface is standard
through the proposed character device, the user experience, likely might
not.
This allow new capability to debug the CPU or program system's 
device via BMC without additional devices nor cost. 
If that is the case, should not we leverage the kernel's device driver
model and expect the JTAG framework to create specific devices for the
different pieces of HW discovered on the scan chain? That would also
presumably allow the core JTAG framework to retain the necessary state
changes in order to address one particular device within the scan chain.
This patch purpose is to add JTAG master core infrastructure by 
defining new JTAG class and provide generic JTAG interface
to allow hardware specific drivers to connect this interface.
This will enable all JTAG drivers to use the common interface
part and will have separate for hardware implementation.
Let's consider I want to get rid of OpenOCD, or rather, move its driver
interface within the kernel and replace it on the OpenOCD side with a
generic character device interface. I could presumably amortize the
costly operations which are currently I/O and/or system call limiting
when running in user-space, what would it look like with your proposed
framework, have you given some thoughts about that?

Thanks!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help