etnaviv on armstoneA9r2 with fsimx6_etnaviv_defconfig and armstonea9r2dl.dtb from fsimx6-B2024.04

    Hello,

    I wanted to try the open source etnaviv driver for the i.MX GPU. I found that F&S made an modifed defconfig (fsimx6_etnaviv_defconfig) to enable this in the kernel from fsimx6-B2024.04. However: When i start the kernel on my armstoneA9r2 board, always the closed source vivante driver ("galcore" in the kernel log) is loaded. As device tree I use armstonea9r2dl.dtb from the same BSP. What am I missing, or is it not even possible at all?


    Greetings,

    André Wagner

    I made some progress.


    Following things i could fix:

    1. Deactivate the Vivante driver in the fsimx6_etnaviv_defconfig. A activated vivante driver blocks the etnaviv driver from loadings since it loads before.

    2. Adjust the device from Vivante style device tree entry to Etnaviv style entry.

    3. I got the etnaviv DRM/DRI userspace installed, which were correctly loaded by my Qt5 app


    The problem it got now its that no screens where detected by the DRM subsystem. What can be wrong there? I've read that is could be a problem of the LVDS Device Bridge drivers, but I've read that this drivers needs to work, for having a proper 3d accellerated setup (either with vivante or etnaviv).


    The kernel log:


    imx sema4 driver is registered.

    imx-ipuv3 2400000.ipu: IPUv3H probed

    imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)

    imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)

    imx-drm display-subsystem: failed to bind ldb (ops imx_ldb_ops): -2

    imx-drm display-subsystem: master bind failed: -2

    imx-ipuv3-crtc: probe of imx-ipuv3-crtc.3 failed with error -2

    etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)

    etnaviv-gpu 130000.gpu: model: GC880, revision: 5106

    [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0



    My patches so far:

    Hello,


    We added an example on how to use the etnaviv driver with an efusa9 some releases ago.

    Hower, this might differ a little, depending on which display and board type is used.


    to activate the etnaviv driver, there are several steps, that need to be done.


    1. Use the fsimx6_etnaviv_defconfig

    https://github.com/FSEmbedded/…/fsimx6_etnaviv_defconfig

    2. Make some adjustments to the Device Tree: See

    https://github.com/FSEmbedded/…t/dts/efusa9q-etnaviv.dts

    3. Make some adjustments to the Buildroot defconfig

    https://github.com/FSEmbedded/…iv_experimental_defconfig


    However the Buildroot has not been fully tested with the B2024.04 release, so there could be some issues here.

    Mostly, you need to make sure that the Mesa driver has the etnaviv config activated.


    Your log indicates, that the main issue seems to be your display.

    There is an example in the device tree on how to use a LVDS display. Maybe you can try to adapt this to your Device Tree?

    https://github.com/FSEmbedded/…s/efusa9q-etnaviv.dts#L52

    https://github.com/FSEmbedded/…s/efusa9q-etnaviv.dts#L98


    Your F&S Support Team

    Thanks for the help

    I just found efus9q-etnaviv.dts by myself in the morning and yes I am using the fsimx6_etnaviv_defconfig. According to the efus device tree I made a armstonea9r2dl-etnaviv.dts device tree with my display settings (see attachment with a txt suffix since dts suffix is not supported).


    Now it looks already better, the display at the LVDS Device Bridge seems to be initialized.

    But where I expect imx-drm display-subsystem: master bind

    I got a kernel panic (see attachment kernel_panic.txt).


    Do you have a guess what else can be wrong?










    Thank you very much for your patch!


    I integrated your patch (attachment: drm_core_backport_from_fs.patch), extra i needed to chance the output port of the lvds device bridge from port@4 to port@2, all other settings i could take from efus9q-etnaviv.dts (attachment: panel_lvds_setting). Upfront i already changed the devicetree from vivante to etnaviv style and deactivated vivante (attachment: activate_etnaviv_driver.patch).


    To make it short:

    IT WORKS!


    My Qt-Application renders via eglfs-backed via drm via etnaviv to the lvds output where my display is connected.


    Thank you very much for your support!


    PS: Do you think that the changes we did for supporting etnaviv + drm will be present in a future release of the BSP?

    Thats hard to say, because NXP made some hard changes to the code for the vivante driver, which prevent the etnaviv driver to work.


    However we are working on a linux mainline version for fsimx6, whiteout the imx changes, which should also be easier to update.

    The etnaviv driver should work out of the box there.


    Your F&S Support Team

    Hello,


    I had to discover that my Qt application was falling back to framebuffer support but i didn't realize until now.

    The output while trying to start is:

    qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_kms")

    qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_kms")

    qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_kms"

    qt.qpa.eglfs.kms: Loading KMS setup from "/etc/eglfs_hdmi.json"

    qt.qpa.eglfs.kms: Requested configuration (some settings may be ignored):

         headless: false

         hwcursor: false

         pbuffers: true

         separateScreens: false

         virtualDesktopLayout: 0

         outputs: QMap(("LVDS-1", QMap(("mode", QVariant(QString, "800x600"))("name", QVariant(QString, "LVDS-1")))))

    qt.qpa.eglfs.kms: New DRM/KMS via GBM integration created

    qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_kms"

    qt.qpa.eglfs.kms: platformInit: Opening DRM device

    qt.qpa.eglfs.kms: GBM: Using DRM device "/dev/dri/card1" specified in config file

    qt.qpa.eglfs.kms: Using backend-provided DRM device /dev/dri/card1

    qt.qpa.eglfs.kms: Creating GBM device for file descriptor 4 obtained from "/dev/dri/card1"

    qt.qpa.eglfs.kms: Initalizing event reader for device 0x1a51248 fd 4

    qt.qpa.eglfs.kms: Querying EGLDisplay

    qt.qpa.eglfs.kms: Event reader thread: entering event loop

    qt.qpa.eglfs.kms: No eglGetPlatformDisplay for GBM, falling back to eglGetDisplay

    Could not open egl display

    Aborted



    I did already extended debugging and following points i think I understood and checked:

    1. the etnaviv kernel driver exposes the Vivante GPU as /dev/dri/card0 and /dev/dri/renderD128
    2. the imx-drm kernel driver exposes the IPU as /dev/dri/card1
    3. kms works on /dev/dri/card1 since I can see output with modetest
    4. the LVDS output is attached to the IPU so to /dev/dri/card1, modetest shows also that
    5. the Qt5 eglfs backend triggers the MESA-LOADER looks all /dev/dri/card* to find a device which supports modesetting
    6. the only device which supports modesetting is /dev/dri/card1 since /dev/dri/card0 has no screens/outputs
    7. via libdrm the MESA-LOADER finds that /dev/dri/card1 is a device which runs on imx-drm kernel driver
    8. since the kernel drivers name is imx-drm the MESA-LOADER loads imx-drm_dri
    9. Problem is not specific to qt, since kmscube ("failed to initialize EGL") and weston-simple-dmabuf-egl ("../clients/simple-dmabuf-egl.c:1375: create_display: Assertion `display->display' failed." also fail.
    10. In /sys/kernel/debug/dma_buf/bufinfo i should see something like exp_name and imp_name + etnaviv and imx-drm. But right now it shows only "Total 0 objects, 0 bytes", so handling from etnaviv to imx-drm does not work at all.
    11. Ubuntu's mesa build uses the mega mesa driver so all drivers are include in one shared object. Which drivers are contained i can see with strings etnaviv_dri.so | grep __driDriverGetExtensions. Since i see __driDriverGetExtensions_etnaviv and __driDriverGetExtensions_imx_drm the necessary driver / stub driver is included. The drivers filename needs to correspond <kernel driver name >_dri.so
    12. the mesa mega driver picks /dev/dri/card1, sees that there is no real driver behind and redirects to KMSRO /dev/dri/renderD128.
    13. /dev/dri/card1 and /dev/dri/renderD128 should share a buffer via GBM (userspace)/PRIME (kernelspace)

    Further ideas what else i can check?


    Thanks in advance!

    Hello,


    you do not build Weston, right? Could you try to build the mainline version and add it to your image and test if it works there?


    Please make sure to add

    Code
    1. BR2_PACKAGE_WESTON=y
    2. BR2_PACKAGE_WESTON_DRM=y
    3. BR2_PACKAGE_WESTON_DEFAULT_DRM=y

    and remove

    Code
    1. BR2_PACKAGE_WESTON_IMX_FBDEV=y

    from your defconfig, and also remove


    Code
    1. use-g2d=1

    form your weston.ini.


    Also make sure that these mesa configs are active:

    Code
    1. BR2_PACKAGE_MESA3D=y
    2. BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y
    3. BR2_PACKAGE_MESA3D_OPENGL_ES=y
    4. BR2_PACKAGE_MESA3D_OPENGL_EGL=y



    Your F&S Support Team