Closed ghost closed 2 years ago
try weston --tty=2
normally the weston should be launched by default.
check the example config, see weston-init: https://github.com/JeffyCN/yocto-conf/blob/zeus/include/display.conf#L4
check the example config, see weston-init: https://github.com/JeffyCN/yocto-conf/blob/zeus/include/display.conf#L4
Thank you for your answer. As you said, I built it referring to the yocto-conf repository. After booting the board, I tried executing the Weston command.
root@rockchip-rk3288-evb:/tmp# weston --tty=2
Date: 2022-03-06 UTC
[01:59:21.491] weston 7.0.0
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 7.0.0
[01:59:21.504] Command line: weston --tty=2
[01:59:21.508] OS: Linux, 4.4.194-rockchip-standard, #1 SMP Sat Mar 5 16:54:21 UTC 2022, armv7l
[01:59:21.516] Using config file '/etc/xdg/weston/weston.ini'
[01:59:21.522] Output repaint window is 7 ms maximum.
[01:59:21.526] Loading module '/usr/lib/libweston-7/drm-backend.so'
[01:59:21.544] initializing drm backend
[01:59:21.546] using /dev/dri/card0
[01:59:21.547] DRM: supports universal planes
[01:59:21.549] DRM: supports atomic modesetting
[01:59:21.554] DRM: supports picture aspect ratio
[01:59:21.558] Loading module '/usr/lib/libweston-7/gl-renderer.so'
[01:59:21.565] EGL client extensions: EGL_EXT_client_extensions
EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
EGL_KHR_platform_gbm EGL_MESA_platform_gbm
EGL_KHR_platform_wayland EGL_EXT_platform_wayland
ERROR: The DDK (built for 0x750 r0p0 status range [1..1]) is not compatible with this Mali GPU device, /dev/mali0 detected as 0x750 r1p0 status 0.
Failed creating base context during DDK compatibility check.
[01:59:21.665] failed to initialize display
[01:59:21.665] EGL error state: EGL_NOT_INITIALIZED (0x3001)
[01:59:21.669] failed to initialize egl
[01:59:21.672] fatal: failed to create compositor backend
Internal warning: debug scope 'drm-backend' has not been destroyed.
arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '4'.arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '4'.arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '4'.arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '4'.
Is there a problem with the kernel driver?
ERROR: The DDK (built for 0x750 r0p0 status range [1..1]) is not compatible with this Mali GPU device, /dev/mali0 detected as 0x750 r1p0 status 0.
looks like your board is having rk3288w, which has the Mali GPU midgard t76x r1p0.
so you need to use rk3288w-evb config: meta-rockchip# ag rk3288w conf/machine/include/rk3288.inc 10:MALI_SUBVERSION := "${@bb.utils.contains('MACHINE_FEATURES', 'rk3288w', 'r1p0', 'r0p0', d)}"
build/conf# ag rk3288w rockchip-rk3288w-evb.conf 3:MACHINE_FEATURES += "rk3288w"
As you said, I modified the local.conf and built it.
local.conf
error
leejh@leejh-VirtualBox:/work/yocto/build$ bitbake core-image-weston
Parsing recipes: 100% |##########################################| Time: 0:00:14
Parsing of 2278 .bb files complete (0 cached, 2278 parsed). 3416 targets, 298 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-18.04"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "rockchip-rk3288-evb"
DISTRO = "poky"
DISTRO_VERSION = "3.0.4"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta-oe
meta-python = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-qt5 = "zeus:91e6e3b1f5aebd17f895caac3dee32a14630da99"
meta-rust = "zeus:59c951cc171aee5db29bbd74e104705a10fae588"
meta-clang = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta-rockchip = "zeus:9a0f8202581f6bd607e99494ba2cf60fdd89cd03"
meta
meta-poky
meta-yocto-bsp = "zeus:daf096e295121ea49ebf21f8070e9a6e28f5d46c"
meta-browser = "zeus:830ef438e81ba5fc915b1855e69f02b2c286b21a"
Initialising tasks: 100% |#######################################| Time: 0:00:01
Sstate summary: Wanted 1845 Found 0 Missed 1845 Current 0 (0% match, 0% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: core-image-weston-1.0-r0 do_rootfs: The postinstall intercept hook 'update_gtk_immodules_cache' failed, details in /work/yocto/build/tmp/work/rockchip_rk3288_evb-poky-linux-gnueabi/core-image-weston/1.0-r0/temp/log.do_rootfs
ERROR: Logfile of failure stored in: /work/yocto/build/tmp/work/rockchip_rk3288_evb-poky-linux-gnueabi/core-image-weston/1.0-r0/temp/log.do_rootfs.8727
ERROR: Task (/work/yocto/build/../poky/meta/recipes-graphics/images/core-image-weston.bb:do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5402 tasks of which 1 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
/work/yocto/build/../poky/meta/recipes-graphics/images/core-image-weston.bb:do_rootfs
An error called "The postinstall intercept hook 'update_gtk_immodules_cache' failed" occurs. I erased all the results that were built and tried to build again, but the error did not disappear. I tried to solve it, but I couldn't find the cause. What else should I modify?
looks like something wrong in the gtk script. i don't know much about that, since i'm using core-image-minimal(the graphic packages are added in the local conf, and no gtk) instead of core-image-weston
anyway, for the gtk issue, there're a few patches in google results: https://support.xilinx.com/s/question/0D52E00006hpW4USAU/immodulescache-no-such-file-or-directory?language=en_US https://support.xilinx.com/s/question/0D52E00006hpmwHSAQ/vcu-trd-20191-zcu106-the-postinstall-intercept-hook-updategtkimmodulescache-failed?language=en_US https://www.mail-archive.com/meta-freescale@lists.yoctoproject.org/msg00199.html
looks like something wrong in the gtk script. i don't know much about that, since i'm using core-image-minimal(the graphic packages are added in the local conf, and no gtk) instead of core-image-weston
anyway, for the gtk issue, there're a few patches in google results: https://support.xilinx.com/s/question/0D52E00006hpW4USAU/immodulescache-no-such-file-or-directory?language=en_US https://support.xilinx.com/s/question/0D52E00006hpmwHSAQ/vcu-trd-20191-zcu106-the-postinstall-intercept-hook-updategtkimmodulescache-failed?language=en_US https://www.mail-archive.com/meta-freescale@lists.yoctoproject.org/msg00199.html
I will refer to the patch files and links you shared.
However, there seems to be a problem with building with core-image-minimal.
leejh@leejh-VirtualBox:/work/yocto/build$ bitbake core-image-minimal
Loading cache: 100% |##############################################################| Time: 0:00:00
Loaded 3416 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "rockchip-rk3288-evb"
DISTRO = "poky"
DISTRO_VERSION = "3.0.4"
TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta-oe
meta-python = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-qt5 = "zeus:91e6e3b1f5aebd17f895caac3dee32a14630da99"
meta-rust = "zeus:59c951cc171aee5db29bbd74e104705a10fae588"
meta-clang = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta-rockchip = "zeus:9a0f8202581f6bd607e99494ba2cf60fdd89cd03"
meta
meta-poky
meta-yocto-bsp = "zeus:daf096e295121ea49ebf21f8070e9a6e28f5d46c"
meta-browser = "zeus:830ef438e81ba5fc915b1855e69f02b2c286b21a"
Initialising tasks: 100% |#########################################################| Time: 0:00:04
Sstate summary: Wanted 2 Found 0 Missed 2 Current 1670 (0% match, 99% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: core-image-minimal-1.0-r0 do_rootfs: The postinstall intercept hook 'update_pixbuf_cache' failed, details in /work/yocto/build/tmp/work/rockchip_rk3288_evb-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs
ERROR: Logfile of failure stored in: /work/yocto/build/tmp/work/rockchip_rk3288_evb-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.6334
ERROR: Task (/work/yocto/build/../poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4991 tasks of which 4990 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
/work/yocto/build/../poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
that is unlikely related to meta-rockchip too...looks like something wrong in your poky repo.
zeus is an old version, i've only tested it 2 years ago: https://github.com/JeffyCN/yocto-manifests/tree/release-1.3.0_20200915_zeus
and if let me guess, it might still caused by missing parent dir too. maybe try to add a similar mkdir in that hook script, or just remove the content of that script(weston doesn't depend on it)
and if let me guess, it might still caused by missing parent dir too. maybe try to add a similar mkdir in that hook script, or just remove the content of that script(weston doesn't depend on it)
Thank you! I solved the problem by modifying the script as below.
diff --git a/scripts/postinst-intercepts/update_pixbuf_cache b/scripts/postinst-intercepts/update_pixbuf_cache
old mode 100644
new mode 100755
index ea12814474..bd57480286
--- a/scripts/postinst-intercepts/update_pixbuf_cache
+++ b/scripts/postinst-intercepts/update_pixbuf_cache
@@ -8,6 +8,7 @@ set -e
export GDK_PIXBUF_MODULEDIR=$D${libdir}/gdk-pixbuf-2.0/2.10.0/loaders
export GDK_PIXBUF_FATAL_LOADER=1
+mkdir -p $D${libdir}/gdk-pixbuf-2.0/2.10.0/loaders
PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D $D${libdir}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \
>$GDK_PIXBUF_MODULEDIR/../loaders.cache && \
sed -i -e "s:$D::g" $GDK_PIXBUF_MODULEDIR/../loaders.cache
I have one more question. The screen output through the edp interface of the development board seems to change to power saving mode after a certain period of time. The following error occurs as the screen changes to power saving mode. Is it a problem with the kernel driver?
[ 8096.459777] CPU: 2 PID: 354 Comm: weston Not tainted 4.4.194-rockchip-standard #1
[ 8096.467311] Hardware name: Generic DT based system
[ 8096.472254] [<c010f77c>] (unwind_backtrace) from [<c010b55c>] (show_stack+0x20/0x24)
[ 8096.480102] [<c010b55c>] (show_stack) from [<c040ac10>] (dump_stack+0x84/0xa0)
[ 8096.487419] [<c040ac10>] (dump_stack) from [<c0113708>] (__div0+0x20/0x28)
[ 8096.494375] [<c0113708>] (__div0) from [<c0408cbc>] (Ldiv0_64+0x8/0x18)
[ 8096.501081] [<c0408cbc>] (Ldiv0_64) from [<c07c5428>] (clk_dclk_round_rate+0x3c/0x6c)
[ 8096.509020] [<c07c5428>] (clk_dclk_round_rate) from [<c07c04c8>] (clk_composite_determine_rate+0xd8/0x1ec)
[ 8096.518767] [<c07c04c8>] (clk_composite_determine_rate) from [<c07b98f0>] (clk_core_round_rate_nolock+0x58/0xb4)
[ 8096.529026] [<c07b98f0>] (clk_core_round_rate_nolock) from [<c07bcb8c>] (clk_round_rate+0x48/0x64)
[ 8096.538078] [<c07bcb8c>] (clk_round_rate) from [<c0503e38>] (vop_crtc_mode_fixup+0x68/0x90)
[ 8096.546532] [<c0503e38>] (vop_crtc_mode_fixup) from [<c04c3eb8>] (drm_atomic_helper_check_modeset+0x824/0x910)
[ 8096.556629] [<c04c3eb8>] (drm_atomic_helper_check_modeset) from [<c04c45c0>] (drm_atomic_helper_check+0x20/0x38)
[ 8096.566896] [<c04c45c0>] (drm_atomic_helper_check) from [<c04e92cc>] (drm_atomic_check_only+0x458/0x500)
[ 8096.576459] [<c04e92cc>] (drm_atomic_check_only) from [<c04e941c>] (drm_atomic_async_commit+0x24/0x7c)
[ 8096.585851] [<c04e941c>] (drm_atomic_async_commit) from [<c04e9cec>] (drm_mode_atomic_ioctl+0x51c/0x5d4)
[ 8096.595408] [<c04e9cec>] (drm_mode_atomic_ioctl) from [<c04cd310>] (drm_ioctl+0x2dc/0x414)
[ 8096.603762] [<c04cd310>] (drm_ioctl) from [<c0243e1c>] (do_vfs_ioctl+0xb0/0x678)
[ 8096.611247] [<c0243e1c>] (do_vfs_ioctl) from [<c0244444>] (SyS_ioctl+0x60/0x7c)
[ 8096.618641] [<c0244444>] (SyS_ioctl) from [<c01074c0>] (ret_fast_syscall+0x0/0x54)
yes, kernel issue. different drm display mode(resolution and refresh rate) might require different clock rate. and looks like this display mode is causing a abnormal clock rate that rk3288's clk tree doesn't support(or might be an issue in the rk3288 clk driver).
maybe you can hack the vop_crtc_mode_fixup
yes, kernel issue. different drm display mode(resolution and refresh rate) might require different clock rate. and looks like this display mode is causing a abnormal clock rate that rk3288's clk tree doesn't support(or might be an issue in the rk3288 clk driver).
I'm sorry, but I'm asking because I don't understand well. Does it mean that removing the function mapped to the structure below does not cause an error? https://github.com/JeffyCN/mirrors/blob/a7963498e38864de35febdff7a0985f947210f06/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L3685
If that's not the case, where should I fix it?
sorry, i don't know much about that too. according to your stack, the issue is caused by the clk_round_rate in vop_crtc_mode_fixup, which looks like the driver is trying to adjust the clk rate(crtc_clock), but that result in a __div0 exception(div to 0).
maybe you can try to add logs there to figure it out(is crtc_clock zero?), maybe you can try to remove that func(or return earlier if something wrong) as a workaround(might cause inaccurate clk rate)
anyway, it looks like the weston started now ;)
anyway, it looks like the weston started now ;)
thank you :)
Describe the bug I tried to run weston by building a meta-rockchip layer(zeus) with yocto, but an error occurred.
Environment
build/conf/bblayers.conf
build/conf/local.conf
build core-image-core-image-weston
result of the build
flash emmc
Error when executing weston
XDG_RUNTIME_DIR not set error:![xdg_err](https://user-images.githubusercontent.com/46815991/156729060-aeff5153-5215-45db-9a19-834bcb0ed209.PNG)
[Solved] $ mkdir /tmp/wayland $ echo XDG_RUNTIME_DIR=/tmp/wayland >> /etc/environment
drm-backend error![weston_err](https://user-images.githubusercontent.com/46815991/156730319-0290eb2f-6fa3-4760-8a2b-8a19ec77bf33.PNG)
I want to know the cause of the error as follows. Is there anything else I need to do?