RDK X5接收MIPI YUV422時，UYVY為何在DDR中變成YUYV？

jimlxr80 · 2026 年10 月 14 日 05:51

大家好，我在RDK X5上接收一個MIPI CSI-2設備的數據，配置如下：

C

datatype = 0x1E; // YUV422 8-bit，X5定義註釋為UYVY

format = EMODE_YUV422;

pack_mode = 1;

width = 1080;

height = 2912;

wstride = 2160;

實際抓到的DDR數據有以下現象：

圖像區按UYVY解析時顏色錯誤，按YUYV解析時顏色正常。
幀尾還包含16-bit depth和metadata數據，這兩部分都需要每2 byte交換後才能正確解析。
使用GMSL Pixel Mode和Tunnel Mode時，結果相同，因此看起來不像是SerDes Pixel Mode造成。
搜索X5代碼，只找到大量.pack_mode = 1，沒有找到pack_mode的具體定義，也沒有找到UYVY/YUYV順序選項。

想請教：

X5 VIN收到DT=0x1E後，是否會把UYVY自動重排成YUYV寫入DDR？
.pack_mode = 1的具體含義是什麼？是否會導致相鄰byte交換？
有沒有方法讓VIN把MIPI payload按原始byte order直接寫入DDR，不進行重排？

謝謝！

瓜仔 · 2026 年10 月 14 日 06:05

先給結論：pack_mode = 1 不是 UYVY/YUYV 的順序選擇位，也不會交換相鄰 byte。X5 官方對 YUV sensor 的說明是：format = 0x1E 搭配 pack_mode = 1 代表 packed（逐像素交錯）YUV422、stride 填 2×width；format = 0x1E 搭配 pack_mode = 2 是 semi-planar 的 YUV422SP（NV16）、stride 填 1×width；format = 0x18 + pack_mode = 2 是 YUV420SP（NV12）。你的 width 1080、wstride 2160 正是 pack_mode=1 的 packed 配置。VIN 結構體表格把 pack_mode 標成「預留」，實際用法以 Camera 調試 FAQ 的「如何配置 yuv sensor ?」為準；欄位表見 VIN API。

第二，官方文件沒有描述 VIN 會對 MIPI payload 做 byte 重排，也沒有能讓 VIN 按原始 byte order 直寫的選項；DT = 0x1E 只是「YUV422 8-bit」這個型別，payload 內 Y/U/V 的先後由 TX 端決定。要判斷 DDR 的 YUYV 是來源本身如此、還是中間被重排，得先確認 TX 實際輸出順序（查 sensor/serializer 是否有 YUV 順序寄存器，或送已知 pattern 比對）。RX 側目前只能看到下發的配置：

cat /sys/class/vps/mipi_host0/status/cfg   # mipi_host0 換成實際使用的 RX 端口

這是 init 時下發的設定，不等於實際收到什麼 datatype 的證明。

第三，圖像區按 YUYV 解析正常，目前只能說明 DDR 裡的圖像資料可以按 YUYV422 解讀；究竟是來源本來就送 YUYV，還是 VIN/SerDes 做了重排，要等 TX 輸出順序確認後才能判斷。若幀尾那兩段不是 0x1E 圖像資料，需按它們實際的 datatype 與打包格式解析，不要套用 0x1E 的解讀。

方便的話說一下 TX 端是哪顆 sensor/serializer、它的 datasheet 有沒有 YUV 順序可調的寄存器，這點直接決定要不要在 VIN 側找解法。

jimlxr80 · 2026 年10 月 14 日 06:19

謝謝解答，明白了，pack_mode=1只是packed YUV422，不是UYVY/YUYV選擇或byte swap。

補充TX端是Libra2000 → MAX96717 → MAX96724 → X5。我已分別測過GMSL Pixel Mode和Tunnel Mode，DDR結果相同：

Plain Text

圖像按YUYV解析正常；

幀尾disparity和metadata需swap16後正常。

兩張圖像、disparity和metadata目前都封裝在同一個DT=0x1E、1080×2912×2的長幀中。

我再向Libra2000 vendor確認TX端的YUV順序和16-bit endian。請問X5側除了送已知pattern比對，是否還有方法查看VIN接收前後的原始payload byte order？

瓜仔 · 2026 年10 月 14 日 06:27

目前官方資料裡，沒有提供在 X5 側讀取 MIPI PHY／VIN 之前原始 payload 的方法：X5 SDK 只給了 mipi_host 的 sysfs 配置與狀態節點（下發配置、運行狀態、寄存器 dump）。而官方對 YUV sensor 的說明是資料進 MIPI 後由 SIF 直接 dump 到 DDR、不經 ISP，所以可觀測的最早一份資料就是 SIF/VIN 寫進 DDR 的 buffer，也就是你現在抓的那份；要確認 lane 上真正的 bytes，得外接 MIPI analyzer 或差分示波器抓。

