Debugging Embedded Linux
Section #6. Debugging Embedded Linux
From a device driver perspective, embedded software developers often face interfaces not commonly found on conventional computers. Figure 1.3 shows a hypothetical embedded device that could be a handheld, smart phone, point-of-sale (POS) terminal, kiosk, navigation system, gaming device, telemetry gadget on an automobile dashboard, IP phone, music player, digital settop box, or even a pacemaker programmer. The device is built around a System on Chip (SoC) and has some combination of flash memory, SDRAM, Liquid Crystal Display (LCD), serial ports, touch screen, Universal Serial Bus (USB), audio codec, connectivity, Secure Digital/Multimedia Card (SD/MMC) controller, Compact Flash, Inter-Integrated Circuit (I2C) devices, Serial Peripheral Interface (SPI) devices, biometrics, smart card interfaces, keypad, switches, and electronics specific to the industry domain. Modifying and debugging drivers for some of these devices can be tougher than usual: NAND flash drivers have to handle problems such as bad blocks and failed bits, unlike standard hard disk drivers. Flash-based filesystems such as Journalling Flash File System (JFFS) are more complex to debug than EXT2 or EXT3 filesystems. A USB On-The-Go (OTG) driver is more involved than a conventional USB Open Host Controller Interface (OHCI) driver. The SPI subsystem in the kernel is not as mature as the serial layer. Moreover, the industry domain using the embedded device might impose specific requirements such as deterministic response times or fast boot.
从设备驱动程序的角度来看，嵌入式软件开发人员经常面对传统计算机上常见的接口。图1.3显示了一个假想的嵌入式设备，可以是手持式，智能手机，销售点（POS）终端，自助服务终端，导航系统，游戏设备，汽车仪表板上的遥测小工具，IP电话，音乐播放器，数字机顶盒，甚至是可编程心脏起搏器。该器件围绕片上系统（SoC）构建，并具有闪存，SDRAM，液晶显示器（LCD），串行端口，触摸屏，通用串行总线（USB），音频编解码器，可连接，安全数字/的一些组合。多媒体卡（SD / MMC）控制器，紧凑型闪存，内部集成电路（I2C）设备，串行外围设备接口（SPI）设备，生物识别，智能卡接口，键盘，开关以及特定于行业领域的电子设备。某些设备的驱动程序的修改和调试可能比平常更难：与标准硬盘驱动程序不同，NAND闪存驱动程序必须处理坏块和故障位等问题。基于Flash的文件系统（如Journalling Flash File System（JFFS））比EXT2或EXT3文件系统更复杂。 USB On-The-Go（OTG）驱动程序比传统的USB开放式主机控制器接口（OHCI）驱动程序更为复杂。内核中的SPI子系统不如串行设备那么成熟。此外，使用嵌入式设备的行业领域可能会施加特定要求，例如确定性响应时间或快速启动。
Figure 1.3. Block diagram of a hypothetical embedded device
Let’s collect some pointers on debugging device drivers for I/O interfaces commonly found on embedded hardware. To do this, let’s take a clockwise tour around the embedded SoC shown in Figure 1.3, starting with the NOR flash. Before we end this section, let’s also learn some board-level debugging skills.
让我们收集关于调试嵌入式硬件上常见的I/O接口的设备驱动程序的一些技巧。为此，让我们顺时针浏览图1.3所示的嵌入式SoC，从NOR闪存开始。在结束本节之前，我们还将学习一些板级调试技巧。
Flash Memory
Embedded devices usually boot from flash memory and have filesystem data resident on flash-based storage. Many devices use a small NOR flash component for the former and a NAND flash part for the latter. NOR memory, thus, holds the bootloader and the base kernel, whereas NAND storage contains filesystem partitions and device driver modules.
嵌入式设备通常从闪存启动，并且文件系统数据驻留在基于闪存的存储上。许多器件为启动使用小型NOR闪存组件，为存储使用NAND闪存部件。因此，NOR存储器保存引导加载程序和基本内核，而NAND存储器包含文件系统分区和设备驱动程序模块。
Flash drivers are supported by the kernel’s Memory Technology Devices (MTD) subsystem. If you use an MTD-supported chip, you need to write only an MTD map driver to suitably partition the flash to hold the bootloader, kernel, and filesystem. The MTD subsystem resides in the drivers/mtd/ directory in the kernel source tree.
内核的内存技术设备（MTD）子系统支持闪存驱动程序。如果使用MTD支持的芯片，则只需编写MTD映射驱动程序即可对闪存进行适当分区以保存引导加载程序，内核和文件系统。 MTD子系统驻留在内核源代码树的drivers/mtd/目录中。
To debug flash-related problems, enable CONFIG_MTD_DEBUG (Device Drivers→Memory Technology Devices→Debugging) during kernel configuration. You can further tune the debug verbosity level to between 0 and 3.
要调试与闪存相关的问题，请在内核配置期间启用CONFIG_MTD_DEBUG（Device Drivers→Memory Technology Devices→Debugging）。您可以进一步将调试级别调整为0到3之间。
The Linux MTD project page www.linux-mtd.infradead.org/ has FAQs, various pieces of documentation, and a Linux MTD JFFS HOWTO that provides insights into JFFS2 design. The linux-mtd mailing list is the place to discuss questions related to MTD device drivers. Look at http://lists.infradead.org/pipermail/linux-mtd/ for the mailing list archives.
Linux MTD项目页面www.linux-mtd.infradead.org/包含常见问题解答，各种文档以及Linux MTD JFFS HOWTO，可提供有关JFFS2设计的见解。linux-mtd邮件列表是讨论与MTD设备驱动程序相关的问题的地方。请查看http://lists.infradead.org/pipermail/linux-mtd/以获取邮件列表存档。
Serial Port
The Universal Asynchronous Receiver/Transmitter (UART) chip is responsible for serial communication and is an interface you are likely to find on all SoCs. UARTs are considered basic hardware, so the kernel contains UART drivers for all SoCs on which it runs. On embedded devices, UARTs are used to interface the processor with debug serial ports, modems, touch controllers, cellular chipsets, Bluetooth silicon, Global Positioning System (GPS) units, telemetry electronics, and so on.
通用异步接收器/发送器（UART）芯片负责串行通信，是您在所有SoC上都能找到的接口。 UART被认为是基本硬件，因此内核在所有的SoC上包含UART驱动程序。在嵌入式设备上，UART用于将处理器与调试串行端口，调制解调器，触摸控制器，蜂窝芯片组，蓝牙芯片，全球定位系统（GPS）单元，遥测电子设备等连接。
In the Linux source tree, the drivers/serial/ directory contains the source code of the serial subsystem.
在Linux源代码树中，drivers/serial/目录包含串行子系统的源代码。
If the UART is meant to be your system console, debugging it isn’t an easy job because you can’t invoke printk() from inside the driver. If you have another console device and an associated working driver, you can print your debug messages to that device, however.
如果UART是您的系统控制台，那么调试它并不是一件容易的事，因为您无法从驱动程序内部调用printk（）。如果有其它的控制台设备和关联的驱动程序，则可以将调试消息打印到该设备。
PCMCIA and Compact Flash
PCMCIA (Personal Computer Memory Card International Association) or Compact Flash (CF) slots are common add-ons to embedded devices. The advantage of WiFi-enabling an embedded device using a CF card is that you don’t need to re-spin the board if the WiFi controller goes end of life. Also, because diverse technologies are available in the PCMCIA/CF form factor, you’ve the freedom to change the connectivity mode from WiFi to another technology such as Bluetooth later. The disadvantage of such a scheme is that even with mechanical retaining, sockets are inherently unreliable. There is the possibility of the card coming loose due to shock and vibe, and resulting intermittent connections.
PCMCIA（个人计算机存储卡国际协会）或Compact Flash（CF）插槽是嵌入式设备的常见附件。使用CF卡的嵌入式设备启用WiFi的优势在于，如果WiFi控制器坏了，则无需重新做电路板，更换即可。 此外，由于PCMCIA / CF提供了多种技术，您可以*地将连接模式从WiFi更改为其他技术（如蓝牙）。 这种方案的缺点在于，即使采用机械方式，插座本身也不可靠。由于震动，卡可能会松动，导致连接不稳定。
The kernel’s PCMCIA/CF subsystem lives in the drivers/pcmcia/ directory. 内核的PCMCIA/ CF子系统位于drivers/pcmcia/目录中。
To effectively debug PCMCIA/CF client drivers, you need to see debug messages emitted by the PCMCIA core. For this, enable CONFIG_PCMCIA_DEBUG (Bus options→PCCARD support→Enable PCCARD debugging) during kernel configuration. Verbosity levels of the debug output can be controlled either via the pcmcia_core.pc_debug kernel command-line argument or using the pc_debug module insertion parameter.
要有效地调试PCMCIA/CF客户端驱动程序，您需要查看PCMCIA内核发出的调试消息。 为此，在内核配置期间启用CONFIG_PCMCIA_DEBUG（Bus options→PCCARD support→Enable PCCARD debugging）。可以通过pcmcia_core.pc_debug内核命令行参数或使用pc_debug模块插入参数来控制调试输出的详细级别。
Information about PC Card client drivers is available in the process filesystem entry, /proc/bus/pccard/drivers. Look at /sys/bus/pcmcia/devices/* for card-specific information such as manufacturer and card IDs. Take a look inside /proc/bus/pci/ to know more about your PCMCIA host controller if your system uses a PCI-to-PCMCIA bridge. /proc/interrupts lists IRQs active on your system, including those used by the PCMCIA layer.
有关PC Card客户端驱动程序的信息，请参见proc文件系统条目/proc/bus/pccard/drivers。 查看/sys/bus/pcmcia/devices/ *以获取特定于卡的信息，例如制造商和卡ID。如果您的系统使用PCI-to-PCMCIA网桥，请查看/proc/bus/pci/以了解有关PCMCIA主控制器的更多信息。 /proc/interrupts列出系统上活动的IRQ，包括PCMCIA层使用的IRQ。
You can find a mailing list dedicated to Linux-PCMCIA at http://lists.infradead.org/mailman/listinfo/linux-pcmcia.
您可以在http://lists.infradead.org/mailman/listinfo/linux-pcmcia找到专用于Linux-PCMCIA的邮件列表。
Secure Digital Media
Many embedded processors include controllers that communicate with SD and MMC media. SD/MMC storage is built using NAND flash memory. Like CF cards, SD/MMC cards add several gigabytes of memory to your device. They also offer an easy memory upgrade path, because the available density of SD/MMC cards is constantly increasing.
许多嵌入式处理器包括与SD和MMC介质通信的控制器。SD/MMC存储使用NAND闪存构建。与CF卡一样，SD/MMC卡可为您的设备增加几千兆字节的内存。它们还提供简单的内存升级路径，因为SD/MMC卡的可用密度不断增加。
The kernel contains an SD/MMC subsystem in drivers/mmc/.内核在drivers / mmc /中包含SD/ MMC子系统。
The hdparm utility elicits various PATA/SATA disk parameters from the underlying kernel block driver. To benchmark disk read speeds on a SATA drive, for example, do this:
hdparm实用程序从底层内核块驱动程序中引出各种PATA/SATA磁盘参数。例如，要对SATA驱动器上的磁盘读取速度进行基准测试，请执行以下操作：
For the full capabilities of hdparm, read the man pages.
有关hdparm的完整功能，请阅读帮助手册。
Self-Monitoring, Analysis and Reporting Technology (SMART) is a system built into many modern ATA and SCSI disks to monitor failures and perform self-tests. A user space daemon named smartd collects the information gathered by SMART-capable disks with the help of the underlying device driver. Look at the man pages of smartd, smartctl, and smartd.conf to learn how to obtain health status from SMART-enabled disks.
自我监控，分析和报告技术（SMART）是许多现代ATA和SCSI磁盘中内置的系统，用于监控故障并执行自检。名为smartd的用户空间守护程序在底层设备驱动程序的帮助下收集由支持SMART的磁盘收集的信息。查看smartd，smartctl和smartd.conf的帮助手册，了解如何从启用SMART的磁盘获取运行状况。
If your distribution doesn’t pre-package hdparm and SMART tools, you can download them from http://sourceforge.net/projects/hdparm/ and http://sourceforge.net/projects/smartmontools/, respectively.
如果您的linux发行版没有预装hdparm和SMART工具，您可以分别从http://sourceforge.net/projects/hdparm/和http://sourceforge.net/projects/smartmontools/下载它们。
Files under /proc/ide/ contain information about IDE disk drives on your system. To obtain the geometry of the first IDE disk, look at the contents of /proc/ide/ide0/hda/geometry. Information pertaining to SCSI devices is available under /proc/scsi/. You can gather disk partition information from /proc/partitions.
/proc/ide/下的文件包含有关系统上IDE磁盘驱动器的信息。要获取第一个IDE磁盘的几何图形，请查看/proc/ide/ide0/hda/geometry的内容。有关SCSI设备的信息可在/proc/scsi/下找到。您可以从/proc/partitions收集磁盘分区信息。
The sysfs directory of interest for IDE devices is /sys/bus/ide/, whereas for SCSI is /sys/bus/scsi/. Additionally, each block device active on the system owns a subdirectory under /sys/block/, which contains associated request queue parameters, constituent partition details, and state information.
IDE设备的sysfs目录是/sys/bus/ide/，而SCSI是/sys/bus/scsi/。此外，系统上活跃的每个块设备都拥有/sys/block/下的子目录，该子目录包含相关的请求队列参数，分区详细信息和状态信息。
Some kernel configuration options are available that trigger emission of debug output from the block subsystem. CONFIG_BLK_DEV_IO_TRACE provides the ability to trace the block layer. CONFIG_SCSI_CONSTANTS and CONFIG_SCSI_LOGGING turn on SCSI error reporting and logging, respectively.
某些内核配置选项可用于触发块子系统的调试输出。CONFIG_BLK_DEV_IO_TRACE提供跟踪块层的功能。CONFIG_SCSI_CONSTANTS和CONFIG_SCSI_LOGGING分别打开SCSI错误报告和日志记录。
The linux-ide mailing list is the forum to discuss questions related to the Linux-IDE subsystem. Subscribe to the linux-scsi mailing list and browse through its archives for discussions pertaining to the Linux-SCSI subsystem.
linux-ide邮件列表是讨论与Linux-IDE子系统相关的问题的论坛。订阅linux-scsi邮件列表并浏览其存档以获取有关Linux-SCSI子系统的讨论。
Universal Serial Bus
Legacy computers support the USB host mode by which you can communicate with most classes of USB devices. Embedded systems frequently also require support for the USB device mode, wherein the system itself functions as a USB device and plugs into other host computers.
传统计算机支持USB主机模式，您可以通过该模式与大多数USB设备进行通信。嵌入式系统通常还需要支持USB设备模式，由于系统本身还需要被当作USB设备并插入其他计算机。
Many modern embedded controllers support USB OTG that lets your device work either as a USB host or as a USB device. It enables you, for example, to connect a USB pen drive to your embedded device. It also enables your embedded device to itself function as a USB pen drive by exporting part of its local storage for external access. The Linux USB subsystem (residing in drivers/usb/) offers drivers for USB OTG. For hardware that’s not compatible with OTG, the USB Gadget project (implemented in drivers/usb/gadget/), brings USB device capability.
现代许多嵌入式控制器支持USB OTG，可让您的设备作为USB主机或USB设备工作。例如，它可以将USB笔式驱动器连接到嵌入式设备。它还可以通过导出部分本地存储进行外部访问，使您的嵌入式设备本身可用作USB笔式驱动器。Linux USB子系统（驻留在drivers/usb/中）提供USB OTG的驱动程序。对于与OTG不兼容的硬件，USB Gadget项目（在drivers/usb/gadget/中实现）带来了USB设备功能。
A USB bus analyzer magnifies the goings-on in the bus and is useful for debugging low-level problems. If you can’t get hold of an analyzer, you might make do with the kernel’s soft USB tracer usbmon. This tool captures traffic between USB host controllers and devices. To collect a trace, read from the debugfs[9] file /sys/kernel/debug/usbmon/Xt, where X is the bus number to which your device is connected.
USB总线分析仪可以放大总线上的故障，可用于调试底层的问题。如果你无法掌握分析仪，你可能会使用内核的软USB跟踪器usbmon。此工具可捕获USB主机控制器和设备之间的流量。要收集跟踪，请从debugfs [9]文件/sys/kernel/debug/usbmon/Xt中读取，其中X是设备所连接的总线编号。
[9] An in-memory filesystem to export kernel debug data to user space.
For example, consider a USB disk connected to a PC. From the associated “T:” line in /proc/bus/usb/devices, you can see that the drive is attached to bus 1:
例如，以连接到PC的USB磁盘为例。从/proc/bus/usb/devices中关联的“T：”行，您可以看到驱动器连接到总线1：
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
Ensure that you have enabled debugfs (CONFIG_DEBUG_FS) and usbmon (CONFIG_USB_MON) support in your kernel. This is a snapshot of usbmon output while copying a file from the disk:
确保已在内核中启用了debugfs（CONFIG_DEBUG_FS）和usbmon（CONFIG_USB_MON）。 这是从磁盘复制文件时usbmon输出的快照：
Each output line starts with the URB address, followed by an event timestamp. An S in the next column indicates URB submission, whereas a C announces a callback. The following field has the format URBType:Bus#:DeviceAddress:Endpoint#. In the preceding output, a URBType of Bi stands for a bulk URB in the IN direction. After this, usbmon dumps the URB status, data length, a data tag (= or < in the preceding output), and the data words (if the tag is =). The last three lines in the preceding output are callbacks associated with bulk URBs submitted in earlier lines. You can match the callbacks with the related submissions using the URB addresses. Documentation/usb/usbmon.txt details usbmon syntax and contains example code to parse the output into human readable form.
每个输出行以URB地址开头，后跟事件时间戳。下一列中的S表示URB提交，而C表示回调。以下字段的格式为URBType：Bus＃：DeviceAddress：Endpoint＃。在前面的输出中，UR的URBType代表IN方向的批量URB。在此之后，usbmon转储URB状态，数据长度，数据标记（=或<在前面的输出中）和数据字（如果标记是=）。前面输出中的最后三行是与早期行中提交的批量URB相关联的回调。您可以使用URB地址将回调与相关提交进行匹配。Documentation/usb/usbmon.txt详细介绍了usbmon语法，并包含将输出解析为人类可读形式的示例代码。
If you turn on Device Drivers → USB support → USB verbose debug messages during kernel configuration, the kernel will emit the contents of all dev_dbg() statements present in the USB subsystem.
如果在内核配置期间打开Device Drivers → USB support → USB verbose debug messages，内核将输出USB子系统中所有dev_dbg（）语句的内容。
You can glean device and bus specific information from the USB filesystem (usbfs) node /proc/bus/usb/devices. usbfs also lets you implement USB device drivers in user space. Even when the final destination of your USB driver is inside the kernel, starting with a user space driver can ease debugging and testing.
您可以从USB文件系统（usbfs）节点/proc/bus/usb/devices中收集设备和总线信息。usbfs还允许您在用户空间实现USB设备驱动程序。虽然USB驱动程序最终位于内核中，但从用户空间驱动程序开始，可以简化调试和测试。
The linux-usb-devel mailing list is the forum to discuss questions related to USB device drivers. Visit https://lists.sourceforge.net/lists/listinfo/linux-usb-devel for subscription and archive retrieval information. Read www.linux-usb.org/usbtest for ideas on USB testing.
linux-usb-devel邮件列表是讨论与USB设备驱动程序相关的问题的论坛。访问https://lists.sourceforge.net/lists/listinfo/linux-usb-devel以获取订阅和归档检索信息。有关USB测试的建议，请阅读www.linux-usb.org/usbtest。
The home page of the Linux-USB project is www.linux-usb.org/. You can download the USB 2.0 specification, OTG supplement, and other related standards from www.usb.org/developers/docs/.
Linux-USB项目的主页是www.linux-usb.org/。您可以从www.usb.org/developers/docs/下载USB 2.0规范，OTG补充和其他相关标准。
Real Time Clock
Many embedded SoCs include RTC support to keep track of wall time, but some rely on an external RTC chip. Unlike x86-based computers where the RTC is part of the South Bridge chipset, embedded controllers commonly interface with external RTCs via slow serial buses such as I2C or SPI. You can drive such RTCs by writing client drivers that use the services of the I2C or SPI core layers. The former drivers can be found under drivers/i2c/, and the latter under drivers/spi/.
许多嵌入式SoC支持RTC以跟踪时间，但有些依赖于外部RTC芯片。在基于x86的计算机中，RTC是南桥芯片组的一部分，嵌入式控制器与其不同。嵌入式控制器通常通过I2C或SPI等慢速串行总线与外部RTC连接。您可以通过编写使用I2C或SPI核心层服务的客户端驱动程序来驱动此类RTC。前端驱动程序可以在drivers / i2c /下找到，后端驱动在drivers / spi /下。
To collect I2C-specific debugging messages, turn on a relevant combination of I2C Core debugging messages, I2C Algorithm debugging messages, I2C Bus debugging messages, and I2C Chip debugging messages under Device Drivers→I2C support in the kernel configuration menu. Similarly, for SPI debugging, turn on Debug Support for SPI drivers under Device Drivers→SPI support.
要收集特定于I2C的调试消息，请在内核配置菜单中的Device Drivers→I2C支持下打开I2C核心调试消息，I2C算法调试消息，I2C总线调试消息和I2C芯片调试消息等。同样，对于SPI调试，在Device Drivers→SPI支持下打开SPI驱动程序的调试支持。
To understand the flow of I2C packets on the bus, connect an I2C bus analyzer to your board. The lm-sensors package contains a tool called i2cdump that dumps register contents of devices on the I2C bus.
要了解总线上I2C数据包的流量，请将I2C总线分析仪连接到电路板。 lm-sensors软件包包含一个名为i2cdump的工具，用于转储I2C总线上设备的寄存器内容。
You can find a mailing list dedicated to Linux I2C at http://lists.lm-sensors.org/mailman/listinfo/i2c.
您可以在http://lists.lm-sensors.org/mailman/listinfo/i2c找到专用于Linux I2C的邮件列表。
Audio
An audio codec converts digital audio data to analog sound signals for playback via speakers and performs the reverse operation for recording through a microphone. The codec’s connection with the CPU depends on the digital audio interface supported by the embedded controller. The usual way to communicate with a codec is via the Audio Codec’97 (AC’97) bus or the Inter-IC Sound (I2S) bus for data and I2C for the control interface.
音频编解码器将数字音频数据转换为模拟声音信号，以便通过扬声器进行播放，并执行反向操作以通过麦克风进行录制。编解码器与CPU的连接取决于嵌入式控制器支持的数字音频接口。与编解码器通信的常用方法是通过音频编解码器97（AC'97）总线或用于控制接口的数据间IC（I2S）和I2C。
Advanced Linux Sound Architecture (ALSA) is the sound framework of choice in the 2.6 kernel. ALSA obsoletes Open Sound System (OSS), which was the sound subsystem in 2.4 kernels. The kernel’s sound core and audio bus drivers stay inside the top-level sound/ directory in the kernel source tree.
高级Linux声音体系结构（ALSA）是2.6内核中的首选声音框架。 ALSA废弃了Open Sound System（OSS），它是2.4内核中的声音子系统。 内核的声音核心和音频总线驱动程序保留在内核源代码树中的*sound/目录中。
You may turn on options under Device Drivers→Sound→Advanced Linux Sound Architecture in the kernel configuration menu to include ALSA debug code (CONFIG_SND_DEBUG), verbose printk() messages (CONFIG_SND_VERBOSE_PRINTK), and verbose procfs content (CONFIG_SND_VERBOSE_PROCFS).
Procfs information pertaining to ALSA drivers resides in /proc/asound/. Look inside /sys/class/sound/ for the device model information associated with each sound-class device.
您可以在内核配置菜单中打开Device Drivers→Sound→Advanced Linux Sound Architecture下的选项，以包括ALSA调试代码（CONFIG_SND_DEBUG），详细的printk（）消息（CONFIG_SND_VERBOSE_PRINTK）和详细的procfs内容（CONFIG_SND_VERBOSE_PROCFS）。
与ALSA驱动程序有关的Procfs信息位于/proc/asound/中。在/sys/class/sound/里面查看与每个声级设备相关的设备型号信息。
If you think you have found a bug in an ALSA driver, post it to the alsa-devel mailing list (http://mailman.alsa-project.org/mailman/listinfo/alsa-devel). The linux-audio-dev mailing list (http://music.columbia.edu/mailman/listinfo/linux-audio-dev/), also called the Linux Audio Developers (LAD) list, discusses questions related to the Linux-Sound architecture and audio applications.
如果您认为在ALSA驱动程序中发现了错误，请将其发布到alsa-devel邮件列表（http://mailman.alsa-project.org/mailman/listinfo/alsa-devel）。linux-audio-dev邮件列表（http://music.columbia.edu/mailman/listinfo/linux-audio-dev/）也称为Linux音频开发人员（LAD）列表，讨论与Linux-Sound架构和音频应用相关的问题。
Touch Screen
Touch is the primary input mechanism on several embedded devices. Many handhelds offer soft touch keyboards for data entry.
触摸屏是许多嵌入式设备上的主要输入机制。许多手持设备提供用于数据输入的软触摸键盘。
The kernel offers an input subsystem for the uniform handling of functionally similar input devices even if they are physically different. For example, all mice, whether they are PS/2, USB, or Bluetooth, are treated alike. The kernel also provides an event abstraction for dispatching input reports to user applications. Applications such as X Windows work seamlessly over the event interfaces exported by the input subsystem.
内核提供了一个输入子系统，用于统一处理功能相似的输入设备，即使它们在物理上是不同的。例如，所有鼠标，无论是PS/2，USB还是蓝牙，都受到同样的对待。内核还提供了一个事件抽象，用于将输入报告分发给用户应用程序。X Windows等应用程序可以在输入子系统导出的事件接口上无缝工作。
If your touch controller driver conforms to the input event abstraction, it’s straightforward to tie it with a graphical user interface (GUI).
如果您的触摸控制器驱动程序符合输入事件抽象，则可以直接将其与图形用户界面（GUI）联系起来。
You can use the evbug module as a debugging aid if you’re developing an input driver. It dumps the (type, code, value) tuple corresponding to events generated by the input subsystem. Figure 1.4 contains data captured by evbug while operating some input devices.
如果您正在开发输入驱动程序，则可以使用evbug模块作为调试辅助工具。它转储与输入子系统生成的事件对应的（类型，代码，值）元组。 图1.4包含evbug在操作某些输入设备时捕获的数据。
Figure 1.4. Evbug output
To make sense of the dump in Figure 1.4, remember that touchpads generate absolute coordinates (EV_ABS) or event type 0x03, trackpoints produce relative coordinates (EV_REL) or event type 0x02, and keyboards emit key events (EV_KEY) or event type 0x01. Event type 0x0 corresponds to an invocation of input_sync(), which does the following:
要理解图1.4中的转储，请记住触摸板生成绝对坐标（EV_ABS）或事件类型0x03，轨迹点生成相对坐标（EV_REL）或事件类型0x02，键盘发出键事件（EV_KEY）或事件类型0x01。事件类型0x0对应于input_sync（）的调用，它执行以下操作：
input_event(dev, EV_SYN, SYN_REPORT, 0);
This translates to a (type, code, value) tuple of (0x0, 0x0, 0x0) and completes each input event.
这转换为（0x0,0x0,0x0）的（类型，代码，值）元组，并完成每个输入事件。
Video
Some embedded systems are headless, but many have associated displays. A suitably oriented (landscape or portrait) LCD panel is connected to the video controller that’s part of the embedded SoC.
有些嵌入式系统是无显示器的，但很多有显示器。合适的LCD面板连接到视频控制器，该控制器是嵌入式SoC的一部分。
The kernel’s frame buffer interface insulates applications from display hardware, so porting a compliant GUI to your device is easy if your display driver conforms to the kernel’s frame buffer abstraction. The frame buffer core layer and low-level frame buffer drivers reside in the drivers/video/ directory.
内核的帧缓冲接口将应用程序与显示硬件隔离开来，因此如果您的显示驱动程序符合内核的帧缓冲区抽象，则可以轻松地将兼容的GUI移植到您的设备。帧缓冲核心层和低级帧缓冲驱动程序在drivers / video /目录中。
The virtual frame buffer driver, enabled by setting CONFIG_FB_VIRTUAL in the configuration menu, operates over a pseudo graphics adapter. You can use this driver’s assistance to debug the frame buffer subsystem.
在配置菜单中设置CONFIG_FB_VIRTUAL，就会启用的虚拟帧缓冲驱动程序，该驱动通过伪图形适配器进行操作。您可以借助此驱动程序的帮助来调试帧缓冲子系统。
Some frame buffer drivers, such as intelfb, offer an additional configuration option that you can enable to generate driver-specific debug information.
某些帧缓冲驱动程序（如intelfb）提供了一个附加配置选项，您可以启用该选项以生成特定于驱动程序的调试信息。
To discuss issues related to frame buffer drivers, subscribe to the linux-fbdev-devel mailing list, https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel/.
要讨论与帧缓冲驱动程序相关的问题，请订阅linux-fbdev-devel邮件列表，https：//lists.sourceforge.net/lists/listinfo/linux-fbdev-devel/。
Bluetooth
Connectivity injects intelligence, so few embedded devices have no communication capability. Popular networking technologies found on embedded devices include Bluetooth, Infrared, WiFi, cellular modems, and radio communication.
连接注入智能，因此嵌入式设备基本都有通信能力。在嵌入式设备上发现的流行网络技术包括蓝牙，红外，WiFi，蜂窝调制解调器和无线电通信。
Bluetooth eliminates cables and opens a flood gate of novel applications. The BlueZ Bluetooth implementation is part of the mainline kernel and is the official Linux Bluetooth stack. Look inside drivers/bluetooth/ for low-level BlueZ drivers.
蓝牙不使用电缆并打开了新应用的大门。BlueZ蓝牙是主线内核的一部分，是官方Linux蓝牙堆栈。从drivers/bluetooth/查看底层BlueZ驱动程序。
There are two BlueZ tools useful for debugging:
有两个BlueZ工具可用于调试：
- hcidump taps HCI packets flowing back and forth and parses them into human-readable form. Here’s an example dump while a device inquiry is in progress: 1. Hcidump捕获流动的HCI数据包并将其解析为可读的形式。这是设备查询正在运行的示例转储：
- The virtual HCI driver (hci_vhci.ko) emulates a Bluetooth interface if you do not have actual hardware. 如果您没有硬件，虚拟HCI驱动程序（hci_vhci.ko）将模拟蓝牙接口。
Board Rework
Navigating board schematics and datasheets is an important debugging skill you need while bringing up the bootloader or kernel on embedded hardware. Understanding your board’s placement plot, which is a file that shows the position of chips on your board, is a big help when you debug a potential hardware problem using an oscilloscope, or when you need to perform minor board rework. Reference designators (such as U10 and U11 in Figure 1.5) associate each chip in the schematic with the placement plot. Printed Circuit Boards (PCBs) are usually clothed with silk screens that print the reference designator near each chip.
导航板原理图和数据表是在嵌入式硬件上启动bootloader或内核时所需的重要调试技巧。 了解电路板的布局图，这是一个显示电路板上芯片位置的文件，在使用示波器调试潜在的硬件问题时，或者当您需要进行电路板小的修改时，布局图很有帮助。参考标志（如图1.5中的U10和U11）将原理图中的每个芯片与布局图相关联。印刷电路板（PCB）通常采用丝网印刷，在每个芯片附近印刷参考标志。
Figure 1.5. Debugging an I2C RTC on an embedded system
Consider this fictitious scenario in which USB enumeration doesn’t occur on your board under test. The USB hub driver detects device insertions but cannot assign endpoint addresses. A close look at the schematics reveals that the connections originating from the SPEED and MODE pins of the USB transceiver have been interchanged by mistake. An examination of the placement plot identifies the location of the transceiver on the PCB. Matching the transceiver’s reference designator on the placement plot with the silk screen on the PCB pinpoints the places where you have to solder “yellow wires” to repair the faulty connections.
考虑一个虚构的场景，在您的测试板上USB不能枚举。USB集线器驱动程序检测到设备插入，但无法分配端点地址。仔细查看原理图后发现，USB收发器的SPEED和MODE引脚的连接错误地互换。对布局图的检查确定了收发器在PCB上的位置。将布局图上的收发器参考标记与PCB上的印刷电路相匹配，确定必须焊接“黄线”以修复故障连接。
A multimeter and an oscilloscope are worthy additions to your embedded debugging toolkit. As an illustration, let’s consider an example situation involving the I2C RTC shown in Figure 1.5. Consider this scenario: You have written an I2C client driver for this RTC chip. However, when you run your driver on the board, it renders the system unbootable. Neither does the bootloader come up when you reset the board, nor does your JTAG debugger connect to the target. To understand possible causes of this seemingly fatal error, let’s take a closer look at the connection diagram. Because both the RTC and the CPU need an external clock, the board supplies it using a single 32 KHz crystal. This 32 KHz clock needs to be buffered, however. The RTC buffers the clock for its use and makes it available on an output pin for free. This pin CLK_OUT, feeds the clock to the processor. Connect an oscilloscope (or a multimeter that can measure frequency) between CLK_OUT and ground to verify the processor clock frequency. As you can see in Figure 1.5, the scope reads 1 KHz rather than the expected 32 KHz! What could be wrong here?
万用表和示波器是嵌入式调试工具包的有益补充。作为一个例子，让我们考虑一个涉及图1.5所示的I2C RTC的示例情况。请考虑以下情况：您已为此RTC芯片编写了I2C客户端驱动程序。但是，当您在板上运行驱动程序时，它会使系统无法启动。重启电路板时，bootloader也不会出现，JTAG调试器也不会连接到目标。为了理解这个看似致命的错误的可能原因，让我们仔细看看连接图。由于RTC和CPU都需要外部时钟，因此电路板使用单个32 KHz晶振供电。但是，这个32 KHz时钟需要进行缓冲。 RTC缓冲时钟供其使用，并在输出引脚上免费提供。该引脚CLK_OUT将时钟提供给处理器。在CLK_OUT和地之间连接示波器（或可测量频率的万用表）以验证处理器时钟频率。如图1.5所示，示波器读数为1 KHz而不是预期的32 KHz！问题就是出在这里。
The RTC control register contains bits that choose the frequency of CLK_OUT. While probing the chip, the driver has erroneously initialized these bits to generate 1 KHz on CLK_OUT. RTC registers are nonvolatile because of the battery backup, so the control register holds this bad value across reboots. The resulting skewed clock is sufficient to render the system unbootable. Disconnect the RTC’s backup battery, drain the registers, reconnect the battery, verify using the scope that the 32 KHz clock is restored on CLK_OUT, fix your driver code, and start afresh!
RTC控制寄存器包含选择CLK_OUT频率的位。在探测芯片时，驱动器错误地初始化这些位以在CLK_OUT上产生1 KHz。由于有备用电池，RTC寄存器是非易失性的，因此控制寄存器在重启时保持这个错误值。产生的时钟偏差足以使系统无法启动。断开RTC的备用电池，清空寄存器，重新连接电池，确保CLK_OUT上恢复32 KHz时钟频率，修复驱动程序代码，然后重新开始！
Test Equipment
It goes without saying that you need the full complement of relevant test equipment for device driver debugging. If you test a modem interface in a digital-only laboratory environment for example, you will be well served by a phone simulator. If a high-speed serial driver is manifesting parity errors, an oscilloscope can aid your problem analyses. If you are writing an I/O device driver, it helps if you have the associated bus analyzer. If you are writing a network driver, the corresponding protocol line sniffer eases your debugging effort.
毫无疑问，您需要完整的测试设备来进行设备驱动程序调试。例如，如果您在仅限数字的实验室环境中测试调制解调器接口，那么电话模拟器将提供良好的服务。如果高速串行驱动程序出现奇偶校验错误，示波器可以帮助进行问题分析。如果您正在编写I/O设备驱动程序，如果您有相关的总线分析器，则会有所帮助。如果您正在编写网络驱动程序，相应的协议嗅探器可以简化您的调试工作。