Since my 'scope is too slow see the high-speed data transfers, I dropped a MIPI D-Phy into a handy FPGA+SoC dev. board with a RPi MIPI connector (Zybo-Z7-20) and made a home-brew protocol analyzer. There are some interesting differences between the output generated by the CM4IO board and the RP1.
The first major difference is the CM4 fills blanking regions mostly with zero-length NULL packets (x09 x00 x00 x09 xFF xFF) while the RP1 is using blanking packets (type x19). I doubt this is significant, but it's a difference.
With the horizontal timings recommended by the manufacturer (376/20/8/20) both the CM4 and the RP1 stay in high-speed mode for the bulk of the video frame, only returning to LP11 during the vertical interval. The video timings during the continuous high-speed transfer for the bulk of the video frame on both systems. I see x468 byte packets of type x3E (376 pixels of 888 RGB) being sent with reasonably appropriate amounts of blanking (either as type x09 null packets or x19 blanking packets) with H Sync Start/End packets positioned appropriately. There's a pretty significant difference in the vertical interval, however. The CM4 continues sending the sync interval pretty much as-is from the main video field region including the HFP (as null packets), H sync start, blanking (as blanking packet), H sync end, and HBP (as null packets). After 22 lines a V sync start is inserted followed by a V sync end on the next line, then another 20 lines of vertical back porch before the interface goes into high-speed mode to send the active region of the video frame.
On the RPi 5/RP1 things are much different. At the end of the active video region, the interface returns to LP11 however there is no EoTp packet (type x08) sent. The CM4 sends the EoTp packet at the end of each high-speed burst before going into low-power mode. My copy of the DSI specification (from 2010) says the generation of EoTp packets needs to be configurable to support "earlier DSI systems". Can the RP1 generate EoTp packets? The datasheet I have for the ST7701 indicates it can work with or without EoTp packets, but I suspect if we can't get the RP1 to generate EoTp packets we'll have to attempt to reverse-engineer more of the manufacturer provided init sequence and see if we can disable this on the ST7701 side. The text of the ST7701 data-sheet mentions a "DIS_EoTp_HS" bit but make no further mention of it in the control registers section (more mystery control bits, hooray!).
The other major difference between the CM4 and the RP1 is the horizontal front porch (HFP). In the vertical interval, after entering high-speed mode, the CM4 emits null packets for the HFP followed by sync start, blanking, sync end, and EoTp. The RP1 immediately emits the sync start, omitting any form of horizontal front porch. The rest of the burst looks as expected (blanking, sync end) although again there is no EoTp packet marking the end of the burst. I don't know enough about mapping DPI video timings onto MIPI to know if the lack of HFP in the burst transfer is significant.
The first major difference is the CM4 fills blanking regions mostly with zero-length NULL packets (x09 x00 x00 x09 xFF xFF) while the RP1 is using blanking packets (type x19). I doubt this is significant, but it's a difference.
With the horizontal timings recommended by the manufacturer (376/20/8/20) both the CM4 and the RP1 stay in high-speed mode for the bulk of the video frame, only returning to LP11 during the vertical interval. The video timings during the continuous high-speed transfer for the bulk of the video frame on both systems. I see x468 byte packets of type x3E (376 pixels of 888 RGB) being sent with reasonably appropriate amounts of blanking (either as type x09 null packets or x19 blanking packets) with H Sync Start/End packets positioned appropriately. There's a pretty significant difference in the vertical interval, however. The CM4 continues sending the sync interval pretty much as-is from the main video field region including the HFP (as null packets), H sync start, blanking (as blanking packet), H sync end, and HBP (as null packets). After 22 lines a V sync start is inserted followed by a V sync end on the next line, then another 20 lines of vertical back porch before the interface goes into high-speed mode to send the active region of the video frame.
On the RPi 5/RP1 things are much different. At the end of the active video region, the interface returns to LP11 however there is no EoTp packet (type x08) sent. The CM4 sends the EoTp packet at the end of each high-speed burst before going into low-power mode. My copy of the DSI specification (from 2010) says the generation of EoTp packets needs to be configurable to support "earlier DSI systems". Can the RP1 generate EoTp packets? The datasheet I have for the ST7701 indicates it can work with or without EoTp packets, but I suspect if we can't get the RP1 to generate EoTp packets we'll have to attempt to reverse-engineer more of the manufacturer provided init sequence and see if we can disable this on the ST7701 side. The text of the ST7701 data-sheet mentions a "DIS_EoTp_HS" bit but make no further mention of it in the control registers section (more mystery control bits, hooray!).
The other major difference between the CM4 and the RP1 is the horizontal front porch (HFP). In the vertical interval, after entering high-speed mode, the CM4 emits null packets for the HFP followed by sync start, blanking, sync end, and EoTp. The RP1 immediately emits the sync start, omitting any form of horizontal front porch. The rest of the burst looks as expected (blanking, sync end) although again there is no EoTp packet marking the end of the burst. I don't know enough about mapping DPI video timings onto MIPI to know if the lack of HFP in the burst transfer is significant.
Statistics: Posted by cdsteinkuehler — Sat Jul 27, 2024 7:35 pm
