Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1717551 > unrolled thread

[patch v6 0/3] JTAG driver introduction

Back to article view | Back to linux.kernel

Contents

  [patch v6 0/3] JTAG driver introduction Oleksandr Shamray <oleksandrs@mellanox.com> - 2017-08-22 18:20 +0200
    [patch v6 1/3] drivers: jtag: Add JTAG core driver Oleksandr Shamray <oleksandrs@mellanox.com> - 2017-08-22 18:20 +0200
    Re: [patch v6 0/3] JTAG driver introduction Linus Walleij <linus.walleij@linaro.org> - 2017-08-24 23:10 +0200
      Re: [patch v6 0/3] JTAG driver introduction Rick Altherr <raltherr@google.com> - 2017-08-24 23:40 +0200
        Re: [patch v6 0/3] JTAG driver introduction Linus Walleij <linus.walleij@linaro.org> - 2017-08-25 10:40 +0200
          Re: [patch v6 0/3] JTAG driver introduction Stuart Longland <stuartl@longlandclan.id.au> - 2017-08-25 11:00 +0200
            Re: [patch v6 0/3] JTAG driver introduction Rick Altherr <raltherr@google.com> - 2017-08-25 19:00 +0200
            Re: [patch v6 0/3] JTAG driver introduction Linus Walleij <linus.walleij@linaro.org> - 2017-08-28 00:30 +0200
          Re: [patch v6 0/3] JTAG driver introduction Rick Altherr <raltherr@google.com> - 2017-08-25 19:00 +0200
            Re: [patch v6 0/3] JTAG driver introduction Linus Walleij <linus.walleij@linaro.org> - 2017-08-28 00:40 +0200
              Re: [patch v6 0/3] JTAG driver introduction Rick Altherr <raltherr@google.com> - 2017-08-28 05:00 +0200

#1717551 — [patch v6 0/3] JTAG driver introduction

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. 

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.

The JTAG (Joint Test Action Group) core driver provides minimal generic
JTAG interface, which can be used by hardware specific JTAG master
controllers. By providing common interface for the JTAG controllers,
user space device programing is hardware independent.
 
Modern SoC which in use for embedded system' equipped with
internal JTAG master interface.
This interface is used for programming and debugging system's
hardware components, like CPLD, FPGA, CPU, voltage and
industrial controllers.
Firmware for such devices can be upgraded through JTAG interface during
Runtime. The JTAG standard support for multiple devices programming,
is in case their lines are daisy-chained together.

For example, systems which equipped with host CPU, BMC SoC or/and 
number of programmable devices are capable to connect a pin and
select system components dynamically for programming and debugging,
This is using by the BMC which is equipped with internal SoC master
controller.
For example:

BMC JTAG master --> pin selected to CPLDs chain for programming (filed
upgrade, production) 
BMC JTAG master --> pin selected to voltage monitors for programming 
(field upgrade, production) 
BMC JTAG master --> pin selected to host CPU (on-site debugging 
and developers debugging)

For example, we can have application in user space which using calls
to JTAG driver executes CPLD programming directly from SVF file
 
The JTAG standard (IEEE 1149.1) defines the next connector pins:
- TDI (Test Data In);
- TDO (Test Data Out);
- TCK (Test Clock);
- TMS (Test Mode Select);
- TRST (Test Reset) (Optional);

The SoC equipped with JTAG master controller, performs
device programming on command or vector level. For example
a file in a standard SVF (Serial Vector Format) that contains
boundary scan vectors, can be used by sending each vector
to the JTAG interface and the JTAG controller will execute
the programming.

Initial version provides the system calls set for:
- SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
  number of clocks.

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.

