MIPI DSI Video Mode: real framebuffer never reaches panel display, only colorbar/test pattern works #830

New issue

Open

opened 2026-04-27 02:12:47 -04:00 by Yueze · 0 comments

Yueze commented

2026-04-27 02:12:47 -04:00

(Migrated from github.com)

Summary

Cannot get real framebuffer content displayed over MIPI DSI Video Mode on
LicheeRV Nano. Setup runs cleanly via SDK API, scaler/MAC/DPHY all report
correct state, IRQ handlers fire at expected rate, but panel never displays
the actual pixel data we push.

Related unresolved issues: #27, #52

Hardware

LicheeRV Nano (SG2002)
A 1-lane MIPI DSI AMOLED panel with internal GRAM (smartwatch-class)
Connected via standard MIPI DSI pins (CLK, D0)
Verified hardware: panel correctly displays content via DCS GRAM Write
(DCS 0x2C/0x3C in LP escape mode), so panel + wiring + power are fine

Software

Buildroot built from this repo (current main)
Kernel: linux 5.10 with soph_vo.ko + soph_mipi_tx.ko
Custom binary in middleware/v2/sample/ modeled after vdecvo doing:
- CVI_VB_SetConfig + CVI_VB_Init + CVI_SYS_Init
- SAMPLE_COMM_VO_StartVO (VO_OUTPUT_USER with custom timing)
- CVI_VO_ShowChn
- CVI_VB_CreatePool + CVI_VB_GetBlock + CVI_SYS_Mmap
- Fill RGB888 buffer with solid color, CVI_SYS_IonFlushCache
- Loop CVI_VO_SendFrame at 30fps
Panel init via /dev/mipi-tx ioctl: SET_DEV_CFG + SET_HS_SETTLE +
ENABLE + DCS init sequence
After init, panel is software-reset via DCS 0x01 SWRESET to ensure
clean state

What works

All SDK ioctls return success: SendFrame runs 2880+ frames with 0 errors
/proc/cvitek/vo: DevEn=Y, IntfType=MIPI, VideoEn=Y, ChnEn=Y, Show=Y
/proc/cvitek/mipi_tx: lane=1, output_mode=DSI_VIDEO, pixel_clk correct,
sync info matches what we set
DSI MAC reg 0x0A08A000 bit2=1 (HS Video Mode) stable
Scaler tgen_en=1, bw fail=0
Kernel printk traces (added for debug): vo_irq_handler fires at
disp_frame_end every ~31ms, _vo_hw_enque writes scaler DMA register
to VB block phys addr each frame
Path B (LP DCS GRAM write at chunk=40 via SET_CMD ioctl) works
perfectly — same panel displays full red

What doesn't work

Panel in Video Mode displays blank black, regardless of pixel content
in our DRAM buffer
Verified with dd that DRAM at scaler DMA addr contains the correct
pixel bytes
Tried multiple colors (RED, GREEN) — both result in black panel
Tried multiple video_mode_e values — see below

What we suspect

dev_cfg->video_mode field appears unused at the hardware register level:

Only 3 references in entire kernel: print, reject check, default reset
Kernel hardcodes if (video_mode != BURST_MODE) return -EINVAL
mipi_tx_get_combo_dev_cfg() always overwrites with BURST_MODE
No code path writes the value to any MIPI MAC register

This suggests the silicon may only support BURST_MODE, OR the
scaler-output-to-MAC-FIFO video data bridge requires an undocumented
register write that the SDK doesn't expose.

Questions

Does Sipeed have any internal example of MIPI DSI Video Mode displaying
real framebuffer content (not the BIST color bar that sample_dsi
--panel demonstrates) on this SoC family?
Is there a register that needs to be written to enable the
scaler-DISP-output → MAC-video-FIFO data path? The SDK source doesn't
show such a write; is there NDA/datasheet documentation?
Are AMOLED panels with internal GRAM (Command Mode native, but supporting
Video Mode receive) officially supported on this SoC? Or only video-mode
TFT-LCDs like HX8394/ST7701?
If the silicon does not support arbitrary MIPI panels in HS Video Mode
with real framebuffer, what is the recommended platform in your product
line that DOES support this for AMOLED panels?

Reproduction

