DSI display comes up during U-Boot and displays ST Logo but turns off once Linux Kernel takes over on our custom DK2 board. Weston Wayland Compositor fails to start during boot and backlight setup fails too. Does Wayland compositor have GPIO dependencies?

[EB.1]

Most of the DSI pin mapping is same as ST's DK2 board except DSI_RESET and DSI_TE. I updated the DSI_RESET pin mapping in the device tree to reflect actual connections. However, Weston Wayland compositor fails to start even when DSI display is not connected. Does weston have any other GPIO dependencies?

[   2.289892] stm32-usbphyc 5a006000.usbphyc: registered rev:1.0

[   2.295603] stm32-display-dsi 5a000000.dsi: Linked as a consumer to regulator.2

[   2.304123] panel-orisetech-otm8009a 5a000000.dsi.0: Linked as a consumer to regulator.8

[FAILED] Failed to start Weston Wayland Compositor.

[FAILED] Failed to start Load/Save Screen Ba…tness of backlight:5a000000.dsi.0.

I get the following messages when I try to manually start weston:

root@stm32mp1:/sbin# weston start

Date: 2020-01-29 UTC

[21:20:37.923] weston 5.0.0

              https://wayland.freedesktop.org

              Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/

              Build: unknown (not built from git or tarball)

[21:20:37.923] Command line: weston start

[21:20:37.923] OS: Linux, 4.19.49, #1 SMP PREEMPT Sun Jun 9 07:17:25 UTC 2019, armv7l

[21:20:37.924] Using config file '/etc/xdg/weston/weston.ini'

[21:20:37.925] Output repaint window is 100 ms maximum.

[21:20:37.925] Loading module '/usr/lib/libweston-5/drm-backend.so'

[21:20:37.940] initializing drm backend

[21:20:37.941] logind: failed to get session seat

[21:20:37.942] logind: cannot setup systemd-logind helper (-61), using legacy fallback

[21:20:37.942] <stdin> not a vt

[21:20:37.942] if running weston from ssh, use --tty to specify a tty

[21:20:37.942] fatal: drm backend should be run using weston-launch binary, or your system should provide the logind D-Bus API.

[21:20:37.942] fatal: failed to create compositor backend

The output of 'systemctl status weston.service'

[[0;1;31m�?[[0m weston.service - Weston Wayland Compositor

  Loaded: loaded (/lib/systemd/system/weston.service; enabled; vendor preset: enabled)

  Active: [[0;1;31mfailed[[0m (Result: exit-code) since Wed 2020-01-29 20:59:31 UTC; 22min ago

 Process: 3609 ExecStartPre=/sbin/check-gpu [[0;1;31m(code=exited, status=1/FAILURE)[[0m

Jan 29 20:59:31 stm32mp1 systemd[1]: Starting Weston Wayland Compositor...

Jan 29 20:59:31 stm32mp1 systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mweston.service: Control process exited, code=exited status=1[[0m

Jan 29 20:59:31 stm32mp1 systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mweston.service: Failed with result 'exit-code'.[[0m

Jan 29 20:59:31 stm32mp1 systemd[1]: [[0;1;31m[[0;1;39m[[0;1;31mFailed to start Weston Wayland Compositor.[[0m

I've attached full boot log for your reference.

[Olivier GALLIEN]

Hi @EB.1​ 

To secure your board/display bring-up we would advise to adopt a step by step approach in order to rounded more quickly where is potential issue.

Prior to load the full weston framework, can you please check everything ok at driver level playing with "modetest".

refer to https://wiki.st.com/stm32mpu/wiki/DRM_KMS_overview#How_to_use_the_framework

if it already fail at that stage you can then start to debug using methods suggested here :

https://wiki.st.com/stm32mpu/wiki/DRM_KMS_overview#How_to_trace_and_debug_the_framework) 

Hope it help,

Olivier

[EB.1]

Hello OlivierG,

Thank you for your response.

I tried some of the tests you suggested. Here are the results (FYI, I'm using OpenSTLinux Starter Image):

root@stm32mp1:~# modetest -M stm

failed to open device 'stm': No such file or directory

root@stm32mp1:~# ls /sys/kernel/debug/dri/0/

ls: cannot access '/sys/kernel/debug/dri/0/': No such file or directory

The "dri" directory is empty.

I've seen the same behavior across multiple custom boards of ours. The same SD card with same image works fine on ST's DK2 board and Weston comes up fine.

Does Weston have any dependency on the state of GPIOs or on GPIO pin mapping? Because the only thing different on our board compared to ST's DK2 is pin mapping of few GPIOs are different. Everything else is the same.

Please let me know what you think.

[EB.1 · Accepted solution]

We figured out why the Western Wayland Compositor wasn't coming up.

From our testing it looks like Weston comes up successfully only if:

1. LTDC peripheral is enabled in device tree.
2. The pin mapping of LTDC pins (we're using 24bit BGR) in the device tree matches physical connections.

Both my test cases did not satisfy one of the above two requirements:

Test case 1: I booted our custom board with OpenSTLinux Starter image without any custom mods to device tree - Weston didn't come up because we had remapped 3 of the LTDC pins on our custom board and default device tree did not reflect it.

Test Case 2: I used a minimal custom DT in which LTDC peripheral was not enabled. My assumption here was that OpenSTLinux would not try to bring up Weston service if LTDC/DSI peripheral was not enabled in DT. I didn't know OpenSTLinux would try to bring it up anyways and "FAIL" to do so.

Western Wayland Compositor came up after I enabled LTDC peripheral in my custom DT and matched pin mapping of LCD pins with physical connections.