企业官网建设流程全解析

1. 从一块不亮的屏幕说起：MIPI-DSI 到底在系统里扮演什么角色

如果你手里正拿着一块 MIPI-DSI 接口的屏幕，接上板子，上电，结果背光亮了但屏幕一片漆黑，或者干脆连背光都不亮，那你大概率正站在一个嵌入式显示调试的经典路口。这个路口的第一块路牌，就是搞清楚 MIPI-DSI 这个硬件接口到底在系统里干了什么。

MIPI-DSI，全称 Mobile Industry Processor Interface - Display Serial Interface，翻译过来就是移动产业处理器接口下的显示串行接口。名字很长，但核心意思很朴素：它是处理器和显示屏之间的一条高速串行数据通道。你可以把它理解成一条专门给图像数据修的高速公路，处理器是发货方，屏幕是收货方，DSI 就是那条路。这条路和传统的 RGB 并口、LVDS 接口最大的区别在于，它是串行的、差分信号传输的、带独立时钟通道的，而且协议层还分了命令模式和视频模式两种工作方式。

为什么现在越来越多的屏幕用 DSI 而不是 RGB 并口？原因很直接。RGB 并口需要 24 根左右的数据线加时钟线，走线多、占面积、抗干扰能力一般，分辨率一高时钟频率就压不住。DSI 用差分对传输，一对线就能跑几百 Mbps 到 Gbps 级别的速率，线少、速率高、抗干扰好，特别适合移动设备和嵌入式设备这种板子空间紧张、又需要高分辨率显示的场景。所以从手机到平板，从开发板到工业 HMI，DSI 几乎成了中小尺寸屏幕的首选接口。

但 DSI 的复杂也恰恰来自它的优势。串行差分意味着信号完整性要求高，协议分层意味着初始化流程长，命令模式和视频模式的差异意味着驱动配置完全不同。很多新手第一次点 DSI 屏，卡住的地方往往不是驱动代码写错了，而是根本没搞清楚自己这块屏是命令模式还是视频模式，或者 DSI 的 lane 数、时钟频率、时序参数没配对。这些参数任何一个不对，屏幕就是黑的，而且报错信息往往很模糊，让你无从下手。

这篇内容就是围绕“屏幕点亮”这个最实际的目标，把 MIPI-DSI 从硬件接口到协议初始化、从设备树配置到实测排查的完整链路拆开讲。不管你是刚拿到一块新屏不知道怎么下手的初学者，还是已经调过几块屏但遇到问题只能靠试的老手，这里面的思路和细节都能直接拿去用。我会尽量把每个参数背后的“为什么”讲清楚，因为只有理解了原理，你才能在屏幕不亮的时候知道该往哪个方向查，而不是盲目改代码。

2. DSI 的物理层与协议层：信号是怎么从处理器走到屏幕的

2.1 差分对、时钟通道和 lane 数的实际含义

MIPI-DSI 的物理连接由两类通道组成：一条时钟通道（Clock Lane）和若干条数据通道（Data Lane）。时钟通道是差分对，数据通道也是差分对，每条差分对由 P 和 N 两根线组成。你在原理图上看到的 DSI_CLK_P、DSI_CLK_N、DSI_D0_P、DSI_D0_N 这些网络名，对应的就是这些差分对。

数据通道的数量就是常说的 lane 数。一条 lane 就是一对差分线，能同时传输一位数据。常见的配置有 1 lane、2 lanes、4 lanes。lane 数越多，理论带宽越大。比如同样跑 1Gbps 的速率，4 lane 就是 4Gbps 的总带宽，1 lane 只有 1Gbps。但 lane 数不是随便选的，它由处理器端的 DSI 控制器和屏幕端的接收能力共同决定。你用的处理器 DSI 控制器支持 4 lane，但屏幕只支持 2 lane，那就只能用 2 lane，多接反而可能不工作。

这里有个实际调试中很容易忽略的点：lane 的顺序和极性。DSI 的差分对是有正负之分的，P 和 N 接反了，信号就反相，屏幕大概率不亮或者花屏。有些处理器的 DSI 控制器支持 lane 极性翻转和 lane 顺序重映射，可以在设备树里配置；有些则不支持，必须硬件上接对。我在实际项目里就遇到过因为 PCB 走线时把 D0 和 D1 的 P/N 接反导致屏幕完全不亮的情况，查了半天软件，最后用示波器量差分信号才发现是硬件问题。所以拿到一块新板子，先确认原理图上 DSI 的 lane 顺序和极性是否和处理器手册里的推荐接法一致，这一步能省掉后面很多无用功。