Oleksandr Shamray (3):
  drivers: jtag: Add JTAG core driver
  drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master
    driver
  Doccumentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx
    families     JTAG master driver

 .../devicetree/bindings/jtag/aspeed-jtag.txt       |   18 +
 Documentation/ioctl/ioctl-number.txt               |    2 +
 MAINTAINERS                                        |    8 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    1 +
 drivers/jtag/Kconfig                               |   29 +
 drivers/jtag/Makefile                              |    2 +
 drivers/jtag/jtag-aspeed.c                         |  772 ++++++++++++++++++++
 drivers/jtag/jtag.c                                |  311 ++++++++
 include/linux/jtag.h                               |   48 ++
 include/uapi/linux/jtag.h                          |  113 +++
 11 files changed, 1306 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
 create mode 100644 drivers/jtag/Kconfig
 create mode 100644 drivers/jtag/Makefile
 create mode 100644 drivers/jtag/jtag-aspeed.c
 create mode 100644 drivers/jtag/jtag.c
 create mode 100644 include/linux/jtag.h
 create mode 100644 include/uapi/linux/jtag.h

[toc] | [next] | [standalone]

#1717555 — [patch v6 1/3] drivers: jtag: Add JTAG core driver

Initial patch for JTAG friver
JTAG class driver provide infrastructure to support hardware/software
JTAG platform drivers. It provide user layer API interface for flashing
and debugging external devices which equipped with JTAG interface
using standard transactions.

Driver exposes set of IOCTL to user space for:
- XFER:
- SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
  number of clocks).
- SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency.

Driver core provides set of internal APIs for allocation and
registration:
- jtag_register;
- jtag_unregister;
- jtag_alloc;
- jtag_free;

Platform driver on registration with jtag-core creates the next
entry in dev folder:
/dev/jtagX

Signed-off-by: Oleksandr Shamray <oleksandrs@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
v5->v6
v4->v5

v3->v4
Comments pointed by Arnd Bergmann <arnd@arndb.de>
- change transaction pointer tdio type  to __u64
- change internal status type from enum to __u32
- reorder jtag_xfer members to aviod the implied padding
- add __packed attribute to jtag_xfer and jtag_run_test_idle

v2->v3
Notifications from kbuild test robot <lkp@intel.com>
- Change include path to <linux/types.h> in jtag.h

v1->v2
Comments pointed by Greg KH <gregkh@linuxfoundation.org>
- Change license type from GPLv2/BSD to GPLv2
- Change type of variables which crossed user/kernel to __type
- Remove "default n" from Kconfig

Comments pointed by Andrew Lunn <andrew@lunn.ch>
- Change list_add_tail in jtag_unregister to list_del

Comments pointed by Neil Armstrong <narmstrong@baylibre.com>
- Add SPDX-License-Identifier instead of license text

Comments pointed by Arnd Bergmann <arnd@arndb.de>
- Change __copy_to_user to memdup_user
- Change __put_user to put_user
- Change type of variables to __type for compatible 32 and 64-bit systems
- Add check for maximum xfer data size
- Change lookup data mechanism to get jtag data from inode
- Add .compat_ioctl to file ops
- Add mem alignment for jtag priv data

Comments pointed by Tobias Klauser <tklauser@distanz.ch>
- Change function names to avoid match with variable types
- Fix description for jtag_ru_test_idle in uapi jtag.h
- Fix misprints IDEL/IDLE, trough/through
---
 Documentation/ioctl/ioctl-number.txt |    2 +
 MAINTAINERS                          |    8 +
 drivers/Kconfig                      |    2 +
 drivers/Makefile                     |    1 +
 drivers/jtag/Kconfig                 |   16 ++
 drivers/jtag/Makefile                |    1 +
 drivers/jtag/jtag.c                  |  311 ++++++++++++++++++++++++++++++++++
 include/linux/jtag.h                 |   48 ++++++
 include/uapi/linux/jtag.h            |  113 ++++++++++++
 9 files changed, 502 insertions(+), 0 deletions(-)
 create mode 100644 drivers/jtag/Kconfig
 create mode 100644 drivers/jtag/Makefile
 create mode 100644 drivers/jtag/jtag.c
 create mode 100644 include/linux/jtag.h
 create mode 100644 include/uapi/linux/jtag.h

diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 3e3fdae..1af2508 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -321,6 +321,8 @@ Code  Seq#(hex)	Include File		Comments
 0xB0	all	RATIO devices		in development:
 					<mailto:vgo@ratio.de>
 0xB1	00-1F	PPPoX			<mailto:mostrows@styx.uwaterloo.ca>
