i.MX53, Linux 4.9 and Etnaviv

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX53, Linux 4.9 and Etnaviv

17,825 Views
Maddis
Contributor IV

We have i.MX53 based custom HW and so far we have been using 2.6 - series kernel since that was the last officially supported one.

I noticed that that Yocto 2.2 have support for i.MX53 and kernel 4.9 has the Etnaviv opensource graphics driver too.

So, I compiled our image for imx53qsb, that has 1024x768 lvds - display because it was the quickest way to get image up and running. I got system up and running and graphics are working. Only thing is that Wayland/Weston is sloooow. I don't think there is any acceleration going on. If I even try to move mouse the weston cpu-usage goes to 60-95% and cursor barely moves.

The HW is capable to handle the display because we have similar size(in resolution) display in our product and it works way faster with older kernel/drivers.

Have anyone have better luck with i.MX53 and Etnaviv?

Labels (4)
42 Replies

5,863 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Francesco,

Here is the patch I used against Buildroot mainline:

http://code.bulix.org/wpdqmx-1261086 

It allows me to run kmscube successfully on a imx53qsb board.

You still need to copy the GPU firmwares manually though.

I will work on upstreaming the kmscube bump and also the fix for the freedreno dependencies in Buildroot.

Let me know if it works for you as well.

Regards,

Fabio Estevam 

0 Kudos
Reply

5,863 Views
francesco_agost
Contributor I

Hi Fabio,

Thanks for your patch, I manually patched buildroot for kmscube, and added to my configuration 

BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_KMSRO=y
Now kmscube works fine! And QT finally sees the display with name UNKNOWN1. But all QT application QML/Widget that use platform eglfs throws following error:

[ 4124.912697] [drm:msm_ioctl_gem_submit] *ERROR* invalid cmdstream size: 0
[E] submit failed: -22 (Invalid argument) (msm_submit_sp_flush:292)
[E] bos[0]: handle=3, flags=5 (msm_dump_submit:91)
[E] cmd[0]: type=1, submit_idx=0, submit_offset=0, size=0 (msm_dump_submit:98)
Could not queue DRM page flip on screen UNKNOWN1 (Invalid argument)

just for a double check, I tried glmark2-es2-drm, all scenes is shown correctly on display, but on every scene, I can see the same error of the Qt application except the last row about DRM page flip:


[ 5191.207844] [drm:msm_ioctl_gem_submit] *ERROR* invalid cmdstream size: 0w:242)
[I] GMEM size: 0x00020000 (msm_pipe_new:243)
[E] submit failed: -22 (Invalid argument) (msm_submit_sp_flush:292)
[E] bos[0]: handle=12, flags=5 (msm_dump_submit:91)
[E] cmd[0]: type=1, submit_idx=0, submit_offset=0, size=0 (msm_dump_submit:98)

Maybe Adreno A201 gpu with freedreno require different parameter for Qt cross-compile? Or maybe I need to patch Qt configuration on buildroot like kmscube?

Regards,
Francesco Agostini 

0 Kudos
Reply

5,863 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Francesco,

Glad to know that kmscube works now :-)

For this DRM page flip issue you need to run the following line prior to running the Qt5 application:

# export QT_QPA_EGLFS_ALWAYS_SET_MODE=1

Let me know if it fixes the problem.

Regards,

Fabio Estevam

0 Kudos
Reply

5,863 Views
francesco_agost
Contributor I

Hi Fabio,

I rebuilt buildroot with Qt3D just for test the GPU, works fine, the only error that I can see by the driver is the same about ioclt. But the application works fine.

I tested:

- simple widget application :  OK
- simple QML application : OK
- simple opengl qml and 3D application : OK
- qml-planets example with anoter heavy qml application : Load but go out of out of memory. But is caused by limited hardware performance.

Seems that all work fine, with only the strange warning by kernel about ioclt, maybe can help developers. Thank you very much for your helpful support. It is incredible to see old SoC like i.MX51 working with a new kernel.

Regards,
Francesco Agostini 

0 Kudos
Reply

5,863 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Francesco,

Glad you got Qt5 applications to work with mainline kernel on i.MX51 :-)

In the meantime I fixed some kmscube issues upstream:

https://gitlab.freedesktop.org/mesa/kmscube/-/commits/master/ 

and also sent Buildroot patches to make use of the latest kmscube version:

https://github.com/buildroot/buildroot/commit/396191b1562072de11a702ffb9d61e7de9f40c04 

and

https://github.com/buildroot/buildroot/commit/f77b149a36b5dbaf51d7b8ea35752b6924d1b62d 

About your comment on the "UNKNOW" display, it may be probably due to the lack of an appropriate json file describing the panel topology of your board.

On imx6sabresd we do the following in Buildroot:

Running Qt5 Cinematic Demo:

# export QT_QPA_EGLFS_KMS_CONFIG=/root/sabresd.json
# export QT_QPA_EGLFS_ALWAYS_SET_MODE=1
# /usr/share/Qt5/CinematicExperience/Qt5_CinematicExperience

Where the json file is:

https://github.com/buildroot/buildroot/blob/master/board/freescale/imx6-sabresd/rootfs_overlay/root/... 

I am not sure about the ioctl error you mentioned. Could you please let me know the detailed steps to reproduce it with Buildroot?

Regards,

Fabio Estevam

0 Kudos
Reply

5,863 Views
francesco_agost
Contributor I

Hi Fabio,

Buildroot with Qt5 Cinex work fine! I can scroll the pages and see the contents without any problem. But if I try to create the json for configure the panel topology Qt can't see the display.

[I] Pipe Info: (msm_pipe_new:240)
[I] GPU-id: 201 (msm_pipe_new:241)
[I] Chip-id: 0x02000001 (msm_pipe_new:242)
[I] GMEM size: 0x00020000 (msm_pipe_new:243)

Cannot create window: no screens

I've only to learn how to create the appropriate file for my panel. In the end, I tried to see why the ioct go wrong. In the kernel, i found in the file msm_gem_submit.c at function int msm_ioctl_gem_submit the condition that blocks the ioclt. The condition is in the ioctl command validation area, probably receive a wrong parameter from ioctl (size = 0) and stop the ioctl to prevent unsafe driver condition. Maybe it is caused by wrong information about display in userspace, or incomplete display description. I'll try to understand why maybe a correct configuration with json file can solve all problems. I'll keep you up to date about new tests with different json.

Regards,
Francesco Agostini 

0 Kudos
Reply

5,863 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Francesco,

To create the json file you need the display name and resolution.

To get the display name you can see it under /sys/class/drm/ directory. This is what I get on a imx6q sabresd:

# ls /sys/class/drm/
card0-HDMI-A-1/ card0/ renderD128/
card0-LVDS-1/ card1/ version

Regards,

Fabio Estevam

0 Kudos
Reply

5,871 Views
burakaydin
Contributor II

Hi Chris,

How can we try i.MX53 with the configuration you have indicated? (5.4 kernel, mesa 19.3, opengl es 2.0 hw acceleration)? Is there a BSP support repo url for yocto? Or should we manually compile kernel and required libraries you mentioned?

Kind Regards,

Burak

0 Kudos
Reply

5,871 Views
cphealy1
Senior Contributor I

There is active work in the opensource community to support the GPU in the i.MX53.  The GPU IP in the i.MX53 ended up being what is now known as the Adreno series in the Qualcomm Snapdragon line of SoCs.  The GPU IP core in the i.MX53 is the Adreno 205 and support is being worked on with Freedreno.

If you are patient, there will soon be support for the GPU using the latest kernel.  (Support for pretty much everything else including the display controller, crypto, and HW video accelerator is already in place in the mainline kernel.)

0 Kudos
Reply

5,871 Views
alexberenshtein
Contributor III

Hi, Mr. Chris Healy.

I see 3 problems :

 - no support GPU in kernel ( ver 4.XXXX)  ;

- no support GPU in X-server ( last version );

- no support GPU in  z160 library ( last version ) ;

Tel me please , when it is possible to complete work .

This is Official release ?

Best regards.

0 Kudos
Reply

5,871 Views
cphealy1
Senior Contributor I

Hi Alex,

You are correct that none of these three things exist in a complete form yet in any official release.

Userspace support for the 3D GPU (AMD Z430 or Adreno A205) in the i.MX51 and i.MX53 is being developed in Mesa which will expose OpenGL ES 2.0 support.  Once this support lands in upstream Mesa, it should be possible to run Qt applications (for example) using the eglfs backend thus leveraging the 3D GPU.

Kernel support for the 3D GPU is pretty stagnant at the moment.  That said, it is possible to use the KGSL driver with minor modifications on top of the mainline kernel to support the 3D GPU.

For the AMD Z160, there is already userspace code for using it, but I know very little about it.  You can find it here:  xorg/driver/xf86-video-freedreno - X.Org driver for Adreno mobile GPUs   As you'll see, there is support for both the Z160 and Z180 in this codebase.

I'm working with some folks to get sufficient support added for the use cases I have which involve running Qt applications that leverage the 3D GPU.

Are there particular use cases you are looking to solve?

Regards,

Chris

0 Kudos
Reply

5,871 Views
alexberenshtein
Contributor III

Hi, Mr. Chris Healy.

Thank for cooperation.

Yes , I have few cases.

I build system with:

1. i.MX53;

2. Yocto - 2.4 ;