2.2 高速模式和低功耗模式：DSI 为什么要两套信号电平

DSI 的物理层有一个很特别的设计：它支持两种信号传输模式，高速模式（High-Speed Mode，HS）和低功耗模式（Low-Power Mode，LP）。这两种模式的区别不只是速率，连信号电平都不一样。

高速模式下，差分对的共模电压很低，摆幅也很小，典型差分摆幅在 100mV 到 300mV 之间，目的是为了在高频下降低功耗和电磁干扰。低功耗模式下，信号摆幅接近电源电压，典型在 0V 到 1.2V 之间，速率低但抗干扰好，主要用于传输控制命令和进入/退出高速模式的切换信号。

为什么要有两套模式？因为 DSI 链路在大部分时间里其实并不需要全速传输图像数据。比如屏幕初始化阶段，处理器只需要发几条配置命令，数据量很小，用低功耗模式就够了，还省电。等到要刷屏了，再切到高速模式批量传图像数据。传输间隙又可以切回低功耗模式。这种动态切换机制让 DSI 在功耗和带宽之间取得了很好的平衡，也是它适合移动设备的重要原因。

但这个切换机制也给调试带来了麻烦。因为低功耗模式和高速模式的信号特征完全不同，用示波器抓波形时，如果你只设了一个触发条件，很可能只能抓到其中一种模式的信号。我通常建议先用低功耗模式的信号作为触发，因为初始化阶段一定有 LP 信号，抓到之后再观察 HS 切换的过程。另外，有些屏幕对 LP 和 HS 的切换时序有严格要求，比如 LP 到 HS 的建立时间、HS 到 LP 的保持时间，这些参数如果和屏幕手册对不上，也可能导致初始化失败。

2.3 命令模式和视频模式：两种截然不同的工作方式

DSI 协议定义了两种工作模式：命令模式（Command Mode）和视频模式（Video Mode）。这两种模式的区别，直接决定了你的驱动该怎么写、设备树该怎么配。

命令模式下的屏幕，内部通常带一块显示缓存（GRAM）。处理器通过 DSI 发送命令和数据，把图像写入屏幕的 GRAM，屏幕自己负责从 GRAM 里读数据并刷新到面板上。这种模式下，DSI 链路不需要持续传输数据，只在有更新时才传，所以功耗更低。很多小尺寸屏幕、MIPI 屏模组用的都是命令模式。命令模式的屏幕通常还会带一个 TE（Tearing Effect）信号引脚，用来告诉处理器“我这一帧刷完了，你可以发下一帧了”，避免画面撕裂。

视频模式下的屏幕，内部没有缓存或者缓存很小，需要处理器持续不断地把图像数据流推过来，屏幕才能正常显示。这种模式对 DSI 链路的带宽和时序要求更高，因为一旦数据流断了，屏幕就会黑屏或花屏。视频模式通常用在大尺寸、高分辨率的屏幕上，比如平板和车载显示屏。

怎么判断自己手里的屏是哪种模式？最直接的方法是看屏幕的数据手册（Datasheet）。手册里会明确写“Command Mode”还是“Video Mode”，或者写“Supports MIPI DSI Command Mode”之类的描述。如果手册找不到，可以看屏幕的引脚定义：如果有一个 TE 引脚，大概率是命令模式；如果没有 TE 但分辨率很高，大概率是视频模式。另外，命令模式的屏幕初始化时通常需要发一堆厂商自定义的命令序列，而视频模式的屏幕初始化相对简单，主要是配置时序参数。

我在实际项目中遇到过一块屏，手册上写的是视频模式，但设备树里配成了命令模式，结果屏幕能亮但画面严重撕裂，像被刀切过一样。后来改成视频模式并配好时序参数，画面就正常了。所以模式判断错误是 DSI 调试中非常常见的一个坑，而且症状往往不是完全不亮，而是“亮了但不对”，更容易让人误判。

3. 点亮一块 DSI 屏之前，硬件侧必须确认的几件事

3.1 电源域和上电时序：屏幕不亮的头号嫌疑犯

