i.MX8QXP Parallel RGB not working

[philippe_schenk]

Hello

We are developing a SoM with the i.MX8QXP processor called Colibri iMX8QXP. A key feature of this SoM is to provide a parallel RGB interface. Our BSP is currently basing on the imx_4.14.98_2.3.0 release provided on Codeaurora. We got this interface running by multiple patches from Oleksandr you can find under this link.

When running glmark2-es2-wayland we now stumbled on a bug that is causing the parallel rgb interface to get out of sync and the picture on the display is jumping in horizontal axis (see the attached video).

We unfortunately do not have a parallel RGB display for the MEK to try this out on NXPs hardware. However I tried the following:
I downloaded the binary image 'L4.14.98_2.3.0_images_MX8QXPMEK' I flashed the sdcard. On the b0 silicon this of course doesn't boot as the image is built for c0 silicon. I then compiled SCFW and then the whole boot-container for b0 silicon and replaced that boot-container which boots fine afterwards.
I switched devicetree in U-Boot with 'setenv fdt_file fsl-imx8qxp-mek-lcdif.dtb'. The kernel is first off booting but then resulting in a kernel-panic:

[    1.896649] BUG: scheduling while atomic: swapper/0/0/0x00010002
[    1.902662] Modules linked in:
[    1.905722] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.98-2.3.0+g0f549d8c4d5e #1
[    1.913469] Hardware name: Freescale i.MX8QXP MEK (DT)
[    1.918610] Call trace:
[    1.921064] [<ffff000008089c48>] dump_backtrace+0x0/0x3c8
[    1.926469] [<ffff00000808a024>] show_stack+0x14/0x20
[    1.931524] [<ffff000008daf640>] dump_stack+0x9c/0xbc
[    1.936582] [<ffff0000080f3bbc>] __schedule_bug+0x4c/0x70
[    1.941984] [<ffff000008dc3bb8>] __schedule+0x558/0x5e8
[    1.947212] [<ffff000008dc3c80>] schedule+0x38/0xa0
[    1.952095] [<ffff000008dc4160>] schedule_preempt_disabled+0x20/0x38
[    1.958454] [<ffff000008dc5190>] __mutex_lock.isra.0+0x510/0x530
[    1.964466] [<ffff000008dc51c0>] __mutex_lock_slowpath+0x10/0x18
[    1.970477] [<ffff000008dc51f8>] mutex_lock+0x30/0x38
[    1.975536] [<ffff00000855d9e0>] clk_prepare_lock+0x40/0xa0
[    1.981111] [<ffff00000855f424>] clk_prepare+0x1c/0x40
[    1.986256] [<ffff0000086d540c>] mxsfb_irq_handler+0x1c/0x90
[    1.991920] [<ffff00000811ca74>] __handle_irq_event_percpu+0x5c/0x148
[    1.998364] [<ffff00000811cb7c>] handle_irq_event_percpu+0x1c/0x58
[    2.004549] [<ffff00000811cc00>] handle_irq_event+0x48/0x78
[    2.010128] [<ffff000008120a00>] handle_fasteoi_irq+0xa8/0x180
[    2.015965] [<ffff00000811bb94>] generic_handle_irq+0x24/0x38
[    2.021718] [<ffff00000811c214>] __handle_domain_irq+0x5c/0xb8
[    2.027553] [<ffff000008081960>] gic_handle_irq+0x78/0x174
[    2.033043] Exception stack(0xffff000009523dd0 to 0xffff000009523f10)
[    2.039492] 3dc0:                                   0000000000000000 ffff80083ff1ed80
[    2.047327] 3de0: 0000000000000001 ffff000009528e10 00000000020c49ba 00ffffffffffffff
[    2.055165] 3e00: 000000001181cbf2 0000000000000000 0000000000000002 ffff000009523e90
[    2.062999] 3e20: 0000000000000980 0000000000000000 0000000000000001 0000000000000000
[    2.070837] 3e40: 0000000000000001 ffffffffffffffff 0000000000000480 0000000000000038
[    2.078671] 3e60: 0000000000000001 00000000000000be 0000000000000002 ffff0000096d0000
[    2.086508] 3e80: ffff000009528b80 ffff80083ffff500 ffff00000948d028 00000000fd6c04c8
[    2.094344] 3ea0: 00000000ffefbe28 0000000000000000 00000000815e0018 ffff000009523f10
[    2.102180] 3ec0: ffff000008142a70 ffff000009523f10 ffff000008142a74 0000000060000045
[    2.110016] 3ee0: 00000000fd6c04c8 00000000ffefbe28 ffffffffffffffff ffff000008142a4c
[    2.117850] 3f00: ffff000009523f10 ffff000008142a74
[    2.122733] [<ffff000008083230>] el1_irq+0xb0/0x124
[    2.127618] [<ffff000008142a74>] tick_nohz_idle_enter+0x3c/0x50
[    2.133544] [<ffff00000810d790>] do_idle+0x10/0x1e0
[    2.138423] [<ffff00000810daf8>] cpu_startup_entry+0x20/0x28
[    2.144088] [<ffff000008dc1f18>] rest_init+0xd0/0xe0
[    2.149061] [<ffff0000093e0b70>] start_kernel+0x398/0x3ac
[    2.154556] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    2.162651] Mem abort info:
[    2.165440]   Exception class = IABT (current EL), IL = 32 bits
[    2.171354]   SET = 0, FnV = 0
[    2.174404]   EA = 0, S1PTW = 0
[    2.177541] [0000000000000000] user address but active_mm is swapper
[    2.183893] Internal error: Oops: 86000004 [#1] PREEMPT SMP
[    2.189468] Modules linked in:
[    2.192532] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W       4.14.98-2.3.0+g0f549d8c4d5e #1
[    2.201492] Hardware name: Freescale i.MX8QXP MEK (DT)
[    2.206627] task: ffff000009532580 task.stack: ffff000009520000
[    2.212546] PC is at 0x0
[    2.215079] LR is at 0x0
[    2.217608] pc : [<0000000000000000>] lr : [<0000000000000000>] pstate: 000001c5
[    2.225000] sp : ffff000008003ce0
[    2.228310] x29: 00000000ffff179f x28: ffff000009532580 
[    2.233626] x27: 0000000000000001 x26: 0000000000000000 
[    2.238944] x25: ffff000009532b30 x24: ffff000008dc3c80 
[    2.244260] x23: ffff00000950c000 x22: ffff000009532580 
[    2.249577] x21: ffff00000954afd8 x20: ffff000009528e78 
[    2.254893] x19: 0000000000000001 x18: 0000000000000010 
[    2.260210] x17: 0000000000000038 x16: 0000000000000480 
[    2.265527] x15: ffffffffffffffff x14: 0000000000000000 
[    2.270844] x13: 0000000000000000 x12: 0000000000000001 
[    2.276160] x11: 0000000000000000 x10: 0000000000000980 
[    2.281477] x9 : ffff000008003cc0 x8 : ffff000009532f60 
[    2.286794] x7 : 00000000ffffffff x6 : ffff80083a6600a8 
[    2.292111] x5 : 0000800836a06000 x4 : 0000000000000000 
[    2.297427] x3 : 0000000000000020 x2 : 0000800836a06000 
[    2.302744] x1 : ffff000009532580 x0 : ffff80083a660000 
[    2.308064] Process swapper/0 (pid: 0, stack limit = 0xffff000009520000)
[    2.314767] Call trace:
[    2.317211] Exception stack(0xffff000008003ba0 to 0xffff000008003ce0)
[    2.323650] 3ba0: ffff80083a660000 ffff000009532580 0000800836a06000 0000000000000020
[    2.331486] 3bc0: 0000000000000000 0000800836a06000 ffff80083a6600a8 00000000ffffffff
[    2.339323] 3be0: ffff000009532f60 ffff000008003cc0 0000000000000980 0000000000000000
[    2.347158] 3c00: 0000000000000001 0000000000000000 0000000000000000 ffffffffffffffff
[    2.354994] 3c20: 0000000000000480 0000000000000038 0000000000000010 0000000000000001
[    2.362831] 3c40: ffff000009528e78 ffff00000954afd8 ffff000009532580 ffff00000950c000
[    2.370669] 3c60: ffff000008dc3c80 ffff000009532b30 0000000000000000 0000000000000001
[    2.378503] 3c80: ffff000009532580 00000000ffff179f 0000000000000000 ffff000008003ce0
[    2.386339] 3ca0: 0000000000000000 00000000000001c5 ffff000008003dc0 ffff000008104750
[    2.394175] 3cc0: 0000ffffffffffff 0000000000000000 00000000ffff179f 0000000000000000
[    2.402009] [<          (null)>]           (null)
[    2.406713] Code: bad PC value
[    2.409780] ---[ end trace d4a8254aeaaaa986 ]---
[    2.414400] Kernel panic - not syncing: Attempted to kill the idle task!
[    2.421105] SMP: stopping secondary CPUs
[    2.425025] Kernel Offset: disabled
[    2.428517] CPU features: 0x0802008
[    2.432008] Memory Limit: none
[    2.435059] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I have three questions regarding this issue:

1. Do you provide a fix for parallel RGB on the imx_4.14.98_2.3.0 release?
2. Is this issue still persisting on a 5.4 based release from NXP?
3. Do you have any idea what could cause the glmark2 issue in the attached video?

Best Regards,

Philippe

Edit:

- The glmark2 bug in the video occurs only on iMX8DX SoC

- I tried this as well on NXPs release imx_5.4.3_2.0.0 There the bug doesn't appear. So the question will be if a fix will be provided for the 4.14 release we're basing on right now.

[nxf54947]

Hello philippe.schenker@toradex.com‌,

As the bug is limited to i.MX 8DX SoC and kernel 4.14, I'm going to review this issue with our application engineers, and reply as soon as I get more information on this.

Best regards,

Ruben

[nxf54947]

Hello philippe.schenker@toradex.com‌,

The glmark2 issue is still being investigated. Meanwhile, it was reported that the kernel panic faced at QXP is due the flash.bin.

I will have to ask you to please use a non-m4 flash.bin in order to use the parallel display dtb.

Regards

Ruben

[nxf54947]

Hello philippe.schenker@toradex.com‌,

Thank you for your patience.

Could you test the attached patch? Our application engineers suspect that the problem is caused by a display under-run. 

Please, let me know if this works.

Regards,

[philippe_schenk]

Hi nxf54947‌

Thank you very much for your effort and sorry for my latency too, needed some time to actually try this out. So I tried the GBM_SET_FORMAT_MOD_LINEAR=1 like you suggested and also starting Weston a little different. I also tried setting DRM_FORMAT_MOD_LINEAR=1 and to =0 but nothing helped. The DRM_FORMAT_MOD_LINEAR I tried because I couldn't find GBM_SET_FORMAT_MOD_LINEAR in source code at all so I'm doubting that this will help.

What do you suggest to try next?

Thanks and Best Regards
Philippe

[nxf54947]

Hi philippe.schenker@toradex.com‌,

Could you be so kind to provide me the exact steps to reproduce the issue? Is it repeatable with the i.MX 8 QXP? or only with the i.MX 8 DXP?

Also, could you please confirm which demo or BSP image are you using? Did you perform any other changes to it?

I was informed by our application engineers that the i.MX 8 DXP  only has support for L4.14.98_2.3.1 BSP.

Best regards,

Ruben

[philippe_schenk]

Hi Ruben,

Thanks again for your effort. See my answers below

Could you be so kind to provide me the exact steps to reproduce the issue? Is it repeatable with the i.MX 8 QXP? or only with the i.MX 8 DXP?

The biggest issue here is, I do not have NXP hardware that I could use for reproducing this. On our modules this bug does only occur on a DX processor but not on a QXP processor. To reproduce the issue I only have to make sure G2D is enabled in weston.ini and then running glmark2-es2-wayland is showing the bug.

Also, could you please confirm which demo or BSP image are you using? Did you perform any other changes to it?

Like I mentioned above I can only test this on our Boards software.

I was informed by our application engineers that the i.MX 8 DXP  only has support for L4.14.98_2.3.1 BSP.

Thanks, yes we are using that exact release right now.

In the meantime we decided that we update to the L5.4 based release in fall this year. This bug got also postponed to that release. So we all hope now that it won't occur there anymore.

I would suggest that, if it occurs on L5.4 again in fall, I come back and then try my best to test it also on vanilla NXP software with your MEK boards if possible.

Thanks again for your efforts,
Philippe