요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
===========================================================================
Using physical DMA provided by OHCI-1394 FireWire controllers for debugging
===========================================================================
Introduction
------------
Basically all FireWire controllers which are in use today are compliant
to the OHCI-1394 specification which defines the controller to be a PCI
bus master which uses DMA to offload data transfers from the CPU and has
a "Physical Response Unit" which executes specific requests by employing
PCI-Bus master DMA after applying filters defined by the OHCI-1394 driver.
Once properly configured, remote machines can send these requests to
ask the OHCI-1394 controller to perform read and write requests on
physical system memory and, for read requests, send the result of
the physical memory read back to the requester.
With that, it is possible to debug issues by reading interesting memory
locations such as buffers like the printk buffer or the process table.
Retrieving a full system memory dump is also possible over the FireWire,
using data transfer rates in the order of 10MB/s or more.
With most FireWire controllers, memory access is limited to the low 4 GB
of physical address space. This can be a problem on machines where memory is
located mostly above that limit, but it is rarely a problem on more common
hardware such as x86, x86-64 and PowerPC.
At least LSI FW643e and FW643e2 controllers are known to support access to
physical addresses above 4 GB, but this feature is currently not enabled by
Linux.
Together with a early initialization of the OHCI-1394 controller for debugging,
this facility proved most useful for examining long debugs logs in the printk
buffer on to debug early boot problems in areas like ACPI where the system
fails to boot and other means for debugging (serial port) are either not
available (notebooks) or too slow for extensive debug information (like ACPI).
Drivers
-------
The firewire-ohci driver in drivers/firewire uses filtered physical
DMA by default, which is more secure but not suitable for remote debugging.
Pass the remote_dma=1 parameter to the driver to get unfiltered physical DMA.
Because the firewire-ohci driver depends on the PCI enumeration to be
completed, an initialization routine which runs pretty early has been
implemented for x86. This routine runs long before console_init() can be
called, i.e. before the printk buffer appears on the console.
To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
Remote debugging over FireWire early on boot) and pass the parameter
"ohci1394_dma=early" to the recompiled kernel on boot.
Tools
-----
firescope - Originally developed by Benjamin Herrenschmidt, Andi Kleen ported
it from PowerPC to x86 and x86_64 and added functionality, firescope can now
be used to view the printk buffer of a remote machine, even with live update.
Bernhard Kaindl enhanced firescope to support accessing 64-bit machines
from 32-bit firescope and vice versa:
- http://v3.sk/~lkundrak/firescope/
and he implemented fast system dump (alpha version - read README.txt):
- http://halobates.de/firewire/firedump-0.1.tar.bz2
There is also a gdb proxy for firewire which allows to use gdb to access
data which can be referenced from symbols found by gdb in vmlinux:
- http://halobates.de/firewire/fireproxy-0.33.tar.bz2
The latest version of this gdb proxy (fireproxy-0.34) can communicate (not
yet stable) with kgdb over an memory-based communication module (kgdbom).
Getting Started
---------------
The OHCI-1394 specification regulates that the OHCI-1394 controller must
disable all physical DMA on each bus reset.
This means that if you want to debug an issue in a system state where
interrupts are disabled and where no polling of the OHCI-1394 controller
for bus resets takes place, you have to establish any FireWire cable
connections and fully initialize all FireWire hardware __before__ the
system enters such state.
Step-by-step instructions for using firescope with early OHCI initialization:
1) Verify that your hardware is supported:
Load the firewire-ohci module and check your kernel logs.
You should see a line similar to::
firewire_ohci 0000:15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT
... contexts, quirks 0x11
when loading the driver. If you have no supported controller, many PCI,
CardBus and even some Express cards which are fully compliant to OHCI-1394
specification are available. If it requires no driver for Windows operating
systems, it most likely is. Only specialized shops have cards which are not
compliant, they are based on TI PCILynx chips and require drivers for Windows
operating systems.
The mentioned kernel log message contains the string "physUB" if the
controller implements a writable Physical Upper Bound register. This is
required for physical DMA above 4 GB (but not utilized by Linux yet).
2) Establish a working FireWire cable connection:
Any FireWire cable, as long at it provides electrically and mechanically
stable connection and has matching connectors (there are small 4-pin and
large 6-pin FireWire ports) will do.
If an driver is running on both machines you should see a line like::
firewire_core 0000:15:00.1: created device fw1: GUID 00061b0020105917, S400
on both machines in the kernel log when the cable is plugged in
and connects the two machines.
3) Test physical DMA using firescope:
On the debug host, make sure that /dev/fw* is accessible,
then start firescope::
$ firescope
Port 0 (/dev/fw1) opened, 2 nodes detected
FireScope
---------
Target : <unspecified>
Gen : 1
[Ctrl-T] choose target
[Ctrl-H] this menu
[Ctrl-Q] quit
------> Press Ctrl-T now, the output should be similar to:
2 nodes available, local node is: 0
0: ffc0, uuid: 00000000 00000000 [LOCAL]
1: ffc1, uuid: 00279000 ba4bb801
Besides the [LOCAL] node, it must show another node without error message.
4) Prepare for debugging with early OHCI-1394 initialization:
4.1) Kernel compilation and installation on debug target
Compile the kernel to be debugged with CONFIG_PROVIDE_OHCI1394_DMA_INIT
(Kernel hacking: Provide code for enabling DMA over FireWire early on boot)
enabled and install it on the machine to be debugged (debug target).
4.2) Transfer the System.map of the debugged kernel to the debug host
Copy the System.map of the kernel be debugged to the debug host (the host
which is connected to the debugged machine over the FireWire cable).
5) Retrieving the printk buffer contents:
With the FireWire cable connected, the OHCI-1394 driver on the debugging
host loaded, reboot the debugged machine, booting the kernel which has
CONFIG_PROVIDE_OHCI1394_DMA_INIT enabled, with the option ohci1394_dma=early.
Then, on the debugging host, run firescope, for example by using -A::
firescope -A System.map-of-debug-target-kernel
Note: -A automatically attaches to the first non-local node. It only works
reliably if only connected two machines are connected using FireWire.
After having attached to the debug target, press Ctrl-D to view the
complete printk buffer or Ctrl-U to enter auto update mode and get an
updated live view of recent kernel messages logged on the debug target.
Call "firescope -h" to get more information on firescope's options.
Notes
-----
Documentation and specifications: http://halobates.de/firewire/
FireWire is a trademark of Apple Inc. - for more information please refer to:
https://en.wikipedia.org/wiki/FireWire
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
OHCI-1394 물리 DMA 디버깅 소개
1-39OHCI-1394 FireWire 컨트롤러가 제공하는 물리 DMA를 디버깅에 사용하는 방법
소개
현재 사용되는 FireWire 컨트롤러는 거의 모두 OHCI-1394 명세를 준수합니다. 이 명세에서 컨트롤러는 CPU 대신 DMA로 데이터 전송을 처리하는 PCI bus master이며, OHCI-1394 드라이버가 정의한 필터를 적용한 뒤 PCI-Bus master DMA를 사용해 특정 요청을 실행하는 `Physical Response Unit`을 갖습니다.
올바르게 구성하면 원격 시스템이 이러한 요청을 보내 OHCI-1394 컨트롤러에 물리 시스템 메모리 읽기와 쓰기를 수행하도록 지시할 수 있습니다. 읽기 요청의 경우 컨트롤러는 물리 메모리에서 읽은 결과를 요청자에게 돌려보냅니다.
따라서 `printk` buffer나 process table처럼 조사할 가치가 있는 메모리 위치를 읽어 문제를 디버깅할 수 있습니다.
FireWire를 통해 전체 시스템 메모리 덤프를 가져오는 것도 가능하며, 전송 속도는 대략 `10MB/s` 이상입니다.
대부분의 FireWire 컨트롤러에서 메모리 접근은 물리 주소 공간의 낮은 4 GB로 제한됩니다. 메모리 대부분이 이 한계보다 위에 있는 시스템에서는 문제가 될 수 있지만, x86, x86-64, PowerPC 같은 일반적인 하드웨어에서는 드물게 문제가 됩니다.
적어도 `LSI FW643e`와 `FW643e2` 컨트롤러는 4 GB보다 높은 물리 주소 접근을 지원하는 것으로 알려져 있지만, 현재 Linux는 이 기능을 활성화하지 않습니다.
디버깅을 위해 OHCI-1394 컨트롤러를 조기에 초기화하는 기능과 함께 사용하면, 이 수단은 `printk` buffer의 긴 debug log를 조사하거나 ACPI 같은 영역의 early boot 문제를 디버깅할 때 특히 유용합니다. 시스템이 부팅되지 않고 다른 디버깅 수단인 serial port를 notebook에서 사용할 수 없거나, ACPI처럼 방대한 debug information을 처리하기에 너무 느린 경우에 적합합니다.
드라이버와 조기 초기화
40-55드라이버
`drivers/firewire`의 `firewire-ohci` driver는 기본적으로 filtered physical DMA를 사용합니다. 이 방식이 더 안전하지만 remote debugging에는 적합하지 않습니다. Unfiltered physical DMA를 사용하려면 드라이버에 `remote_dma=1` parameter를 전달합니다.
`firewire-ohci` driver는 PCI enumeration이 끝나야 동작할 수 있으므로 x86에는 상당히 일찍 실행되는 initialization routine이 구현되어 있습니다. 이 routine은 `console_init()`이 호출되기 훨씬 전, 즉 `printk` buffer가 console에 나타나기 전에 실행됩니다.
활성화하려면 Kernel hacking menu의 `Remote debugging over FireWire early on boot` 항목인 `CONFIG_PROVIDE_OHCI1394_DMA_INIT`을 켜고, 다시 빌드한 kernel을 부팅할 때 `ohci1394_dma=early` parameter를 전달합니다.
firescope, firedump, fireproxy 도구
56-76도구
`firescope`는 Benjamin Herrenschmidt가 처음 개발했고 Andi Kleen이 PowerPC에서 x86 및 x86_64로 이식하면서 기능을 추가했습니다. 이제 `firescope`로 원격 시스템의 `printk` buffer를 live update와 함께 볼 수 있습니다.
Bernhard Kaindl은 32-bit `firescope`에서 64-bit 시스템에 접근하거나 그 반대로 접근할 수 있도록 `firescope`를 확장했습니다.
그는 빠른 system dump 기능도 구현했습니다. 이는 alpha version이므로 `README.txt`를 읽어야 합니다.
또한 FireWire용 `gdb` proxy가 있습니다. 이 도구를 사용하면 `gdb`가 `vmlinux`에서 찾은 symbol이 가리키는 data에 접근할 수 있습니다.
이 `gdb` proxy의 최신 버전인 `fireproxy-0.34`는 아직 안정적이지 않지만, memory 기반 communication module인 `kgdbom`을 통해 `kgdb`와 통신할 수 있습니다.
버스 리셋 전에 준비해야 할 사항
77-88시작하기
OHCI-1394 명세는 각 bus reset 때마다 OHCI-1394 컨트롤러가 모든 physical DMA를 비활성화하도록 규정합니다.
따라서 interrupt가 비활성화되어 있고 OHCI-1394 컨트롤러의 bus reset을 polling하지 않는 시스템 상태를 디버깅하려면, 시스템이 그 상태에 들어가기 `전에` FireWire cable 연결을 확립하고 모든 FireWire hardware를 완전히 초기화해야 합니다.
다음은 early OHCI initialization과 함께 `firescope`를 사용하는 단계별 절차입니다.
1단계: 지원 하드웨어 확인
89-1091) 하드웨어가 지원되는지 확인합니다.
`firewire-ohci` module을 load하고 kernel log를 확인합니다. 드라이버를 불러올 때 다음과 비슷한 줄이 보여야 합니다.
firewire_ohci 0000:15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT
... contexts, quirks 0x11지원되는 컨트롤러가 없다면 OHCI-1394 명세를 완전히 준수하는 PCI, CardBus 및 일부 Express card를 사용할 수 있습니다. Windows 운영체제에서 별도 driver가 필요하지 않은 카드라면 준수 제품일 가능성이 큽니다. 비준수 카드는 전문 판매점에서만 주로 볼 수 있으며 TI PCILynx chip을 기반으로 하므로 Windows에서도 driver가 필요합니다.
위 kernel log message에는 컨트롤러가 쓰기 가능한 `Physical Upper Bound` register를 구현한 경우 `physUB` 문자열이 들어갑니다. 이는 4 GB 위에서 physical DMA를 수행하는 데 필요하지만, 아직 Linux에서는 활용하지 않습니다.
2단계: FireWire 케이블 연결
110-1222) 정상 동작하는 FireWire cable connection을 구성합니다.
전기적으로나 기계적으로 안정적으로 연결되고 양쪽 connector가 맞는 FireWire cable이면 됩니다. FireWire port에는 작은 4-pin과 큰 6-pin 형식이 있습니다.
양쪽 시스템에서 driver가 실행 중이라면 cable을 연결하여 두 시스템이 이어질 때 양쪽 kernel log에서 다음과 같은 줄을 볼 수 있어야 합니다.
firewire_core 0000:15:00.1: created device fw1: GUID 00061b0020105917, S4003단계: firescope로 물리 DMA 시험
123-1463) `firescope`를 사용해 physical DMA를 시험합니다.
Debug host에서 `/dev/fw*`에 접근할 수 있는지 확인한 뒤 `firescope`를 시작합니다.
$ firescope
Port 0 (/dev/fw1) opened, 2 nodes detected
FireScope
---------
Target : <unspecified>
Gen : 1
[Ctrl-T] choose target
[Ctrl-H] this menu
[Ctrl-Q] quit
------> Press Ctrl-T now, the output should be similar to:
2 nodes available, local node is: 0
0: ffc0, uuid: 00000000 00000000 [LOCAL]
1: ffc1, uuid: 00279000 ba4bb801이제 `Ctrl-T`를 누릅니다. 출력에는 `[LOCAL]` node 외에 오류 메시지가 없는 다른 node가 하나 이상 보여야 합니다.
4단계: 조기 OHCI-1394 디버깅 준비
147-1594) Early OHCI-1394 initialization을 이용한 디버깅을 준비합니다.
4.1) Debug target에서 kernel을 compile하고 설치합니다.
디버깅할 kernel을 `CONFIG_PROVIDE_OHCI1394_DMA_INIT`이 활성화된 상태로 compile한 뒤, 디버깅 대상 시스템인 debug target에 설치합니다. Kernel hacking의 설명은 `Provide code for enabling DMA over FireWire early on boot`입니다.
4.2) 디버깅할 kernel의 `System.map`을 debug host로 전송합니다.
디버깅할 kernel의 `System.map`을 FireWire cable을 통해 대상 시스템에 연결된 debug host로 복사합니다.
5단계: printk 버퍼 가져오기
160-1785) `printk` buffer 내용을 가져옵니다.
FireWire cable을 연결하고 debugging host에서 OHCI-1394 driver를 load한 상태로 debugged machine을 reboot합니다. `CONFIG_PROVIDE_OHCI1394_DMA_INIT`이 활성화된 kernel을 `ohci1394_dma=early` option과 함께 부팅합니다.
그런 다음 debugging host에서 `firescope`를 실행합니다. 예를 들어 `-A`를 사용하면 다음과 같습니다.
firescope -A System.map-of-debug-target-kernel참고: `-A`는 첫 번째 non-local node에 자동으로 attach합니다. FireWire로 연결된 시스템이 두 대뿐일 때에만 안정적으로 동작합니다.
Debug target에 attach한 뒤 `Ctrl-D`를 누르면 전체 `printk` buffer를 볼 수 있습니다. `Ctrl-U`를 누르면 auto update mode로 들어가 debug target에 최근 기록된 kernel message를 갱신되는 live view로 볼 수 있습니다.
`firescope -h`를 호출하면 `firescope` option에 관한 자세한 정보를 확인할 수 있습니다.
문서와 상표 참고 사항
179-185참고
관련 Documentation과 specification은 다음 링크에서 확인할 수 있습니다.
FireWire는 `Apple Inc.`의 trademark입니다. 자세한 내용은 Wikipedia의 FireWire 문서를 참고하십시오.
요약과 해설
debugging-via-ohci1394.rst:1-185이 문서는 FireWire의 OHCI-1394 컨트롤러가 PCI bus master DMA로 원격 물리 메모리를 읽고 쓰는 기능을 kernel debugging에 활용하는 방법을 다룹니다. 특히 console이 준비되기 전의 긴 `printk` log와 ACPI early boot failure를 조사할 때 유용합니다.
보안을 위해 `firewire-ohci`가 기본 적용하는 physical DMA filter는 remote debugging과 맞지 않으므로 `remote_dma=1`이 필요합니다. 더 이른 시점의 문제를 보려면 `CONFIG_PROVIDE_OHCI1394_DMA_INIT`과 `ohci1394_dma=early`를 함께 사용합니다.
실제 작업 순서는 호환 controller 확인, 안정적인 cable 연결, `/dev/fw*`와 `firescope`로 DMA 시험, 대상 kernel의 `System.map` 전송, `firescope -A` attach 및 `Ctrl-D`/`Ctrl-U`를 이용한 `printk` 확인입니다. Bus reset은 physical DMA를 끄므로 interrupt가 멈추기 전에 연결과 초기화를 끝내야 합니다.