Linux Kernel GPIO based sloppy logic analyzer | Linux 6.18.37

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약과 해설

gpio-sloppy-logic-analyzer.rst:1-93

GPIO sloppy logic analyzer는 별도 측정 장비가 없거나 원격 환경인 경우 GPIO line을 빠르게 읽어 대략적인 waveform을 얻는 커널 debugging 수단입니다. non-strict pin controller에서는 실제 peripheral 동작과 동시에 같은 pin을 GPIO input으로 관찰할 수도 있습니다.

정확한 logic analyzer를 대체하지는 않으며 scheduler latency와 interrupt의 영향을 받습니다. helper script로 CPU를 격리하고 대상 bus보다 충분히 높은 sampling frequency와 명확한 trigger를 설정한 뒤, 생성된 `.sr` 파일을 PulseView나 sigrok-cli로 검토해야 합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기

1 .. SPDX-License-Identifier: GPL-2.0

3 =============================================

4 Linux Kernel GPIO based sloppy logic analyzer

5 =============================================

7 :Author: Wolfram Sang

9 Introduction

10 ============

12 This document briefly describes how to run the GPIO based in-kernel sloppy

13 logic analyzer running on an isolated CPU.

15 The sloppy logic analyzer will utilize a few GPIO lines in input mode on a

16 system to rapidly sample these digital lines, which will, if the Nyquist

17 criteria is met, result in a time series log with approximate waveforms as they

18 appeared on these lines. One way to use it is to analyze external traffic

19 connected to these GPIO lines with wires (i.e. digital probes), acting as a

20 common logic analyzer.

22 Another feature is to snoop on on-chip peripherals if the I/O cells of these

23 peripherals can be used in GPIO input mode at the same time as they are being

24 used as inputs or outputs for the peripheral. That means you could e.g. snoop

25 I2C traffic without any wiring (if your hardware supports it). In the pin

26 control subsystem such pin controllers are called "non-strict": a certain pin

27 can be used with a certain peripheral and as a GPIO input line at the same

28 time.

30 Note that this is a last resort analyzer which can be affected by latencies,

31 non-deterministic code paths and non-maskable interrupts. It is called 'sloppy'

32 for a reason. However, for e.g. remote development, it may be useful to get a

33 first view and aid further debugging.

35 Setup

36 =====

38 Your kernel must have CONFIG_DEBUG_FS and CONFIG_CPUSETS enabled. Ideally, your

39 runtime environment does not utilize cpusets otherwise, then isolation of a CPU

40 core is easiest. If you do need cpusets, check that helper script for the

41 sloppy logic analyzer does not interfere with your other settings.

43 Tell the kernel which GPIOs are used as probes. For a Device Tree based system,

44 you need to use the following bindings. Because these bindings are only for

45 debugging, there is no official schema::

47 i2c-analyzer {

48 compatible = "gpio-sloppy-logic-analyzer";

49 probe-gpios = <&gpio6 21 GPIO_OPEN_DRAIN>, <&gpio6 4 GPIO_OPEN_DRAIN>;

50 probe-names = "SCL", "SDA";

51 };

53 Note that you must provide a name for every GPIO specified. Currently a

54 maximum of 8 probes are supported. 32 are likely possible but are not

55 implemented yet.

57 Usage

58 =====

60 The logic analyzer is configurable via files in debugfs. However, it is

61 strongly recommended to not use them directly, but to use the script

62 ``tools/gpio/gpio-sloppy-logic-analyzer``. Besides checking parameters more

63 extensively, it will isolate the CPU core so you will have the least

64 disturbance while measuring.

66 The script has a help option explaining the parameters. For the above DT

67 snippet which analyzes an I2C bus at 400kHz on a Renesas Salvator-XS board, the

68 following settings are used: The isolated CPU shall be CPU1 because it is a big

69 core in a big.LITTLE setup. Because CPU1 is the default, we don't need a

70 parameter. The bus speed is 400kHz. So, the sampling theorem says we need to

71 sample at least at 800kHz. However, falling edges of both signals in an I2C

72 start condition happen faster, so we need a higher sampling frequency, e.g.

73 ``-s 1500000`` for 1.5MHz. Also, we don't want to sample right away but wait

74 for a start condition on an idle bus. So, we need to set a trigger to a falling

75 edge on SDA while SCL stays high, i.e. ``-t 1H+2F``. Last is the duration, let

76 us assume 15ms here which results in the parameter ``-d 15000``. So,

77 altogether::

79 gpio-sloppy-logic-analyzer -s 1500000 -t 1H+2F -d 15000

81 Note that the process will return you back to the prompt but a sub-process is

82 still sampling in the background. Unless this has finished, you will not find a

83 result file in the current or specified directory. For the above example, we

84 will then need to trigger I2C communication::

86 i2cdetect -y -r <your bus number>

88 Result is a .sr file to be consumed with PulseView or sigrok-cli from the free

89 `sigrok`_ project. It is a zip file which also contains the binary sample data

90 which may be consumed by other software. The filename is the logic analyzer

91 instance name plus a since-epoch timestamp.

93 .. _sigrok: https://sigrok.org/

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

GPIO 기반 sloppy logic analyzer 소개