很多人拿到屏幕第一件事就是改驱动、调设备树，但我想说，在动软件之前，先把硬件侧的电源和时序确认一遍，能排除掉至少一半的“不亮”问题。

DSI 屏幕通常需要多路电源：模拟电源（AVDD）、数字电源（DVDD）、IO 电源（IOVDD），有的还有背光电源（LED+/LED-）。这些电源的上电顺序和时序间隔，屏幕手册里一般都有明确要求。比如某块屏要求 AVDD 先上，延迟 10ms 后 DVDD 上，再延迟 5ms 后 IOVDD 上，全部上电完成后至少等待 120ms 才能发初始化命令。如果你用了一个统一的 3.3V 供电，或者上电顺序反了，屏幕可能根本不响应初始化命令。

我踩过的一个坑是：某块屏的 IOVDD 要求 1.8V，但我一开始接成了 3.3V，结果屏幕的 IO 接口被过压，虽然没烧，但通信完全乱码，初始化命令发过去没任何反应。后来改成 1.8V 就正常了。所以第一步一定是拿万用表量每一路电源的电压，确认和手册一致，再用示波器看上下电时序是否符合要求。

另外，复位引脚（RESET）的时序也很关键。大多数屏幕要求复位拉低至少 10ms，然后拉高，再等待一段时间才能发命令。有些处理器的复位引脚是默认拉高的，如果你在设备树里没配置复位 GPIO，屏幕可能一直处于复位状态，自然不亮。这个细节在设备树配置章节我会再展开。

3.2 背光电路：屏幕亮了但看不见的常见原因

背光问题和 DSI 链路问题是两个独立的问题，但症状很容易混淆。DSI 链路没通，屏幕是黑的；背光没亮，屏幕也是黑的。怎么区分？很简单，用手电筒照屏幕，如果能看到淡淡的图像，说明 DSI 链路是通的，只是背光没亮；如果什么都看不到，那可能是 DSI 链路和背光都有问题，或者只是 DSI 链路有问题。

背光电路常见的有两种：一种是屏幕模组自带背光驱动，你只需要给背光电源和使能信号；另一种是屏幕只提供 LED 灯串，需要外部的背光驱动芯片，比如常见的升压恒流驱动。对于第二种，你需要确认背光驱动芯片的使能引脚、PWM 调光引脚是否正确连接和配置。PWM 频率一般建议在 1kHz 到 20kHz 之间，太低会有可闻噪声，太高可能超出驱动芯片能力。

我遇到过一块屏，背光驱动芯片的使能引脚在设备树里配成了高有效，但实际硬件上是低有效，结果背光一直不亮。后来把 GPIO 极性改过来就好了。所以背光不亮时，先量使能引脚的电压，再量 PWM 引脚有没有波形，最后量 LED 灯串两端的电压是否达到驱动芯片的升压目标值。这三步基本能定位大部分背光问题。

3.3 差分走线和连接器：信号完整性的隐形杀手

DSI 的差分信号速率很高，对 PCB 走线和连接器的要求比普通信号严格得多。差分对要求等长、等距、阻抗匹配，通常要求 100 欧姆差分阻抗。如果走线不等长，或者阻抗不匹配，信号到达接收端时眼图会闭合，导致误码率升高，屏幕可能花屏、闪屏或者完全不亮。

连接器也是容易被忽略的一环。有些开发板用的 FPC 连接器质量一般，插拔几次后接触不良，DSI 信号时好时坏。我建议在调试阶段，先用万用表量一下连接器两端对应引脚的通断，确认没有虚焊或接触不良。如果条件允许，用示波器看一下差分信号的眼图，虽然入门级示波器可能带宽不够，但至少能看出信号有没有明显的畸变。

还有一个实际经验：DSI 的差分线尽量不要和电源线、时钟线长距离平行走线，避免串扰。如果板子已经做好了，发现屏幕偶尔花屏，可以尝试降低 DSI 的传输速率，看是否改善。如果降速后改善明显，基本可以确定是信号完整性问题，需要从硬件侧优化。

4. 设备树里的 DSI 节点：每个参数背后的逻辑

4.1 控制器节点和屏幕节点：谁描述什么

在 Linux 设备树里，DSI 相关的配置通常分两部分：处理器端的 DSI 控制器节点，和屏幕端的 panel 节点。控制器节点描述的是处理器 DSI 控制器的能力，比如支持几个 lane、最大速率多少、寄存器基地址等；panel 节点描述的是屏幕本身的特性，比如分辨率、时序参数、初始化命令序列、电源和复位 GPIO 等。