Happy to share simplified reproduction steps + minimal C source if helpful.

Thank you for any guidance.

## Summary Cannot get real framebuffer content displayed over MIPI DSI Video Mode on LicheeRV Nano. Setup runs cleanly via SDK API, scaler/MAC/DPHY all report correct state, IRQ handlers fire at expected rate, but panel never displays the actual pixel data we push. Related unresolved issues: #27, #52 ## Hardware - LicheeRV Nano (SG2002) - A 1-lane MIPI DSI AMOLED panel with internal GRAM (smartwatch-class) - Connected via standard MIPI DSI pins (CLK, D0) - Verified hardware: panel correctly displays content via DCS GRAM Write (DCS 0x2C/0x3C in LP escape mode), so panel + wiring + power are fine ## Software - Buildroot built from this repo (current `main`) - Kernel: linux 5.10 with `soph_vo.ko` + `soph_mipi_tx.ko` - Custom binary in `middleware/v2/sample/` modeled after `vdecvo` doing: - `CVI_VB_SetConfig` + `CVI_VB_Init` + `CVI_SYS_Init` - `SAMPLE_COMM_VO_StartVO` (`VO_OUTPUT_USER` with custom timing) - `CVI_VO_ShowChn` - `CVI_VB_CreatePool` + `CVI_VB_GetBlock` + `CVI_SYS_Mmap` - Fill RGB888 buffer with solid color, `CVI_SYS_IonFlushCache` - Loop `CVI_VO_SendFrame` at 30fps - Panel init via `/dev/mipi-tx` ioctl: `SET_DEV_CFG` + `SET_HS_SETTLE` + `ENABLE` + DCS init sequence - After init, panel is software-reset via DCS 0x01 SWRESET to ensure clean state ## What works - All SDK ioctls return success: `SendFrame` runs 2880+ frames with 0 errors - `/proc/cvitek/vo`: `DevEn=Y, IntfType=MIPI, VideoEn=Y, ChnEn=Y, Show=Y` - `/proc/cvitek/mipi_tx`: lane=1, output_mode=DSI_VIDEO, pixel_clk correct, sync info matches what we set - DSI MAC reg `0x0A08A000` bit2=1 (HS Video Mode) stable - Scaler `tgen_en=1`, `bw fail=0` - Kernel printk traces (added for debug): `vo_irq_handler` fires at `disp_frame_end` every ~31ms, `_vo_hw_enque` writes scaler DMA register to VB block phys addr each frame - Path B (LP DCS GRAM write at chunk=40 via `SET_CMD` ioctl) works perfectly — same panel displays full red ## What doesn't work - Panel in Video Mode displays blank black, regardless of pixel content in our DRAM buffer - Verified with `dd` that DRAM at scaler DMA addr contains the correct pixel bytes - Tried multiple colors (RED, GREEN) — both result in black panel - Tried multiple `video_mode_e` values — see below ## What we suspect `dev_cfg->video_mode` field appears unused at the hardware register level: - Only 3 references in entire kernel: print, reject check, default reset - Kernel hardcodes `if (video_mode != BURST_MODE) return -EINVAL` - `mipi_tx_get_combo_dev_cfg()` always overwrites with `BURST_MODE` - No code path writes the value to any MIPI MAC register This suggests the silicon may only support BURST_MODE, OR the scaler-output-to-MAC-FIFO video data bridge requires an undocumented register write that the SDK doesn't expose. ## Questions 1. Does Sipeed have any internal example of MIPI DSI Video Mode displaying real framebuffer content (not the BIST color bar that `sample_dsi` --panel demonstrates) on this SoC family? 2. Is there a register that needs to be written to enable the scaler-DISP-output → MAC-video-FIFO data path? The SDK source doesn't show such a write; is there NDA/datasheet documentation? 3. Are AMOLED panels with internal GRAM (Command Mode native, but supporting Video Mode receive) officially supported on this SoC? Or only video-mode TFT-LCDs like HX8394/ST7701? 4. If the silicon does not support arbitrary MIPI panels in HS Video Mode with real framebuffer, what is the recommended platform in your product line that DOES support this for AMOLED panels? ## Reproduction Happy to share simplified reproduction steps + minimal C source if helpful. Thank you for any guidance.