Linux/TDA2EXEVM: No frame buffer on VSDK

Chih-Kuo Hsu

Part Number: TDA2EXEVM

Tool/software: Linux

Dear Sirs:

When using VSDK 03_03_00_00, I found there is no Linux video frame buffer inside it. And even when we enable the frame buffer inside the DRM the system is still no frame buffer. After we use the dra71-evm.dtb and set DISPLAY_ON_A15_LINUX from 0 to 1 in omapdrm/oma_drv.c , the VSDK can see the frame buffer device(/dev/fb0) in the Linux and it can use frame buffer to display. This is the way PSDK Linux Automotive used.

However, if using in this way, it will cause the VSDK assertion or the kernel crash in interrupt if we start the VSDK demo case later.

Just want to know: How we can use both VSDK and Linux frame buffer device to draw the GUI without any assertion or crash. Can you point me a way to do it?

Regards,

/ckhsu

over 7 years ago

0 Anand Balagopalakrishnan over 7 years ago

TI__Expert 5130 points

Hi Hsu,

The Display Subsystem HW block can be managed by only one core at any point. This can be A15/Linux or M4/BIOS.

On PSDK Linux Automotive, display is controlled from A15. On the other hand, VisionSDK configuration uses M4 based display. The use case and choice of SDK also determines the display management scheme.

Can you give details of your use case? We can suggest options based on your use case.

Regards,
Anand

0 Chih-Kuo Hsu over 7 years ago in reply to Anand Balagopalakrishnan

Expert 1885 points

Hi Anand:
Our usecase is that we use VisionSDK to construct the core APP, and the UI/Navigation can be exported to be coded by our customer. Just like the TI DM81xx IPNC/DVR SDK. The core app is controlled by SDK but the user can also use the Linux frame buffer to draw their UI.

This case can be done in DM81xx SDK but fail in VisionSDK.

If you have any idea or any way to realize this, please let me know how we can do it.

Regards,
/ckhsu

0 Anand Balagopalakrishnan over 7 years ago in reply to Chih-Kuo Hsu

TI__Expert 5130 points

Hi Ckhsu,

Linux framebuffer support is deprecated on Linux and is not supported on TI SoCs - specifically PSDK Linux Automotive. The Linux display management needs to be through DRM framework.

Can you provide some more details on what UI frameworks will be used by customer? Will the customer application directly write to Linux display interface? Or will a framework like Qt5 be used? Is there a compositor like Wayland/Weston used in the middle?

As mentioned earlier, display needs to be controlled from A15 (PSDKLA) or M4 (Vision-SDK). On the next VisionSDK release (3.04 planned for early Jul), we will introduce a framework that will allow A15 applications to display on M4 using the links & chains framework.

It will ease some of the questions but you will need to modify the application. It is not going to be a framebuffer interface.

We can provide more details after the release.

Regards,
Anand

0 Chih-Kuo Hsu over 7 years ago in reply to Anand Balagopalakrishnan

Expert 1885 points

Hi Anand:

We know the FB is deprecated, however the DRM can support simulate FB devices. Our customer they used to use the old FB device to draw their Navigation APP, but in VSDK 03_02_00_00 and VSDK 03_03_00_00, there are no such mechanism allow the A15 user APP to draw on the device. This is what our customer needs.

Our customer used their own framework, they only ask for FB device. And no matter Qt or Wayland/Weston they all need to control the display on A15. But in VSDK, it seems not working on this way.

And it is very glad to hear that in VSDK 03_04 will have mechanism to let A15 APP to draw and display on M4.

Anand, if we can ask our customer use Qt or Wayland/Weston service, how do you suggest we do the display part in VSDK 03_02 or 03_03?

Regards,

/ckhsu

0 Chih-Kuo Hsu over 7 years ago in reply to Anand Balagopalakrishnan

Expert 1885 points

Please see the below response.

0 Anand Balagopalakrishnan over 7 years ago in reply to Chih-Kuo Hsu