这两部分通过一个叫“port”和“endpoint”的机制连接起来。控制器节点里有一个 port，panel 节点里也有一个 port，两个 endpoint 通过 phandle 互相引用，形成一条完整的显示链路。这个结构看起来有点绕，但它的好处是解耦：控制器驱动不需要知道具体接的是什么屏，panel 驱动也不需要知道接的是哪个处理器，双方只通过标准的 endpoint 接口通信。

配置的时候，最容易出错的地方是 endpoint 的 remote-endpoint 引用写反了，或者 panel 节点的 compatible 字符串和驱动里定义的不匹配。compatible 不匹配的话，panel 驱动根本不会加载，屏幕自然不亮。我通常会在内核启动日志里搜 panel 相关的信息，确认驱动有没有成功 probe。如果看到“panel driver not found”或者类似的报错，第一件事就是检查 compatible 字符串。

4.2 时序参数：porch、sync 和 clock 的计算方法

DSI 视频模式下的屏幕需要一组时序参数，包括水平前肩（HFP）、水平后肩（HBP）、水平同步宽度（HSW）、垂直前肩（VFP）、垂直后肩（VBP）、垂直同步宽度（VSW），以及像素时钟频率。这些参数在屏幕手册里通常以表格形式给出，单位可能是像素时钟周期数或者微秒。

这些参数的作用是告诉处理器：一帧图像里，有效像素区域之外还需要插入多少“空白”时间，用来给屏幕的行列驱动电路做同步。如果这些参数配错了，屏幕可能显示偏移、画面压缩或者完全不亮。计算像素时钟频率的公式是：像素时钟 = （水平总周期数 × 垂直总周期数 × 刷新率）。其中水平总周期数 = HFP + HBP + HSW + 水平有效像素数，垂直总周期数 = VFP + VBP + VSW + 垂直有效行数。

举个例子，一块 800×480 的屏，刷新率 60Hz，HFP=40，HBP=40，HSW=48，VFP=13，VBP=29，VSW=3。那么水平总周期 = 40+40+48+800 = 928，垂直总周期 = 13+29+3+480 = 525，像素时钟 = 928 × 525 × 60 ≈ 29.2MHz。这个频率要和 DSI 控制器的时钟配置匹配，如果差太多，屏幕可能不亮或者刷新率不对。

实际调试中，我建议先用屏幕手册里的典型值，不要自己随便改。如果手册只给了时序图，没有具体数值，可以用示波器量屏幕的像素时钟引脚（如果有的话），或者参考同分辨率同刷新率的其他屏幕参数。改时序参数时，每次只改一个，改完重新测试，这样才能定位到是哪个参数的问题。

4.3 初始化命令序列：命令模式屏幕的“开机密码”

命令模式的屏幕，上电后需要处理器发送一串初始化命令，屏幕才会开始正常工作。这串命令通常包括：退出睡眠模式、设置像素格式、设置时序、设置电源电压、打开显示等。不同厂商、不同型号的屏幕，命令序列完全不同，而且很多命令是厂商自定义的，手册里可能只给了命令值，没给详细解释。

这些命令在设备树里通常以字节数组的形式写在 panel 节点的 init-sequence 属性里。每条命令一般包含命令类型（比如 DCS 短写、DCS 长写）、命令码、参数和延时。写的时候要注意命令之间的延时，有些命令需要等待几毫秒到几十毫秒才能发下一条，如果延时不够，屏幕可能不响应。

我调过一块屏，初始化命令序列里有一条“退出睡眠”命令后面需要延时 120ms，但我一开始只写了 10ms，结果屏幕偶尔能亮偶尔不亮，很不稳定。后来把延时改成 120ms，就每次都亮了。所以初始化命令里的延时参数一定要严格按手册来，不能想当然地缩短。

另外，有些屏幕的初始化命令序列很长，几十条甚至上百条，手动写设备树很容易出错。我的做法是先用厂商提供的初始化代码或者参考驱动，把命令序列整理成表格，逐条核对命令码、参数和延时，确认无误后再写入设备树。写入后如果屏幕不亮，可以用逻辑分析仪抓 DSI 总线上的命令，看实际发出的命令和预期是否一致。