X5 側能查的只有「下發配置與 host 狀態」，不會顯示 byte order：

# host 編號換成實際接入的那一路（0~3）
cat /sys/class/vps/mipi_host0/status/cfg     # init 時下發的 mipi 配置
cat /sys/class/vps/mipi_host0/status/info    # 目前運行狀態
cat /sys/class/vps/mipi_host0/status/regs    # mipi host 寄存器 dump

另外文件對 0x1E 只定義了 packed（pack_mode=1、stride 2×width）與 YUV422SP/NV16（pack_mode=2、stride 1×width）兩種排版，沒有 UYVY/YUYV 選擇或 byte swap 欄位。因此 X5 這端沒有可直接切換的位序選項；MAX96717／MAX96724 的 pipe 與資料格式暫存器回讀（走板端 i2c）可以幫你確認兩種模式下這一段的配置是否一致，但它只能證明配置層面，不能單獨證明 SerDes 沒有做位元組重排。配合你已測出 pixel mode 與 tunnel mode 的 DDR 結果相同，方向可以收斂到 TX 端定義，或仍用可區分的 pattern 驗證。

想在 VIN 這一級用官方工具再抓一份對照，板端 /app/platform_samples/sample_vin/get_vin_data dump 的確實就是 VIN/SIF 輸出；但它是按 vp_sensor 既有的 sensor 清單選配置，只在板端已有對應 sensor 配置／驅動時可用，Libra2000 這類自定義源若沒加入對應配置無法直接跑，那就以你現有 VIN 配置的 DDR dump 為基準。

參考：X5 SDK 的 Camera 調試 FAQ（YUV sensor 配置、mipi_host 狀態與寄存器查看）、sample_vin 使用說明。

CanNyCat · 2026 年10 月 14 日 06:33

目前公开资料里没查到 VIN 前原始 CSI-2 payload 的导出接口。X5 能抓的是 SIF/VIN 写入 DDR 后的 buffer；mipi_host 的状态、配置和寄存器 dump 不能当作 payload 抓包。

另外，官方 FAQ 把 0x1E + pack_mode=1 标为 YUYV422，但没说明是否做字节交换，暂时不能认定 X5 自动 swap。要看 MAX96724 出口的真实字节，需要带 CSI-2 解码的抓包工具；这类混合帧的底层适配，建议通过 DGP 对接专业 Camera 工程师核查。

官方说明：https://developer.d-robotics.cc/x5_sdk_doc/multimedia_development/isp_tuning_guide/Camera_sensor_FAQ.html

DGP：https://developer.d-robotics.cc/dgp

瓜仔 · 2026 年10 月 14 日 06:45

X5 側沒有讀取 VIN/PHY 之前 CSI-2 原始 payload 的介面，能看到的最早一點就是 SIF 寫進 DDR 的 buffer。

官方 FAQ 列的 HOST(RX) 觀測手段只有運行狀態與配置：cat /sys/class/vps/mipi_host0/status/info、.../status/cfg、.../status/regs（mipi host 號按實際替換）。這些是配置和寄存器回讀，不是封包內容，不能用來判定 UYVY/YUYV。
VIN 之後能拿到原始資料的是 SIF 輸出：HB_VIN_GetDevFrame(devId, 0, ...)（SIF 的 chn 0），前提是配置走 sif-offline-isp 或 sif-online-ddr 這類可 dump raw 的場景，並已有可用的 sensor 配置。官方對 YUV sensor 的說明就是 MIPI 進來後由 SIF 直寫 DDR、跳過 ISP。
所以用已知 pattern 比對 SIF dump，只能判斷這份 byte 在 SIF 之後是否已被重排，無法區分是 TX、SerDes 還是 SIF 造成；要看 MAX96724 出口的實際 byte，仍需帶 CSI-2 解碼的抓包工具。

另外補一句官方口徑：FAQ 對 0x1E 只列 packed（pack_mode=1，stride 2×width）和 NV16（pack_mode=2，stride 1×width）兩種，沒有 UYVY/YUYV 或 byte swap 選項。

建議下一步：先 dump 一份 SIF raw，和 TX 端送的已知 pattern 逐 byte 比對圖像區與幀尾 16-bit 資料，確認 swap 是在進 SIF 前就發生；同時向 Libra2000 / MAX96724 端確認該 pipe 的 YUV 順序與 16-bit endian 定義。參考：Camera 調試 FAQ、視頻輸入 API。