RK3506 DRM虚拟FB开启后无显示输出

Question

在RK3506平台启用DRM框架下的虚拟Framebuffer（virtual FB）后，系统无法输出显示画面，屏幕黑屏或无信号输出。常见原因为虚拟FB未正确注册到DRM设备、缺少合适的显示时序配置（如timings或crtc初始化失败），或未绑定到HDMI/DP等显示接口驱动。此外，KMS（Kernel Mode Setting）未启用、fbdev模拟层冲突，或设备树中未正确配置display-subsystem节点，也会导致虚拟FB虽创建但无实际输出。需结合dmesg日志与DRM调试接口排查。

Answer 1

一、问题现象与初步定位

在RK3506平台上启用DRM（Direct Rendering Manager）框架下的虚拟Framebuffer（virtual FB）后，系统启动过程中屏幕黑屏或无信号输出。此问题常见于嵌入式Linux系统中首次引入虚拟显示设备的场景。

通过串口终端观察到内核已加载DRM核心模块，且dmesg日志显示drm: fb_helper initialization相关消息，但后续未见HDMI或DP接口驱动绑定成功的信息。

• 现象1：dmesg中出现“drm_fbdev_generic_setup: cannot create framebuffer”错误
• 现象2：/sys/class/drm/card0-*目录下缺少connector节点
• 现象3：DRM KMS未完成初始化，导致fbdev模拟层无法创建显存映射

二、DRM虚拟Framebuffer工作原理简述

DRM框架中的虚拟FB是一种不依赖物理显示控制器（如VOP）而由软件模拟的帧缓冲设备，常用于调试、容器化图形环境或无头服务器场景。

其核心流程如下：

1. DRM设备注册时调用drm_universal_plane_init()初始化CRTC和Plane
2. 通过drm_framebuffer_create()创建虚拟帧缓冲对象
3. 调用drm_mode_config_reset()构建mode_config结构体
4. 执行drm_fbdev_generic_setup()建立fbdev兼容层
5. 最终将虚拟FB关联至特定Connector（需手动配置或自动探测）

三、常见故障原因分类分析

类别	具体原因	典型日志特征
设备树配置	display-subsystem节点缺失或compatible错误	dmesg提示“no display-subsystem found”
KMS状态	KMS未启用或DRM_MODE_CONFIG_FLAGS属性未设置	“KMS not enabled, skipping fbdev emulation”
CRTC初始化	crtc->funcs为NULL或clock频率未配置	“failed to enable crtc”
时序配置	未提供valid timings或mode_valid回调拒绝模式	“mode not valid”, “rejected by mode_valid()”
接口绑定	HDMI/DP驱动未probe或connector未注册	“connector status: disconnected”
资源冲突	fbdev与DRM同时尝试控制同一framebuffer	“conflict detected with fbdev”

四、深度排查路径与调试手段

结合dmesg日志与DRM调试接口进行逐层验证：

# 查看DRM设备状态
ls /sys/class/drm/
cat /sys/kernel/debug/dri/0/state

# 启用DRM调试（需编译时开启CONFIG_DRM_DEBUG）
echo 0xffff > /sys/module/drm/parameters/debug

# 检查虚拟FB是否被创建
grep -i framebuffer dmesg | grep -v "release"
    

五、关键代码段与修复建议

确保在DRM driver probe函数中正确初始化虚拟CRTC并注册FB：

static int rockchip_drm_virtual_crtc_init(struct drm_device *dev)
{
    struct drm_crtc *crtc;
    int ret;

    crtc = kzalloc(sizeof(*crtc), GFP_KERNEL);
    if (!crtc)
        return -ENOMEM;

    drm_crtc_init_with_planes(dev, crtc, &virt_plane, NULL,
                              &rockchip_virtual_crtc_funcs, NULL);

    drm_mode_crtc_set_gamma_size(crtc, 256);
    drm_crtc_enable_color_mgmt(crtc, 0, false, 0);

    ret = drm_dev_register(dev, 0);
    if (ret)
        goto err_free;

    /* 必须调用此函数以支持fbdev模拟 */
    drm_fbdev_generic_setup(dev, 32);

    return 0;
err_free:
    kfree(crtc);
    return ret;
}
    

六、设备树配置示例与验证要点

RK3506平台应包含正确的display-subsystem定义：

/ {
        display-subsystem {
            compatible = "rockchip,display-subsystem";
            ports {
                #address-cells = <1>;
                #size-cells = <0>;

                port@0 {
                    reg = <0>;
                    /* 连接到虚拟encoder */
                };
            };
        };

        virtual_encoder: encoder {
            compatible = "simple-encoder";
            #video-port-cells = <1>;
        };
    };

七、Mermaid流程图：虚拟FB初始化失败诊断路径

graph TD
            A[系统黑屏] --> B{dmesg是否有DRM错误?}
            B -- 是 --> C[检查drm_fbdev_generic_setup失败原因]
            B -- 否 --> D[查看/sys/class/drm/card0-*]
            D --> E{存在connector?}
            E -- 无 --> F[确认display-subsystem设备树配置]
            E -- 有 --> G[检查connector status]
            G --> H{status=connected?}
            H -- 否 --> I[模拟HDMI热插拔事件]
            H -- 是 --> J[使用modetest工具强制设置mode]
            C --> K[检查CRTC funcs是否为空]
            K --> L[确认KMS已启用(CONFIG_DRM_KMS_CMA_HELPER)]

八、高级调试技巧与长期解决方案

对于复杂集成场景，推荐以下方法提升可维护性：

• 使用modetest -M rockchip -D 0手动测试mode设置
• 在用户空间通过libdrm调用drmModeAddFB()动态创建FB
• 启用CONFIG_DRM_DEBUG_UAPI捕捉ioctl异常
• 通过DRM_DEBUG_DRIVER宏打印底层硬件交互细节
• 构建最小化test driver分离虚拟FB逻辑与主控逻辑
• 利用ftrace跟踪drm_ioctl路径判断调用中断点
• 在initcall阶段注入虚拟connector避免late binding问题
• 考虑使用Zink或LLVMpipe作为上层渲染后端配合虚拟FB