TI__Expert 5130 points

Hi ckhsu,

On VSDK 3.02 / 3.03, the links and chains framework can be used to send a display buffer from A15 to M4. This needs to be a custom interface with its own buffer management developed by customer. TI cannot support the changes required.

On VisionSDK 3.04, TI will provide a DRM interface which can be used to display to M4. We will also be integrating Weston to display using this interface. Hence, if the customer uses Wayland interface, it will work as-is and no changes will be required from customer side.

If customer uses a different framework, customer will need to use DRM APIs to display remotely. Essentially, the lower level display needs to be migrated from FB to DRM. However, we will not support framebuffer simulation / framebuffer interface on this DRM device.

If this is the path you want to go, you can plan for migration from FBDev to DRM in the next 1 month while waiting for VSDK 3.04 release. Please let us know if you need inputs on how to get started with DRM.

Regards,
Anand

0 Chih-Kuo Hsu over 7 years ago in reply to Anand Balagopalakrishnan

Expert 1885 points

Hi Anand:
This is really great to hear the news. Please give me any suggested DRM materials that can let me forward to our customer to migrate their FB code to DRM based code.

Regards,
/ckhsu

0 Anand Balagopalakrishnan over 7 years ago in reply to Chih-Kuo Hsu

TI__Expert 5130 points

Hi ckhsu,

The following thread provides you relevant pointers on DRM:
e2e.ti.com/.../370105

If you have any further questions on DRM, please start a new E2E thread.

Regards,
Anand

0 Anand Balagopalakrishnan over 7 years ago in reply to Anand Balagopalakrishnan

TI__Expert 5130 points

Hi CK Hsu,

One point to note. The DRM interface is going to be a proof of concept from TI. We are looking at this as a community collaboration model. It will not have full SDK level feature support.

Can you let us know what you use the VisionSDK for? Which is the main use case? HeadUnit / Surround View? I am trying to see if PSDK Linux Automotive is the better fit for your use case.

Does it matter to you whether the display runs from M4 or A15?

Regards,
Anand

0 Chih-Kuo Hsu over 7 years ago in reply to Anand Balagopalakrishnan

Expert 1885 points

Hi Anand:
We are doing the ADAS algorithm functions on the C66x DSP by using VLIB/IMGLIB like FCWS/LDW/PD, and our customer insists to create GUI by themselves because they also want to migrate their old navigation software on the A15. Therefore I don't feel the PSDK LA will fit this.

In the last post, you say the DRM draw will be a community collaboration model and it will not have full SDK level feature support. I just want to know will it still be able to release on July? And if release on July, where can I download it? From the VSDK download page or from PSDK LA download page?

If it is a community collaboration model, does this imply it already on the TI git tree? If yes, please let me know the URL. Thank you very much.

Regards,
/ckhsu

0 Anand Balagopalakrishnan over 7 years ago in reply to Chih-Kuo Hsu

TI__Expert 5130 points

Hi Ckhsu,

Thank you for the details. Since Navigation is typically a part of Infotainment / Head Unit ECU, will the ADAS algorithms also be a part of same ECU? If so, is this is a cockpit application? I am trying to understand if it's ADAS functionality added to Infotainment ECU or the other way round?

The delivery will be available as part of VisionSDK 3.04 download page. Subsequently, we will also publish the code sources on public Git tree. You can start development from July.

Regards,
Anand

0 Chih-Kuo Hsu over 7 years ago in reply to Anand Balagopalakrishnan

Expert 1885 points

Hi Anand:
The ADAS functions are not in the same ECU as the Navi APP. The Navi APP is on the A15 by our customer and we do not has its source to modify, and the ADAS algorithms are in the DSP. That's why I raise such a question to ask for drawing in A15.

And thanks to your information, I'll keep my eyes on the download page.

Regards,
/ckhsu

Processors

Processors forum

Linux/TDA2EXEVM: No frame buffer on VSDK