The Cortex-R in the MCU Domain of AM62P

Other Parts Discussed in Thread: AM62P

1. Theoretically, the Cortex-R in the MCU Domain of AM62P should be able to control the screen display just like the Cortex-R in the Wakeup Domain, but there are no current examples. Does this mean that users need to manually port it? Is this understanding correct?
2. Currently, all the DSS-related demos, after preparing the buffer to be displayed, send the display through FVID2 instead of using a simple framebuffer or the commonly used DRM in the Linux system. Is this to support the data stream from the camera at the same time?
3. The Video pipeline of DSS is visible to both the Main Domain and the WKUP Domain. When using the Cortex-R core to control the screen display, do we need to disable the device tree description related to the display in the Linux dts?

  • Hi,

    1. Correct, theoretically DSS can be controlled from MCU R5 as well, but we will not be supporting this usecase and customer will have to port it manually.
    2. Seems you are mixing RTOS and Linux. We do not have a 'simple-framebuffer' or DRM framework concept within RTOS, though conceptually in RTOS, there are 2 buffers, one of which can be used to update the frame while the other is being used to stream data out. There is no correlation with camera being used or not. You just need to populate those display buffers with data either from camera stream or otherwise.
    3. Post U-Boot, in kernel stage, both cores will have control over different pipelines within same DSS. You'll need to define who controls what. You may check the display-share example and https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62p5-sk-dss-shared-mode.dtso?h=ti-linux-6.12.y