5. 从黑屏到点亮：一次完整的排查链路复盘

5.1 上电后完全无反应：先查电源和复位

假设你拿到一块新的 DSI 屏，接好线，上电，屏幕完全没反应，背光也不亮。这时候不要急着改代码，按下面的顺序查。

第一步，量电源。用万用表量屏幕连接器上每一路电源引脚的电压，对照手册确认电压值是否正确。如果某一路电压不对，先查供电电路，可能是 LDO 或 DC-DC 没使能，或者反馈电阻焊错了。

第二步，量复位引脚。屏幕的复位引脚在上电后应该有一个从低到高的跳变，如果一直保持低电平，屏幕就一直在复位状态。如果复位引脚一直低，查处理器的 GPIO 配置，确认复位 GPIO 有没有被正确初始化和拉高。

第三步，量背光使能和 PWM。如果背光使能引脚一直是低，背光驱动芯片不会工作。如果使能正常但背光还是不亮，量 PWM 引脚有没有波形，再量 LED 灯串两端的电压。

这三步做完，基本能确定是电源问题、复位问题还是背光问题。如果这三步都正常，但屏幕还是不亮，那才需要往 DSI 链路和驱动方向查。

5.2 背光亮但屏幕黑：DSI 链路没通的典型症状

背光亮了，说明电源和背光电路基本正常。屏幕黑，说明 DSI 链路没有正确传输图像数据。这时候按下面的顺序查。

先看内核日志。DSI 控制器驱动和 panel 驱动在 probe 阶段会打印一些信息，比如“DSI controller initialized”“panel probed successfully”之类的。如果 panel 驱动没有 probe，检查 compatible 字符串和设备树节点是否匹配。如果 probe 成功但屏幕还是黑，检查 DSI 控制器的时钟是否使能，lane 数是否和屏幕匹配。

然后用逻辑分析仪或示波器抓 DSI 总线。先抓时钟通道，看有没有时钟信号。如果没有时钟，说明 DSI 控制器没有开始传输，可能是控制器驱动没配好或者时钟源没使能。如果有时钟但数据通道没有信号，检查 lane 的映射和极性配置。

最后检查初始化命令。如果是命令模式屏幕，用逻辑分析仪抓 DSI 数据通道上的低功耗模式信号，看初始化命令有没有发出去。如果命令发出去了但屏幕没反应，可能是命令序列有误，或者命令之间的延时不够。

5.3 屏幕亮了但花屏、闪屏：时序和信号完整性问题

屏幕能亮但画面不对，通常比完全不亮更难查，因为问题可能出在多个地方。花屏可能是时序参数不对，闪屏可能是信号完整性问题，画面偏移可能是 porch 参数配错。

先检查时序参数。把屏幕手册里的时序参数和设备树里的配置逐项对比，确认没有抄错。特别注意单位，有些手册给的是微秒，有些给的是像素时钟周期数，搞混了会导致参数差很多。

然后检查 DSI 速率。如果 DSI 速率配得太高，超过了屏幕或 PCB 走线的能力，就会出现误码，导致花屏或闪屏。可以尝试降低 DSI 速率，看是否改善。如果降速后明显改善，说明是信号完整性问题，需要从硬件侧优化走线或连接器。

最后检查刷新率。刷新率太高可能导致屏幕来不及响应，太低可能导致闪烁。一般 60Hz 是安全值，如果屏幕支持 50Hz 到 70Hz，可以先设 60Hz 测试。

5.4 用日志和示波器定位问题的实操技巧

内核日志是排查 DSI 问题的第一手资料。我通常会用dmesg | grep -i dsi和dmesg | grep -i panel过滤出 DSI 和 panel 相关的日志。重点关注 probe 阶段的报错、时钟使能失败的提示、以及任何 timeout 相关的信息。

示波器方面，如果只有一台入门级示波器，可以先用它量电源、复位、背光使能和 PWM 这些低频信号。DSI 的高速差分信号需要带宽足够的示波器和差分探头，如果条件不具备，可以用逻辑分析仪抓低功耗模式的命令信号，至少能确认初始化命令有没有发出去。

还有一个实用技巧：很多处理器的 DSI 控制器驱动支持 debugfs 接口，可以在/sys/kernel/debug/下查看 DSI 控制器的状态，比如当前 lane 数、速率、时钟频率等。如果 debugfs 里的状态和设备树配置不一致，说明配置没有生效，需要检查设备树是否被正确加载。