+0xB2	00-0f	linux/jtag.h		JTAG driver
+					<mailto:oleksandrs@mellanox.com>
 0xB3	00	linux/mmc/ioctl.h
 0xB4	00-0F	linux/gpio.h		<mailto:linux-gpio@vger.kernel.org>
 0xB5	00-0F	uapi/linux/rpmsg.h	<mailto:linux-remoteproc@vger.kernel.org>
diff --git a/MAINTAINERS b/MAINTAINERS
index 205d397..141aeaf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7292,6 +7292,14 @@ L:	linux-serial@vger.kernel.org
 S:	Maintained
 F:	drivers/tty/serial/jsm/
 
+JTAG SUBSYSTEM
+M:	Oleksandr Shamray <oleksandrs@mellanox.com>
+M:	Vadim Pasternak <vadimp@mellanox.com>
+S:	Maintained
+F:	include/linux/jtag.h
+F:	include/uapi/linux/jtag.h
+F:	drivers/jtag/
+
 K10TEMP HARDWARE MONITORING DRIVER
 M:	Clemens Ladisch <clemens@ladisch.de>
 L:	linux-hwmon@vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 505c676..2214678 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -208,4 +208,6 @@ source "drivers/tee/Kconfig"
 
 source "drivers/mux/Kconfig"
 
+source "drivers/jtag/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index dfdcda0..6a2059b 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -182,3 +182,4 @@ obj-$(CONFIG_FPGA)		+= fpga/
 obj-$(CONFIG_FSI)		+= fsi/
 obj-$(CONFIG_TEE)		+= tee/
 obj-$(CONFIG_MULTIPLEXER)	+= mux/