1-34

SPDX 라이선스 식별자: GPL-2.0

Linux 커널 GPIO 기반 sloppy logic analyzer

저자: Wolfram Sang

소개

이 문서는 격리된 CPU에서 실행되는 GPIO 기반 in-kernel sloppy logic analyzer를 실행하는 방법을 간략히 설명합니다.

sloppy logic analyzer는 시스템의 몇 개 GPIO line을 input mode로 사용해 이 digital line들을 빠르게 sample합니다. Nyquist 기준을 충족하면 line에 나타난 대략적인 waveform의 time series log를 얻습니다. 사용 방법 중 하나는 wire, 즉 digital probe로 GPIO line에 연결된 외부 traffic을 분석해 일반적인 logic analyzer처럼 쓰는 것입니다.

또 다른 기능은 peripheral의 I/O cell을 peripheral input 또는 output으로 사용하는 동시에 GPIO input mode로도 사용할 수 있는 경우 on-chip peripheral을 관찰하는 것입니다. 즉 hardware가 지원한다면 배선 없이 I2C traffic을 관찰할 수 있습니다. pin control subsystem에서는 이런 pin controller를 `non-strict`라고 부릅니다. 특정 pin을 특정 peripheral과 GPIO input line으로 동시에 사용할 수 있다는 뜻입니다.

이 도구는 latency, 비결정적 code path, non-maskable interrupt의 영향을 받을 수 있는 최후 수단의 analyzer입니다. 'sloppy'라는 이름에는 이유가 있습니다. 그래도 remote development 같은 환경에서는 첫 관측 결과를 얻어 후속 debugging을 돕는 데 유용할 수 있습니다.

커널과 GPIO probe 설정

35-56

설정

커널에 CONFIG_DEBUG_FS와 CONFIG_CPUSETS가 활성화되어 있어야 합니다. 이상적으로는 runtime environment가 cpuset을 다른 용도로 사용하지 않아야 CPU core를 가장 쉽게 격리할 수 있습니다. cpuset이 필요하다면 sloppy logic analyzer의 helper script가 다른 설정과 충돌하지 않는지 확인하십시오.

probe로 사용할 GPIO를 커널에 지정하십시오. Device Tree 기반 시스템에서는 다음 binding을 사용해야 합니다. 이 binding은 debugging 전용이므로 공식 schema는 없습니다.

i2c-analyzer {
        compatible = "gpio-sloppy-logic-analyzer";
        probe-gpios = <&gpio6 21 GPIO_OPEN_DRAIN>, <&gpio6 4 GPIO_OPEN_DRAIN>;
        probe-names = "SCL", "SDA";
};

지정한 모든 GPIO에 이름을 제공해야 합니다. 현재 최대 8개 probe를 지원합니다. 32개도 가능할 것으로 보이지만 아직 구현되지 않았습니다.

sampling과 trigger 사용법

57-93

사용법

logic analyzer는 debugfs의 파일을 통해 구성할 수 있습니다. 그러나 이 파일들을 직접 사용하지 말고 `tools/gpio/gpio-sloppy-logic-analyzer` 스크립트를 사용하는 것을 강력히 권장합니다. 이 스크립트는 parameter를 더 철저히 검사할 뿐 아니라 측정 중 방해를 최소화하도록 CPU core를 격리합니다.

스크립트에는 parameter를 설명하는 help 옵션이 있습니다. 위 DT 조각을 이용해 Renesas Salvator-XS board의 400kHz I2C bus를 분석한다면 다음 설정을 사용합니다. big.LITTLE 구성에서 big core인 CPU1을 격리하며, CPU1이 기본값이므로 별도 parameter는 필요하지 않습니다.

bus 속도는 400kHz입니다. sampling 정리에 따르면 최소 800kHz로 sample해야 합니다. 하지만 I2C start condition에서는 두 signal의 falling edge가 더 빠르게 발생하므로 더 높은 sampling frequency가 필요합니다. 예를 들어 1.5MHz를 뜻하는 `-s 1500000`을 사용합니다.

즉시 sample하지 않고 idle bus의 start condition을 기다리려면 SCL이 high를 유지하는 동안 SDA가 falling edge가 되는 trigger, 즉 `-t 1H+2F`를 설정해야 합니다. 마지막으로 duration을 15ms로 가정하면 `-d 15000`을 사용합니다. 전체 명령은 다음과 같습니다.

gpio-sloppy-logic-analyzer -s 1500000 -t 1H+2F -d 15000

process가 prompt를 돌려주더라도 sub-process는 background에서 계속 sampling합니다. sampling이 끝나기 전에는 현재 directory나 지정한 directory에서 result file을 찾을 수 없습니다. 위 예에서는 다음 명령으로 I2C communication을 발생시켜야 합니다.

i2cdetect -y -r <your bus number>

결과는 free `sigrok`_ project의 PulseView 또는 sigrok-cli가 읽을 수 있는 `.sr` 파일입니다. binary sample data도 들어 있는 zip 파일이므로 다른 software에서도 사용할 수 있습니다. 파일 이름은 logic analyzer instance 이름과 epoch 이후 timestamp를 조합합니다.

sigrok: https://sigrok.org/