3. Kernel Ver. 4.xxx;

4. Qt Ver.  5.9.xx;

My system is works.  But i have problem with GPU module.

Graphics , with Qt application , run very slow.

I wait  , official release , from "NXP"  with GPU support  , or correct patches for my system .

Maybe you know, when will the official release ,  with GPU support ?

Best regards.

0 Kudos
Reply

5,871 Views
cphealy1
Senior Contributor I

Hi Alex,

i.MX51 and i.MX53 GPU support is landing in the upcoming 4.21 kernel.  The support that's landing in the 4.21 kernel has been successfully tested with Weston 5.0 and Qt 5.11.2.  The necessary userspace bits are still in work and should land in the next month or so with Mesa 19.0.  Based on comparison testing, performance in many use cases exceeds that of the original GPU driver.

With this GPU support, there is now full multimedia and graphics support in the mainline kernel for the i.MX51 and i.MX53.

5,871 Views
Maddis
Contributor IV

It this with open source driver or closed sourced binary driver like it currently is?

0 Kudos
Reply

5,871 Views
cphealy1
Senior Contributor I

Hi Mc Maddie,

I am referring to a fully open source driver for the GPU.  Full support has arrived and is upstream for the i.MX51 and i.MX53 now.  You will need the 5.0 kernel and Mesa 19.0.  With these, you will have full graphics and video support working with no NXP source or binary packages needed.  (The only exception is the need for the two GPU firmware blobs but they can be cherry picked out of the NXP BSPs.)

I'm using an i.MX51 with a 1280x768 display and under the right circumstances can achieve 60fps with our Qt GUI.

Regards,

Chris

0 Kudos
Reply

5,871 Views
cxbere
Contributor I

Hi Chris,

We have same problem (Our custom board has 2.6.35 kernel and we want to upgrade it to newer kernel version...) It was very good to hear Linux 5.0 and QT support. Are there any guide or documentation about take the graphics driver or yocto project which include Linux 5.0 and other things.

Best Regards,

Ercüment TÜRK

0 Kudos
Reply

5,871 Views
Maddis
Contributor IV

Hi,

I've been now spent few days this weeks compiling Linux 5.0 and mesa 19.x to imx53-qsb - development board and got it compiled and something displaying on screen as well. 

The problem is will with the freedreno - driver (I assume that's the opensource driver for the graphics for imx53). I'm not entirely sure if I got it enabled in Linux, I think it's enabled via the MSM - config option. And added freedreno also to mesa. Yet everything I try to start weston it complains about missing imx-drm - driver.

Does the freedreno need some device tree changes? And it seems that configuration help would be appreciated as well with those firmware blob handling.

0 Kudos
Reply

5,871 Views
cphealy1
Senior Contributor I

With the 5.0 kernel, the necessary devicetree patches are in place for the i.MX53 to support the "imageon/adreno" GPU.  The relevant kernel patch that added the necessary devicetree change is here:

kernel/git/stable/linux.git - Linux kernel stable tree 

Before getting into running with Wayland/Weston, I would suggest the following steps:

1) Make sure the driver for the GPU in the kernel is loading correctly.  (You should see some lines with the text msm and a200 in them that are successful.)

2) In userspace, try something simple like "kmscube" before moving to running Wayland/Weston.  If "kmscube" does not work, nothing more complex will work.

3) If "kmscube" does not work, please share the verbose log output from it as well as the output from "modetest -c".

Independent of the above, can you share your target use case for the graphical stack?  What do you plan on running on top of Weston?  What screen resolution and bit depth display are you working with?

0 Kudos
Reply

5,871 Views
Maddis
Contributor IV

Thanks, I'll get back to you if/when I run into problem or get it running.

Atm. I'm using imx53-qsb development board that has 1024x768 resolution screen @ 18-bit(I think) colors connected. If I don't remember too wrong that is the display it came with (It's been years since we got it). 

The plan is, once I get this working hopefully, to update the software of our imx53 based devices so that it's no longer that Linux 2.6 based system and run all kinds of apps on top of the Weston.

0 Kudos
Reply

5,871 Views
tarakpatel
Contributor I

Hi Chris,

Can you let us know how to get those firmware blob and which are they? As we also have custom imx53 board and we are running FreeScale/NXP Official BSP and would like to move from their to the latest kernel. We also require QT Support. As we have learnt from you that mainline kernel now officially support Full Multimedia Capabilities we would like to try and test it on our imx53 based board.

Thanks for your time and help,

Tarak Patel

0 Kudos
Reply

5,871 Views
Maddis
Contributor IV

Hi,

That sounds good! 

Are there any documentation how to take the graphics driver in use with i.MX53? Especially about the firmware blobs.

0 Kudos
Reply