+obj-$(CONFIG_JTAG)		+= jtag/
diff --git a/drivers/jtag/Kconfig b/drivers/jtag/Kconfig
new file mode 100644
index 0000000..0fad1a3
--- /dev/null
+++ b/drivers/jtag/Kconfig
@@ -0,0 +1,16 @@
+menuconfig JTAG
+	tristate "JTAG support"
+	---help---
+	  This provides basic core functionality support for jtag class devices
+	  Hardware equipped with JTAG microcontroller which can be built
+	  on top of this drivers. Driver exposes the set of IOCTL to the
+	  user space for:
+	  SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
+	  SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
+	  RUNTEST (Forces IEEE 1149.1 bus to a run state for specified
+	  number of clocks).
+
+	  If you want this support, you should say Y here.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called jtag.
diff --git a/drivers/jtag/Makefile b/drivers/jtag/Makefile
new file mode 100644
index 0000000..af37493
--- /dev/null
+++ b/drivers/jtag/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_JTAG)		+= jtag.o
diff --git a/drivers/jtag/jtag.c b/drivers/jtag/jtag.c
new file mode 100644
index 0000000..97b351a
--- /dev/null
+++ b/drivers/jtag/jtag.c
@@ -0,0 +1,311 @@
+/*
+ * drivers/jtag/jtag.c
+ *
+ * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2017 Oleksandr Shamray <oleksandrs@mellanox.com>
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include <linux/cdev.h>
+#include <linux/device.h>
+#include <linux/jtag.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/rtnetlink.h>
+#include <linux/spinlock.h>
+#include <uapi/linux/jtag.h>
+
+struct jtag {
+	struct list_head list;
+	struct device *dev;
+	struct cdev cdev;
+	int id;
+	spinlock_t lock;
+	int open;
+	const struct jtag_ops *ops;
+	unsigned long priv[0] __aligned(ARCH_DMA_MINALIGN);
+};
+
+static dev_t jtag_devt;
+static LIST_HEAD(jtag_list);
+static DEFINE_MUTEX(jtag_mutex);
+static DEFINE_IDA(jtag_ida);
+
+void *jtag_priv(struct jtag *jtag)
+{
+	return jtag->priv;
+}
+EXPORT_SYMBOL_GPL(jtag_priv);
+
+static __u64 jtag_copy_from_user(__u64 udata, unsigned long bit_size)
+{
+	unsigned long size;
+	void *kdata;
+
+	size = DIV_ROUND_UP(bit_size, BITS_PER_BYTE);
+	kdata = memdup_user(u64_to_user_ptr(udata), size);
+
+	return (__u64)(uintptr_t)kdata;
+}
+
+static unsigned long jtag_copy_to_user(__u64 udata, __u64 kdata,
+				       unsigned long bit_size)
+{
+	unsigned long size;
+
+	size = DIV_ROUND_UP(bit_size, BITS_PER_BYTE);
+
+	return copy_to_user(u64_to_user_ptr(udata), jtag_u64_to_ptr(kdata),
+			    size);
+}
+
+static struct class jtag_class = {
+	.name = "jtag",
+	.owner = THIS_MODULE,
+};
+
+static int jtag_run_test_idle_op(struct jtag *jtag,
+				 struct jtag_run_test_idle *idle)
+{
+	if (jtag->ops->idle)
+		return jtag->ops->idle(jtag, idle);
+	else
+		return -EOPNOTSUPP;
+}
+
+static int jtag_xfer_op(struct jtag *jtag, struct jtag_xfer *xfer)
+{
+	if (jtag->ops->xfer)
+		return jtag->ops->xfer(jtag, xfer);
+	else
+		return -EOPNOTSUPP;
+}
+
+static long jtag_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+	struct jtag *jtag = file->private_data;
+	__u32 *uarg = (__u32 __user *)arg;
+	void  *varg = (void __user *)arg;
+	struct jtag_run_test_idle idle;
+	struct jtag_xfer xfer;
+	__u64 tdio_user;
+	__u32 value;
+	int err;
+
+	switch (cmd) {
+	case JTAG_GIOCFREQ:
+		if (jtag->ops->freq_get)
+			err = jtag->ops->freq_get(jtag, &value);
+		else
+			err = -EOPNOTSUPP;
+		if (err)
+			break;
+
+		err = put_user(value, uarg);
+		break;
+
+	case JTAG_SIOCFREQ:
+		err = __get_user(value, uarg);
+
+		if (value == 0)
+			err = -EINVAL;
+		if (err)
+			break;
+
+		if (jtag->ops->freq_set)
+			err = jtag->ops->freq_set(jtag, value);
+		else
+			err = -EOPNOTSUPP;
+		break;
+
+	case JTAG_IOCRUNTEST:
+		if (copy_from_user(&idle, varg,
+				   sizeof(struct jtag_run_test_idle)))
+			return -ENOMEM;
+		err = jtag_run_test_idle_op(jtag, &idle);
+		break;
+
+	case JTAG_IOCXFER:
+		if (copy_from_user(&xfer, varg, sizeof(struct jtag_xfer)))
+			return -EFAULT;
+
+		if (xfer.length >= JTAG_MAX_XFER_DATA_LEN)
+			return -EFAULT;
+
+		tdio_user = xfer.tdio;
+		xfer.tdio = jtag_copy_from_user(xfer.tdio, xfer.length);
+		if (!xfer.tdio)
+			return -ENOMEM;
+
+		err = jtag_xfer_op(jtag, &xfer);
+		if (jtag_copy_to_user(tdio_user, xfer.tdio, xfer.length)) {
+			kfree(jtag_u64_to_ptr(xfer.tdio));
+			return -EFAULT;
+		}
+
+		kfree(jtag_u64_to_ptr(xfer.tdio));
+		xfer.tdio = tdio_user;
+		if (copy_to_user(varg, &xfer, sizeof(struct jtag_xfer)))
+			return -EFAULT;
+		break;
+
+	case JTAG_GIOCSTATUS:
+		if (jtag->ops->status_get)
+			err = jtag->ops->status_get(jtag, &value);
+		else
+			err = -EOPNOTSUPP;
+		if (err)
+			break;
+
+		err = put_user(value, uarg);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+	return err;
+}
+
+#ifdef CONFIG_COMPAT
+static long jtag_ioctl_compat(struct file *file, unsigned int cmd,
+			      unsigned long arg)
+{
+	return jtag_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
+}
+#endif
+
+static int jtag_open(struct inode *inode, struct file *file)
+{
+	struct jtag *jtag = container_of(inode->i_cdev, struct jtag, cdev);
+
+	spin_lock(&jtag->lock);
+
+	if (jtag->open) {
+		dev_info(NULL, "jtag already opened\n");
+		spin_unlock(&jtag->lock);
+		return -EBUSY;
+	}
+
+	jtag->open++;
+	file->private_data = jtag;
+	spin_unlock(&jtag->lock);
+	return 0;
+}
+
+static int jtag_release(struct inode *inode, struct file *file)
+{
+	struct jtag *jtag = file->private_data;
+
+	spin_lock(&jtag->lock);
+	jtag->open--;
+	spin_unlock(&jtag->lock);
+	return 0;
+}
+
+static const struct file_operations jtag_fops = {
+	.owner		= THIS_MODULE,
+	.open		= jtag_open,
+	.release	= jtag_release,
+	.llseek		= noop_llseek,
+	.unlocked_ioctl = jtag_ioctl,
+#ifdef CONFIG_COMPAT
+	.compat_ioctl	= jtag_ioctl_compat,
+#endif
+};
+
+struct jtag *jtag_alloc(size_t priv_size, const struct jtag_ops *ops)
+{
+	struct jtag *jtag;
+
+	jtag = kzalloc(sizeof(*jtag) + round_up(priv_size, ARCH_DMA_MINALIGN),
+		       GFP_KERNEL);
+	if (!jtag)
+		return NULL;
+
+	jtag->ops = ops;
+	return jtag;
+}
+EXPORT_SYMBOL_GPL(jtag_alloc);
+
+void jtag_free(struct jtag *jtag)
+{
+	kfree(jtag);
+}
+EXPORT_SYMBOL_GPL(jtag_free);
+
+int jtag_register(struct jtag *jtag)
+{
+	int id;
+	int err;
+
+	id = ida_simple_get(&jtag_ida, 0, 0, GFP_KERNEL);
+	if (id < 0)
+		return id;
+
+	jtag->id = id;
+	cdev_init(&jtag->cdev, &jtag_fops);
+	jtag->cdev.owner = THIS_MODULE;
+	err = cdev_add(&jtag->cdev, MKDEV(MAJOR(jtag_devt), jtag->id), 1);
+	if (err)
+		goto err_cdev;
+
+	/* Register this jtag device with the driver core */
+	jtag->dev = device_create(&jtag_class, NULL, MKDEV(MAJOR(jtag_devt),
+							   jtag->id),
+				  NULL, "jtag%d", jtag->id);
+	if (!jtag->dev)
+		goto err_device_create;
+
+	jtag->open = 0;
+	dev_set_drvdata(jtag->dev, jtag);
+	spin_lock_init(&jtag->lock);
+	mutex_lock(&jtag_mutex);
+	list_add_tail(&jtag->list, &jtag_list);
+	mutex_unlock(&jtag_mutex);
+	return err;
+
+err_device_create:
+	cdev_del(&jtag->cdev);
+err_cdev:
+	ida_simple_remove(&jtag_ida, id);
+	return err;
+}
+EXPORT_SYMBOL_GPL(jtag_register);
+
+void jtag_unregister(struct jtag *jtag)
+{
+	struct device *dev = jtag->dev;
+
+	mutex_lock(&jtag_mutex);
+	list_del(&jtag->list);
+	mutex_unlock(&jtag_mutex);
+	cdev_del(&jtag->cdev);
+	device_unregister(dev);
+	ida_simple_remove(&jtag_ida, jtag->id);
+}
+EXPORT_SYMBOL_GPL(jtag_unregister);
+
+static int __init jtag_init(void)
+{
+	int err;
+
+	err = alloc_chrdev_region(&jtag_devt, 0, 1, "jtag");
+	if (err)
+		return err;
+	return class_register(&jtag_class);
+}
+
+static void __exit jtag_exit(void)
+{
+	class_unregister(&jtag_class);
+}
+
+module_init(jtag_init);
+module_exit(jtag_exit);
+
+MODULE_AUTHOR("Oleksandr Shamray <oleksandrs@mellanox.com>");
+MODULE_DESCRIPTION("Generic jtag support");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/jtag.h b/include/linux/jtag.h
new file mode 100644
index 0000000..f48ae9d
--- /dev/null
+++ b/include/linux/jtag.h
@@ -0,0 +1,48 @@
+/*
+ * drivers/jtag/jtag.c
+ *
+ * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2017 Oleksandr Shamray <oleksandrs@mellanox.com>
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#ifndef __JTAG_H
+#define __JTAG_H
+
+#include <uapi/linux/jtag.h>
+
+#ifndef ARCH_DMA_MINALIGN
+#define ARCH_DMA_MINALIGN 1
+#endif
+
+#define jtag_u64_to_ptr(arg) ((void *)(uintptr_t)arg)
+
+#define JTAG_MAX_XFER_DATA_LEN 65535
+
+struct jtag;
+/**
+ * struct jtag_ops - callbacks for jtag control functions:
+ *
+ * @freq_get: get frequency function. Filled by device driver
+ * @freq_set: set frequency function. Filled by device driver
+ * @status_get: set status function. Filled by device driver
+ * @idle: set JTAG to idle state function. Filled by device driver
+ * @xfer: send JTAG xfer function. Filled by device driver
+ */
+struct jtag_ops {
+	int (*freq_get)(struct jtag *jtag, __u32 *freq);
+	int (*freq_set)(struct jtag *jtag, __u32 freq);
+	int (*status_get)(struct jtag *jtag, __u32 *state);
+	int (*idle)(struct jtag *jtag, struct jtag_run_test_idle *idle);
+	int (*xfer)(struct jtag *jtag, struct jtag_xfer *xfer);
+};
+
+void *jtag_priv(struct jtag *jtag);
+int jtag_register(struct jtag *jtag);
+void jtag_unregister(struct jtag *jtag);
+struct jtag *jtag_alloc(size_t priv_size, const struct jtag_ops *ops);
+void jtag_free(struct jtag *jtag);
+
+#endif /* __JTAG_H */
diff --git a/include/uapi/linux/jtag.h b/include/uapi/linux/jtag.h
new file mode 100644
index 0000000..78309c3
--- /dev/null
+++ b/include/uapi/linux/jtag.h
@@ -0,0 +1,113 @@
+/*
+ * JTAG class driver
+ *
+ * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2017 Oleksandr Shamray <oleksandrs@mellanox.com>
+ *
+ * Released under the GPLv2/BSD.
+ * SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+ */
+
+#ifndef __UAPI_LINUX_JTAG_H
+#define __UAPI_LINUX_JTAG_H
+
+#include <asm/types.h>
+
+/**
+ * enum jtag_xfer_mode:
+ *
+ * @JTAG_XFER_HW_MODE: hardware mode transfer
+ * @JTAG_XFER_SW_MODE: software mode transfer
+ */
+enum jtag_xfer_mode {
+	JTAG_XFER_HW_MODE,
+	JTAG_XFER_SW_MODE,
+};
+
+/**
+ * enum jtag_endstate:
+ *
+ * @JTAG_STATE_IDLE: JTAG state machine IDLE state
+ * @JTAG_STATE_PAUSEIR: JTAG state machine PAUSE_IR state
+ * @JTAG_STATE_PAUSEDR: JTAG state machine PAUSE_DR state
+ */
+enum jtag_endstate {
+	JTAG_STATE_IDLE,
+	JTAG_STATE_PAUSEIR,
+	JTAG_STATE_PAUSEDR,
+};
+
+/**
+ * enum jtag_xfer_type:
+ *
+ * @JTAG_SIR_XFER: SIR transfer
+ * @JTAG_SDR_XFER: SDR transfer
+ */
+enum jtag_xfer_type {
+	JTAG_SIR_XFER,
+	JTAG_SDR_XFER,
+};
+
+/**
+ * enum jtag_xfer_direction:
+ *
+ * @JTAG_READ_XFER: read transfer
+ * @JTAG_WRITE_XFER: write transfer
+ */
+enum jtag_xfer_direction {
+	JTAG_READ_XFER,
+	JTAG_WRITE_XFER,
+};
+
+/**
+ * struct jtag_run_test_idle - forces JTAG state machine to
+ * RUN_TEST/IDLE state
+ *
+ * @mode: access mode
+ * @reset: 0 - run IDLE/PAUSE from current state
+ *         1 - go through TEST_LOGIC/RESET state before  IDLE/PAUSE
+ * @end: completion flag
+ * @tck: clock counter
+ *
+ * Structure represents interface to JTAG device for jtag idle
+ * execution.
+ */
+struct jtag_run_test_idle {
+	__u8	mode;
+	__u8	reset;
+	__u8	endstate;
+	__u8	tck;
+};
+
+/**
+ * struct jtag_xfer - jtag xfer:
+ *
+ * @mode: access mode
+ * @type: transfer type
+ * @direction: xfer direction
+ * @length: xfer bits len
+ * @tdio : xfer data array
+ * @endir: xfer end state
+ *
+ * Structure represents interface to Aspeed JTAG device for jtag sdr xfer
+ * execution.
+ */
+struct jtag_xfer {
+	__u8	mode;
+	__u8	type;
+	__u8	direction;
+	__u8	endstate;
+	__u32	length;
+	__u64	tdio;
+};
+
+#define __JTAG_IOCTL_MAGIC	0xb2
+
+#define JTAG_IOCRUNTEST	_IOW(__JTAG_IOCTL_MAGIC, 0,\
+			     struct jtag_run_test_idle)
+#define JTAG_SIOCFREQ	_IOW(__JTAG_IOCTL_MAGIC, 1, unsigned int)
+#define JTAG_GIOCFREQ	_IOR(__JTAG_IOCTL_MAGIC, 2, unsigned int)
+#define JTAG_IOCXFER	_IOWR(__JTAG_IOCTL_MAGIC, 3, struct jtag_xfer)
+#define JTAG_GIOCSTATUS _IOWR(__JTAG_IOCTL_MAGIC, 4, enum jtag_endstate)
+
+#endif /* __UAPI_LINUX_JTAG_H */
-- 
1.7.1

