Received: by 10.223.176.5 with SMTP id f5csp2940522wra; Mon, 29 Jan 2018 06:32:57 -0800 (PST) X-Google-Smtp-Source: AH8x227sV5uZTi1uVTjyVlHGCo/fAEyqSPB4pYmJ6xhhTU6Fp9B+1712tv+vd/opwrjfYNCOnXhT X-Received: by 2002:a17:902:f83:: with SMTP id 3-v6mr9180746plz.275.1517236377680; Mon, 29 Jan 2018 06:32:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517236377; cv=none; d=google.com; s=arc-20160816; b=NTgeF+SLxuxn29BAFHpVHYMpGKyKQI47ZZAuE/l2RtsQhh8BfC9s/goXwhg1tVM7mU +fLVX9+Cupun7fg/0NLtKnt8f0BwdZ7YuEA7nVJIYcEdrbNwD7eXCXrzjc1p9JAOHDi6 4+T8B1IZjFIHrMMo7f1wTiXtKfN/ZoZ3jjsfPRr6KVJEn6rmT9Y/7pEtzZ0wV1vGRUx6 JmyhlalE0upxYGWrFvVOzD1xNnZ0rHEOtbj42hvaXoaUJVTzn2RQyUj/x33Id6Od+MHr 6vBwQ9UCaJNtQ3oQcE0YOO3QpX3PV0I8U3fHg0pUcnWKxcAis1o9ljasrn7upORScFQ5 plEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=mccJzDeCh85YRDn0esZQc/g3nHyMPWCpkLLl7P1dl28=; b=uy1SWb4kVNlDGLlXEwjg2EjymPyUBFuHJDbBJU+Pa/kPomLGGfP3VhWcGh1qc0MXHn PR7yhi7+DFD1+zI+QpB+y7ybAJ1LA/X2dXv0sNx8Ghka9kTT4FSrWAKns1g60iMBJ+qR NBKwGGeg5685KBoGwzHMECf/3SrTB68X7rO5IAZ53aE/ZuQ3T66qQvPKKGPU7J+ULt3z 2qzP5meDNMNShKsuj/rIttWQQcKPSwYsNsnfzCFMod9v1/NTyHwCPPCWn1XMdV+xft98 r2MRz+RueTBRNLlX6qIFwIUKRowXzmuwLtos3M9x2EgYjhGQDvsBH677BAFQzCFkbvCk y9mQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mellanox.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z190si7526528pgb.808.2018.01.29.06.32.43; Mon, 29 Jan 2018 06:32:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mellanox.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752054AbeA2Ob4 (ORCPT + 99 others); Mon, 29 Jan 2018 09:31:56 -0500 Received: from mail-il-dmz.mellanox.com ([193.47.165.129]:38396 "EHLO mellanox.co.il" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751740AbeA2Obv (ORCPT ); Mon, 29 Jan 2018 09:31:51 -0500 Received: from Internal Mail-Server by MTLPINE1 (envelope-from oleksandrs@mellanox.com) with ESMTPS (AES256-SHA encrypted); 29 Jan 2018 16:31:46 +0200 Received: from r-vnc16.mtr.labs.mlnx (r-vnc16.mtr.labs.mlnx [10.208.0.16]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id w0TEVk3u006123; Mon, 29 Jan 2018 16:31:46 +0200 From: Oleksandr Shamray To: gregkh@linuxfoundation.org, arnd@arndb.de Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, openbmc@lists.ozlabs.org, joel@jms.id.au, jiri@resnulli.us, tklauser@distanz.ch, linux-serial@vger.kernel.org, vadimp@mellanox.com, system-sw-low-level@mellanox.com, robh+dt@kernel.org, openocd-devel-owner@lists.sourceforge.net, linux-api@vger.kernel.org, davem@davemloft.net, mchehab@kernel.org, Oleksandr Shamray Subject: [patch v18 0/4] JTAG driver introduction Date: Mon, 29 Jan 2018 16:31:41 +0200 Message-Id: <1517236305-4880-1-git-send-email-oleksandrs@mellanox.com> X-Mailer: git-send-email 1.7.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 (4): drivers: jtag: Add JTAG core driver drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver Documentation: jtag: Add ABI documentation Documentation/ABI/testing/jtag-dev | 27 + .../devicetree/bindings/jtag/aspeed-jtag.txt | 22 + Documentation/ioctl/ioctl-number.txt | 2 + MAINTAINERS | 10 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/jtag/Kconfig | 30 + drivers/jtag/Makefile | 2 + drivers/jtag/jtag-aspeed.c | 786 ++++++++++++++++++++ drivers/jtag/jtag.c | 273 +++++++ include/linux/jtag.h | 41 + include/uapi/linux/jtag.h | 105 +++ 12 files changed, 1301 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/jtag-dev 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