mirror of
https://github.com/torvalds/linux.git
synced 2024-09-20 23:13:00 +00:00
7828b7bbbf
This is a sloppy logic analyzer using GPIOs. It comes with a script to isolate a CPU for polling. While this is definitely not a production level analyzer, it can be a helpful first view when remote debugging. Read the documentation for details. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240620094159.6785-2-wsa+renesas@sang-engineering.com [Bartosz: moved the Kconfig entry into a different category] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
94 lines
4.1 KiB
ReStructuredText
94 lines
4.1 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
=============================================
|
|
Linux Kernel GPIO based sloppy logic analyzer
|
|
=============================================
|
|
|
|
:Author: Wolfram Sang
|
|
|
|
Introduction
|
|
============
|
|
|
|
This document briefly describes how to run the GPIO based in-kernel sloppy
|
|
logic analyzer running on an isolated CPU.
|
|
|
|
The sloppy logic analyzer will utilize a few GPIO lines in input mode on a
|
|
system to rapidly sample these digital lines, which will, if the Nyquist
|
|
criteria is met, result in a time series log with approximate waveforms as they
|
|
appeared on these lines. One way to use it is to analyze external traffic
|
|
connected to these GPIO lines with wires (i.e. digital probes), acting as a
|
|
common logic analyzer.
|
|
|
|
Another feature is to snoop on on-chip peripherals if the I/O cells of these
|
|
peripherals can be used in GPIO input mode at the same time as they are being
|
|
used as inputs or outputs for the peripheral. That means you could e.g. snoop
|
|
I2C traffic without any wiring (if your hardware supports it). In the pin
|
|
control subsystem such pin controllers are called "non-strict": a certain pin
|
|
can be used with a certain peripheral and as a GPIO input line at the same
|
|
time.
|
|
|
|
Note that this is a last resort analyzer which can be affected by latencies,
|
|
non-deterministic code paths and non-maskable interrupts. It is called 'sloppy'
|
|
for a reason. However, for e.g. remote development, it may be useful to get a
|
|
first view and aid further debugging.
|
|
|
|
Setup
|
|
=====
|
|
|
|
Your kernel must have CONFIG_DEBUG_FS and CONFIG_CPUSETS enabled. Ideally, your
|
|
runtime environment does not utilize cpusets otherwise, then isolation of a CPU
|
|
core is easiest. If you do need cpusets, check that helper script for the
|
|
sloppy logic analyzer does not interfere with your other settings.
|
|
|
|
Tell the kernel which GPIOs are used as probes. For a Device Tree based system,
|
|
you need to use the following bindings. Because these bindings are only for
|
|
debugging, there is no official schema::
|
|
|
|
i2c-analyzer {
|
|
compatible = "gpio-sloppy-logic-analyzer";
|
|
probe-gpios = <&gpio6 21 GPIO_OPEN_DRAIN>, <&gpio6 4 GPIO_OPEN_DRAIN>;
|
|
probe-names = "SCL", "SDA";
|
|
};
|
|
|
|
Note that you must provide a name for every GPIO specified. Currently a
|
|
maximum of 8 probes are supported. 32 are likely possible but are not
|
|
implemented yet.
|
|
|
|
Usage
|
|
=====
|
|
|
|
The logic analyzer is configurable via files in debugfs. However, it is
|
|
strongly recommended to not use them directly, but to use the script
|
|
``tools/gpio/gpio-sloppy-logic-analyzer``. Besides checking parameters more
|
|
extensively, it will isolate the CPU core so you will have the least
|
|
disturbance while measuring.
|
|
|
|
The script has a help option explaining the parameters. For the above DT
|
|
snippet which analyzes an I2C bus at 400kHz on a Renesas Salvator-XS board, the
|
|
following settings are used: The isolated CPU shall be CPU1 because it is a big
|
|
core in a big.LITTLE setup. Because CPU1 is the default, we don't need a
|
|
parameter. The bus speed is 400kHz. So, the sampling theorem says we need to
|
|
sample at least at 800kHz. However, falling edges of both signals in an I2C
|
|
start condition happen faster, so we need a higher sampling frequency, e.g.
|
|
``-s 1500000`` for 1.5MHz. Also, we don't want to sample right away but wait
|
|
for a start condition on an idle bus. So, we need to set a trigger to a falling
|
|
edge on SDA while SCL stays high, i.e. ``-t 1H+2F``. Last is the duration, let
|
|
us assume 15ms here which results in the parameter ``-d 15000``. So,
|
|
altogether::
|
|
|
|
gpio-sloppy-logic-analyzer -s 1500000 -t 1H+2F -d 15000
|
|
|
|
Note that the process will return you back to the prompt but a sub-process is
|
|
still sampling in the background. Unless this has finished, you will not find a
|
|
result file in the current or specified directory. For the above example, we
|
|
will then need to trigger I2C communication::
|
|
|
|
i2cdetect -y -r <your bus number>
|
|
|
|
Result is a .sr file to be consumed with PulseView or sigrok-cli from the free
|
|
`sigrok`_ project. It is a zip file which also contains the binary sample data
|
|
which may be consumed by other software. The filename is the logic analyzer
|
|
instance name plus a since-epoch timestamp.
|
|
|
|
.. _sigrok: https://sigrok.org/
|