[toc] | [prev] | [next] | [standalone]

#1719569

On Tue, Aug 22, 2017 at 6:10 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> 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.

In my worst nightmare they export GPIO lines using
the horrid ABI in /sys/gpio/*

In best case they use the GPIO character device or even
libgpiod.

But having a JTAG abstraction inside the kernel that can
grab a few lines for JTAG defined in a device tree, ACPI DSDT
or similar makes sense too, as it abstracts the hardware so the
JTAG client can then just open whatever /dev/jtag0 is on the machine
and go ahead without having to bother about what GPIO lines
are connected exactly where.

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1719600

On Thu, Aug 24, 2017 at 2:07 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Aug 22, 2017 at 6:10 PM, Oleksandr Shamray
> <oleksandrs@mellanox.com> 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.

> 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

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

> In best case they use the GPIO character device or even
> libgpiod.
>
> But having a JTAG abstraction inside the kernel that can
> grab a few lines for JTAG defined in a device tree, ACPI DSDT
> or similar makes sense too, as it abstracts the hardware so the
> JTAG client can then just open whatever /dev/jtag0 is on the machine
> and go ahead without having to bother about what GPIO lines
> are connected exactly where.
>
> Yours,
> Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1719830

On Thu, Aug 24, 2017 at 11:37 PM, Rick Altherr <raltherr@google.com> wrote:
> On Thu, Aug 24, 2017 at 2:07 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Tue, Aug 22, 2017 at 6:10 PM, Oleksandr Shamray
>> <oleksandrs@mellanox.com> 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".

>> 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.

> 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.

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1719840

[Multipart message — attachments visible in raw view] — view raw

[Note: dropping vadimp@maellanox.com as SMTP server complained about the
DNS server returning NXDOMAIN.  Apologies.]
On 25/08/17 18:32, Linus Walleij wrote:
> Gnah!
> Whoever writes a slot-in replacement making the character device
> take precendence wins lots of karma.

What would such a replacement look like though?

Some sort of system whereby you can read/write single-line commands as
if talking to a GPIO expander over a UART?

Would you access the GPIOs one by one, or would you perhaps map them
into a bitmap (maybe arbitrarily, up to 64-bits wide) and perform masked
operations on the bitmap?

I'm no fan of the sysfs GPIO interface, but it beats poking around at
registers behind the kernel's back.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

[toc] | [prev] | [next] | [standalone]

#1720280

On Fri, Aug 25, 2017 at 1:50 AM, Stuart Longland
<stuartl@longlandclan.id.au> wrote:
> [Note: dropping vadimp@maellanox.com as SMTP server complained about the
> DNS server returning NXDOMAIN.  Apologies.]
> On 25/08/17 18:32, Linus Walleij wrote:
>> Gnah!
>> Whoever writes a slot-in replacement making the character device
>> take precendence wins lots of karma.
>
> What would such a replacement look like though?

See Linus's comments about using the existing kernel GPIO chardev
interface.  It already supports requesting multiple GPIO line state
changes in a single request.

>
> Some sort of system whereby you can read/write single-line commands as
> if talking to a GPIO expander over a UART?
>
> Would you access the GPIOs one by one, or would you perhaps map them
> into a bitmap (maybe arbitrarily, up to 64-bits wide) and perform masked
> operations on the bitmap?
>
> I'm no fan of the sysfs GPIO interface, but it beats poking around at
> registers behind the kernel's back.
> --
> Stuart Longland (aka Redhatter, VK4MSL)
>
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
>

[toc] | [prev] | [next] | [standalone]

#1720937

On Fri, Aug 25, 2017 at 10:50 AM, Stuart Longland
<stuartl@longlandclan.id.au> wrote:
> [Note: dropping vadimp@maellanox.com as SMTP server complained about the
> DNS server returning NXDOMAIN.  Apologies.]
> On 25/08/17 18:32, Linus Walleij wrote:
>> Gnah!
>> Whoever writes a slot-in replacement making the character device
>> take precendence wins lots of karma.
>
> What would such a replacement look like though?

Something that looks for /dev/gpiochipN and if it exists open the GPIOs
from there and make that take precedence over any /sys/gpio/*
poking.

> Some sort of system whereby you can read/write single-line commands as
> if talking to a GPIO expander over a UART?

I don't really understand the question. All GPIO expanders become
a gpiochip, and have their own character device in /dev.

> Would you access the GPIOs one by one, or would you perhaps map them
> into a bitmap (maybe arbitrarily, up to 64-bits wide) and perform masked
> operations on the bitmap?

The character device supports up to 64bits of simultaneous line
switches, but the in-kernel API can only handle 32bits
in a single register write.

> I'm no fan of the sysfs GPIO interface, but it beats poking around at
> registers behind the kernel's back.

Have a look at libgpiod and tools/gpio/* in the kernel.

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1720278

On Fri, Aug 25, 2017 at 1:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Aug 24, 2017 at 11:37 PM, Rick Altherr <raltherr@google.com> wrote:
>> On Thu, Aug 24, 2017 at 2:07 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> On Tue, Aug 22, 2017 at 6:10 PM, Oleksandr Shamray
>>> <oleksandrs@mellanox.com> 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

[toc] | [prev] | [next] | [standalone]

#1720938

On Fri, Aug 25, 2017 at 6:52 PM, Rick Altherr <raltherr@google.com> wrote:

>> 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.

Hm. I see. But I see people pushing the in-kernel method so I think
it will eventually win out.

>>>> 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.

I intended tools/gpio/* to be the documentation:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/gpio

If we need more written documentation we can do it I guess,

Yours,
Linus Walleij

[toc] | [prev] | [next] | [standalone]

#1720979

On Sun, Aug 27, 2017 at 3:30 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Aug 25, 2017 at 6:52 PM, Rick Altherr <raltherr@google.com> wrote:
>
>>> 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.
>
> Hm. I see. But I see people pushing the in-kernel method so I think
> it will eventually win out.
>

SGTM.  I'll see if my team can clean up the MFD-based FTDI driver and
submit it upstream.

>>>>> 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.
>
> I intended tools/gpio/* to be the documentation:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/gpio
>
> If we need more written documentation we can do it I guess,

I haven't been in the habit of looking in tools/.  Guess I should be.

>
> Yours,
> Linus Walleij

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web