dpug2d crashes, how to gain access to more debug?

[ycheng]

Hello NXP communities,

I am putting up my own board that uses an i.MX8 SoC. I am running i.MX Android Automotive OS software.

The board boots fine, but `SurfaceFlinger` keeps crashing and I found that the graphical library cannot initialize. The error I am referring to is attached below. Is there any more debug provided by NXP to tackle this issue?

mek_8q:/ # logcat -sd dpug2d

--------- beginning of main

01-01 00:00:39.646 494 559 E dpug2d : g2d_dev_open: open /dev/dma_heap/reserved-uncached failed, Permission denied

01-01 00:00:39.647 494 559 E dpug2d : g2d_open: Init Dpu Handle fail !

01-01 00:00:39.711 466 466 E dpug2d : g2d_open: Init Dpu Handle fail !

01-01 00:00:39.767 465 465 E dpug2d : g2d_open: Init Dpu Handle fail !

01-01 00:00:44.001 663 663 E dpug2d : g2d_open: Init Dpu Handle fail !

01-01 00:00:44.001 664 664 E dpug2d : g2d_open: Init Dpu Handle fail !

01-01 00:00:48.929 738 738 E dpug2d : g2d_open: Init Dpu Handle fail !

01-01 00:00:48.961 739 739 E dpug2d : g2d_open: Init Dpu Handle fail !

01-01 00:00:53.924 807 807 E dpug2d : g2d_open: Init Dpu Handle fail !

[Bio_TICFSL]

Hello,

The "Permission denied" error when trying to open /dev/dma_heap/reserved-uncached typically means your user or application doesn't have the necessary permissions to access that specific DMA heap device. This is a common issue with DMA heap devices

Here's a breakdown of potential causes and solutions:

1. Incorrect User Permissions:

• Problem:

  Your current user account might not be a member of the group that has access to the DMA heap devices.
• Solution:

  • Add user to the group: If necessary, add your user to the video group using the sudo usermod -a -G video your_username command.
  • Verify permissions: After adding the user to the group, check the permissions of the DMA heap device using ls -l /dev/dma_heap/reserved-uncached to ensure the group has the correct read and write access. 
  2. Kernel Configuration Issues:

• Problem: The kernel might be configured to rename or hide the DMA heap devices.
• Solution:
  • Check kernel configuration: If the device is renamed to "reserved" or "reserved-uncached" because the CONFIG_CMA_SIZE_MBYTES kernel configuration is too low, you might need to adjust this setting.
  • Recompile the kernel: If you need to change the kernel configuration, you'll likely need to recompile the kernel with the desired settings. 
    3. Software Issues:

• Problem:

  The software might be trying to access the device before it's ready or might have an error in its code.
• Solution:

  • Check for errors in the software: If you're using a library or application, check its error handling and see if there's a specific issue related to the DMA heap device.
  • Update or try a different version: If possible, try updating the software or trying a different version to see if the problem is resolved. 

4. Device Tree Issues:

• Problem:

  The device tree might be configured incorrectly, preventing access to the DMA heap device.
• Solution:

  • Check the device tree: If you're working with a custom device tree, ensure it's correctly configured for the DMA heap device and that the necessary properties are set.
  • Consult device documentation: Refer to the device documentation for instructions on configuring the device tree for the DMA heap device. 

In summary, the most common reasons for "Permission denied" when accessing /dev/dma_heap/reserved-uncached are incorrect user permissions or kernel configuration issues. Verifying user group membership and adjusting kernel settings related to the DMA heap devices are usually the first steps to resolve the issue. 

Regards

[ycheng]

Want to up this thread again, as I am hitting a dead-end without hearing from NXP team.

I understand it's really going into NXP's proprietary area and even if the answer is no I hope someone from the team can confirm it.

[Bio_TICFSL]

Hello,

If you are in a rush please enter a case

Regards

[ycheng]

Hi Bio_TICFSL,

Thank you for your prompt reply! I was able to resolve the permission denied on the dma heap device, but the dpu initialization still fails. Can we go back to the original question about gaining more debug on the g2d library?

Here's an updated log output.

Thanks!

mek_8q:/ # logcat -sd dpug2d
01-01 00:00:44.001 663 663 E dpug2d : g2d_open: Init Dpu Handle fail !
01-01 00:00:44.001 664 664 E dpug2d : g2d_open: Init Dpu Handle fail !
01-01 00:00:48.929 738 738 E dpug2d : g2d_open: Init Dpu Handle fail !
01-01 00:00:48.961 739 739 E dpug2d : g2d_open: Init Dpu Handle fail !
01-01 00:00:53.924 807 807 E dpug2d : g2d_open: Init Dpu Handle fail !