6. 几个容易踩的坑和对应的绕行方案

6.1 lane 数和速率配错：屏幕不亮但日志无报错

lane 数和速率配错是 DSI 调试中最隐蔽的坑之一，因为很多时候内核日志不会报错，驱动 probe 也成功，但屏幕就是不亮。原因是 DSI 控制器和屏幕之间的链路参数不匹配，但控制器驱动可能没有做严格的校验。

比如屏幕支持 4 lane，但设备树里只配了 2 lane，控制器会按 2 lane 发送数据，屏幕收不到完整的数据包，自然不亮。反过来，屏幕只支持 2 lane，但设备树里配了 4 lane，控制器会尝试在 4 条 lane 上发送，但屏幕只监听 2 条，也会失败。

避免这个坑的方法很简单：拿到屏幕手册后，第一件事就是确认 lane 数和最大速率，然后在设备树里严格按手册配置。如果不确定，可以先按屏幕支持的最大 lane 数配置，再逐步降低测试。

6.2 初始化命令延时不够：偶发性不亮

初始化命令之间的延时不够，会导致屏幕偶发性不亮。这种问题的特点是：有时候能亮，有时候不亮，重启几次可能就好了。因为延时不够时，屏幕可能还没准备好接收下一条命令，但有时候又刚好赶上了，所以表现不稳定。

解决方法是严格按屏幕手册里的延时参数配置，不要自己缩短。如果手册没给延时，可以参考同类屏幕的经验值，一般退出睡眠模式后至少延时 120ms，其他命令之间至少延时 1ms 到 5ms。

6.3 设备树 compatible 不匹配：驱动根本没加载

compatible 字符串不匹配是新手最容易犯的错误之一。设备树里的 compatible 必须和 panel 驱动里定义的 of_device_id 表完全一致，包括大小写和连字符。如果写错了，panel 驱动不会 probe，屏幕自然不亮。

排查方法是看内核日志里有没有 panel 驱动 probe 的记录。如果没有，用cat /sys/firmware/devicetree/base/下的节点信息确认设备树里的 compatible 字符串，再和驱动源码里的定义对比。

6.4 背光极性和 PWM 频率：亮了但刺眼或闪烁

背光极性和 PWM 频率配错，会导致背光要么不亮，要么一直最亮（刺眼），要么闪烁。极性配错时，使能信号反相，背光驱动芯片可能一直处于关闭或全开状态。PWM 频率太低时，人眼能感觉到闪烁；频率太高时，背光驱动芯片可能响应不过来。

一般建议 PWM 频率设在 1kHz 到 20kHz 之间，极性根据背光驱动芯片的要求配置。如果不确定极性，可以先在设备树里配成高有效，测试后背光不亮再改成低有效。

7. 调完这块屏之后，我总结出的几条实用经验

调 DSI 屏这件事，说到底是一个“软硬结合”的活。你不能只盯着代码看，也不能只盯着硬件看，两边都要兼顾。我调了这么多块屏，最大的体会是：先把硬件侧确认清楚，再动软件，能省掉大量时间。电源、复位、背光、连接器，这四样东西确认无误之后，再去调设备树和驱动，成功率会高很多。

另一个体会是，屏幕手册一定要仔细看，尤其是时序参数和初始化命令部分。很多问题其实手册里都写了，只是我们没注意到。比如某个参数的典型值和最大值最小值，如果你用了最大值，可能在常温下能工作，但温度一变就不稳定了。所以尽量用典型值，留出余量。

还有一点，调试过程中一定要做记录。每次改了哪个参数，屏幕的表现有什么变化，都记下来。这样当问题出现时，你可以回溯到上一次正常的状态，快速定位是哪个改动引入的问题。我见过太多人改了一堆参数，最后不知道是哪个参数起了作用，也不知道是哪个参数导致了新问题。

最后，DSI 调试工具很重要。一台带宽足够的示波器、一个逻辑分析仪、一个能看内核日志的串口终端，这三样东西能帮你解决大部分问题。如果条件有限，至少要有串口终端和万用表，先把电源和日志这两块抓牢，也能解决不少问题。

这块屏点亮之后，下一步通常就是调显示效果了，比如色彩、伽马、刷新率。但那是另一个话题了，先把链路打通，后面的都好说。