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