chromium 103 does not build for imx8qm #649

ambrice · 2022-08-03T18:19:09Z

Building chromium-ozone-wayland on i.MX8QM for wayland only, no x11 libs. Have the following patch to disable dri:

diff --git a/content/gpu/BUILD.gn b/content/gpu/BUILD.gn
index 1a6063b03..c766f5ee3 100644
--- a/content/gpu/BUILD.gn
+++ b/content/gpu/BUILD.gn
@@ -135,7 +135,7 @@ target(link_target_type, "gpu_sources") {
   }
 
   # Use DRI on desktop Linux builds.
-  if (current_cpu != "s390x" && current_cpu != "ppc64" && is_linux &&
+  if (current_cpu != "s390x" && current_cpu != "ppc64" && is_linux && ozone_platform_x11 &&
       !is_castos) {
     configs += [ "//build/config/linux/dri" ]
   }

Similar patch worked for 101, but in 103 I'm getting a compilation error:

| python3 "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome" -- aarch64-poky-linux-clang++ -target aarch64-poky-linux  -mlittle-endian -Qunused-arguments -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Wdate-time --sysroot=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0/recipe-sysroot -Wl,--version-script=../../build/linux/chrome.map -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=20 -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10\%:cache_size_bytes=40g:cache_size_files=100000 -Wl,-mllvm,-import-instr-limit=5 -fwhole-program-vtables -Wl,--no-call-graph-profile-sort -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-z,defs -Wl,--as-needed -pie -Wl,--disable-new-dtags -Wl,--lto-O2 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fmacro-prefix-map=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0=/usr/src/debug/chromium-ozone-wayland/103.0.5060.129-r0                      -fdebug-prefix-map=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0=/usr/src/debug/chromium-ozone-wayland/103.0.5060.129-r0                      -fdebug-prefix-map=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0/recipe-sysroot=                      -fdebug-prefix-map=/var/tmp/yocto/work/aarch64-mx8-poky-linux/chromium-ozone-wayland/103.0.5060.129-r0/recipe-sysroot-native=  -Wl,-z,relro,-z,now  -stdlib=libc++ -o "./chrome" -Wl,--start-group @"./chrome.rsp"  -Wl,--end-group  -latomic -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -latk-1.0 -latk-bridge-2.0 -lgio-2.0 -ldbus-1 -lresolv -ljpeg -lexpat -luuid -ldrm -lxkbcommon -lm -lz -lwayland-client -lgbm -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo -lasound -lwayland-egl -lpci -latspi -lFLAC -lxslt -lxml2
| aarch64-poky-linux-ld.lld: error: undefined symbol: gl::NativeViewGLSurfaceEGL::NativeViewGLSurfaceEGL(gl::GLDisplayEGL*, void*, std::__1::unique_ptr<gfx::VSyncProvider, std::__1::default_delete<gfx::VSyncProvider> >)

The text was updated successfully, but these errors were encountered:

maskimthedog · 2022-08-25T10:59:09Z

I am seeing the same issue building chromium-ozone-wayland for wayland only for i.MX8MM after applying the same patch.

| aarch64-poky-linux-ld.lld: error: undefined symbol: gl::NativeViewGLSurfaceEGL::NativeViewGLSurfaceEGL(gl::GLDisplayEGL*, void*, std::__1::unique_ptr<gfx::VSyncProvider, std::__1::default_deletegfx::VSyncProvider >)
| >>> referenced by gl_surface_wayland.cc:35 (./../../ui/ozone/platform/wayland/gpu/gl_surface_wayland.cc:35)
| >>> thinlto-cache/Thin-7f2605.tmp.o:(ui::GLSurfaceWayland::GLSurfaceWayland(gl::GLDisplayEGL*, std::__1::unique_ptr<wl_egl_window, ui::EGLWindowDeleter>, ui::WaylandWindow*))

ensc · 2022-09-22T08:23:11Z

The immediate problem is that from

#elif defined(__GBM__)
typedef void               *EGLNativeWindowType;
...
#elif defined(USE_OZONE)
typedef intptr_t EGLNativeWindowType;

the first branch is used for some sources while the second one for other. This changes C++ function signatures.

ensc · 2022-09-23T10:17:43Z

setting

CXXFLAGS += "-D__GBM__"

workarounds it for me.

5o5uk3 · 2022-10-18T15:55:17Z

Hello,

I had exactly the same issue (but with chromium 105 build) and I have chosen the opposite approach.
From my point of view gbm.pc file should not add -D__GBM__ flag as it is already set through gbm.h when it is included. That's why I have patched imx-gpu-viv_6.4.3.p2.0-aarch64 recipe to remove this flag and the chromium compilation is OK.
FYI, the patch applied below:

Index: imx-gpu-viv-6.4.3.p2.0-aarch64/gpu-core/usr/lib/pkgconfig/gbm.pc
===================================================================
--- imx-gpu-viv-6.4.3.p2.0-aarch64.orig/gpu-core/usr/lib/pkgconfig/gbm.pc
+++ imx-gpu-viv-6.4.3.p2.0-aarch64/gpu-core/usr/lib/pkgconfig/gbm.pc
@@ -8,4 +8,4 @@ Description: vivante gbm library
 Version: 17.2
 Libs: -L${libdir} -lgbm
 Libs.private: -ldl
-Cflags: -I${includedir} -DLINUX -D__GBM__
+Cflags: -I${includedir} -DLINUX

Villemoes · 2022-10-28T07:45:28Z

Building for imx8mp, having the same issue. Any consensus on whether it needs fixing in chromium or imx-gpu-viv?

5o5uk3 · 2022-11-03T16:18:21Z

@Villemoes What I can assert is that chromium does not seem to use GPU acceleration with my method. I have to check if it behaves better with open source drivers.

amcelroy · 2023-03-01T20:37:17Z

setting
CXXFLAGS += "-D__GBM__"
workarounds it for me.

Howdy, I'm trying to get Chromium compiled for Dunfell Yocto for an iMX8X and am hitting this error. Which file did you add the CXXFLAGS += "-D__GBM__" to?

Edit: Might have figured it out; I put it at the bottom of /layers/meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_110.0.5481.77.bb. Everything compiled correctly, will have to check about GPU accel.

ambrice · 2023-03-27T18:09:44Z

We have been stuck on chromium 92 on i.MX8QM for a while but I copied this recipe from NXP's meta-imx layer:

https://github.com/nxp-imx/meta-imx/tree/langdale-6.1.1-1.0.0/meta-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium/

Seems to work, with GPU acceleration, gets us to chromium 101 at least. I'm using with commit 6079a8b of meta-browser for chromiums 101 recipe.

maskimthedog · 2023-03-29T14:54:54Z

We have been stuck on chromium 92 on i.MX8QM for a while but I copied this recipe from NXP's meta-imx layer:

https://github.com/nxp-imx/meta-imx/tree/langdale-6.1.1-1.0.0/meta-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium/

Seems to work, with GPU acceleration, gets us to chromium 101 at least. I'm using with commit 6079a8b of meta-browser for chromiums 101 recipe.

What about hardware video decode?

ambrice · 2023-03-29T16:11:40Z

I haven't tried hardware video decode but a commit says it was added:

commit fe0d3587d905a8fa32a9830d177f97c90352fdc5
Author: Hou Qi qi.hou@nxp.com
Date: Thu Sep 15 22:28:13 2022 +0800

chromium-ozone-wayland: Add V4L2VDA support on Linux [YOCIMX-6545]

    - support on i.MX 8 series platform.
    - 8MM/8MP/8MQ support h264/hevc/vp8/vp9 hardware decoding.
    - 8QM/8QXP support h264/hevc/vp8 hardware decoding.
    - support seek, playrate change and resolution change.
    - support video acceleration for online media platform such as Youtube, bilibili.

maskimthedog · 2023-03-29T16:20:06Z

I haven't tried hardware video decode but a commit says it was added:

commit fe0d3587d905a8fa32a9830d177f97c90352fdc5 Author: Hou Qi qi.hou@nxp.com Date: Thu Sep 15 22:28:13 2022 +0800
chromium-ozone-wayland: Add V4L2VDA support on Linux [YOCIMX-6545]

    - support on i.MX 8 series platform.
    - 8MM/8MP/8MQ support h264/hevc/vp8/vp9 hardware decoding.
    - 8QM/8QXP support h264/hevc/vp8 hardware decoding.
    - support seek, playrate change and resolution change.
    - support video acceleration for online media platform such as Youtube, bilibili.

Wow, that's very timely. I will check it out. Thank you.

maskimthedog · 2023-03-29T17:44:59Z

fe0d3587d905a8fa32a9830d177f97c90352fdc5

I haven't tried hardware video decode but a commit says it was added:

commit fe0d3587d905a8fa32a9830d177f97c90352fdc5 Author: Hou Qi qi.hou@nxp.com Date: Thu Sep 15 22:28:13 2022 +0800
chromium-ozone-wayland: Add V4L2VDA support on Linux [YOCIMX-6545]

    - support on i.MX 8 series platform.
    - 8MM/8MP/8MQ support h264/hevc/vp8/vp9 hardware decoding.
    - 8QM/8QXP support h264/hevc/vp8 hardware decoding.
    - support seek, playrate change and resolution change.
    - support video acceleration for online media platform such as Youtube, bilibili.

You tested on Langdale, Kirkstone or Dunfell?

maskimthedog · 2023-04-13T17:21:48Z

One of our engineers was able to get video decode in Chromium on Langdale. Video rendering looks good and CPU usage is very minimal.

otavio · 2023-04-13T18:05:55Z

Is the patchset public?

ambrice · 2023-04-13T18:30:56Z

Yes, available at https://github.com/nxp-imx/meta-imx/tree/langdale-6.1.1-1.0.0/meta-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium/

russdill · 2023-06-29T18:23:12Z

I've found this to be a somewhat smaller hammer

diff --git a/ui/gl/BUILD.gn b/ui/gl/BUILD.gn
index 761888bf4a540..0d31ab3b34f35 100644
--- a/ui/gl/BUILD.gn
+++ b/ui/gl/BUILD.gn
@@ -260,6 +260,13 @@ component("gl") {
       if (angle_shared_libvulkan && !is_chromeos) {
         data_deps += [ "//third_party/vulkan-deps/vulkan-loader/src:libvulkan" ]
       }
+      defines += [ "WAYLAND_GBM" ]
+
+      deps += [
+        "//third_party/minigbm",
+        "//ui/gfx:memory_buffer",
+        "//ui/gfx/linux:gbm",
+      ]
     }
   }

russdill · 2023-07-26T16:23:18Z

One of the changes chromium 114 brought in was 20f14755 "ui: gbm_wrapper: Ensure to create BOs with
import-compatible modifier". This change doesn't play well with the imx gbm library. One issue is that the file descriptors to things within the gbm_bo are kept open across a call to gbm_bo_destroy, which causes errors on close. Another issue is that the library doesn't seem to react well with this attempt to use different modifiers within a loop. 9ccd092ec "[m114] Close FDs after use in gbm_wrapper::Device:CereateBufferWithModifiers()" sits on top of this commit, so reverting it is also necessary.

russdill · 2023-07-26T16:31:41Z

The imx gbm library hardcodes dri device nodes but still implements the calls to request them. This patch allows chrome to ignore the ones returned in favor of env vars.

From a51a2a3a567cba945cfa89368924bbfe3f0657ad Mon Sep 17 00:00:00 2001
From: Russ Dill <russ.dill@nikolamotor.com>
Date: Mon, 17 Jul 2023 04:42:10 -0700
Subject: [PATCH 3/7] drm: Allow render node and dri file to be specified

---
 ui/ozone/platform/drm/gpu/gbm_surface_factory.cc             | 5 +++++
 ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc | 4 ++++
 2 files changed, 9 insertions(+)

diff --git a/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc b/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc
index b77c1aa2f7bb4..d9fa29c8c994d 100644
--- a/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc
+++ b/ui/ozone/platform/drm/gpu/gbm_surface_factory.cc
@@ -9,6 +9,7 @@
 
 #include <memory>
 #include <utility>
+#include <string.h>
 
 #include "base/containers/contains.h"
 #include "base/files/file_path.h"
@@ -207,6 +208,10 @@ std::vector<gfx::BufferFormat> EnumerateSupportedBufferFormatsForTexturing() {
     base::FilePath dev_path(FILE_PATH_LITERAL(
         base::StringPrintf(kRenderNodeFilePattern, i).c_str()));
 
+    const char *str = getenv("DRM_RENDER_NODE_FILE");
+    if (str && strcmp(str, base::StringPrintf(kRenderNodeFilePattern, i).c_str()))
+        continue;
+
     ScopedAllowBlockingForGbmSurface scoped_allow_blocking;
     base::File dev_path_file(dev_path,
                              base::File::FLAG_OPEN | base::File::FLAG_READ);
diff --git a/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc b/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc
index cdce6ae0d34db..c9aa6461829c8 100644
--- a/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc
+++ b/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc
@@ -54,6 +54,10 @@ void DrmRenderNodePathFinder::FindDrmRenderNodePath() {
     if (len >= 4 && memcmp(device_link + len - 4, "vgem", 4) == 0)
       continue;
 
+    const char *str = getenv("DRM_RENDER_NODE_FILE");
+    if (str && strcmp(str, base::StringPrintf(kDriRenderNodeTemplate, i).c_str()))
+        continue;
+
     std::string dri_render_node(base::StringPrintf(kDriRenderNodeTemplate, i));
     base::ScopedFD drm_fd(open(dri_render_node.c_str(), O_RDWR));
     if (drm_fd.get() < 0)
-- 
2.34.1

asdasdomar · 2023-07-30T15:16:58Z

One of the changes chromium 114 brought in was 20f14755 "ui: gbm_wrapper: Ensure to create BOs with import-compatible modifier". This change doesn't play well with the imx gbm library. One issue is that the file descriptors to things within the gbm_bo are kept open across a call to gbm_bo_destroy, which causes errors on close. Another issue is that the library doesn't seem to react well with this attempt to use different modifiers within a loop. 9ccd092ec "[m114] Close FDs after use in gbm_wrapper::Device:CereateBufferWithModifiers()" sits on top of this commit, so reverting it is also necessary.

Yes, reverting those commits worked for me as well.
Thanks

escherstair · 2023-11-10T20:09:27Z

Hello to everybody,
this issue is more than one year old (at the moment).
It's for chromium v103, but then (some months after) v105 and v114 are mentioned.
My question is: can the latest release available at the moment (I imagine v118 or v119) be built without issues for imx8qm/imx8mp?
Are patches required for a successful build?

VaginAY · 2024-03-12T09:50:38Z

Confirm for 123 version. After make all patches from meta-browser applicable (or remove such backport).

Pathces from meta-imx doesn't help.

georgekelly1097 · 2024-04-19T16:39:07Z

It seems NXP attempted to patch this twice.

First in meta-imx commit nxp-imx/meta-imx@45ae537 with the comment " Disable VPU temporarily until the patches are rebased based on newer version of chromium". Then they reverted that in commit 5401bc9.

Next, they renamed the top level folder "meta-sdk" to "meta-sdk-imx", so the commit history is hard to follow. Now NXP's chromium patches are here: https://github.com/nxp-imx/meta-imx/tree/nanbield-6.6.3-1.0.0/meta-imx-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium/chromium-ozone-wayland. It appears that these 3 patches are the relevant ones:
0004-Fix-chromium-build-failure.patch
0005-Revert-ui-gbm_wrapper-Ensure-to-create-BOs-with-impo.patch
0006-Fixed-chromium-crash-after-upgrading.patch \

I've got a build chugging now to see if they resolve this issue

rakuco assigned msisov Aug 5, 2022

Ravikasyap mentioned this issue May 22, 2023

Unable to add chromium-ozone-wayland package in Krikstone version yocto #684

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chromium 103 does not build for imx8qm #649

chromium 103 does not build for imx8qm #649

ambrice commented Aug 3, 2022

maskimthedog commented Aug 25, 2022

ensc commented Sep 22, 2022

ensc commented Sep 23, 2022

5o5uk3 commented Oct 18, 2022

Villemoes commented Oct 28, 2022

5o5uk3 commented Nov 3, 2022

amcelroy commented Mar 1, 2023 •

edited

ambrice commented Mar 27, 2023

maskimthedog commented Mar 29, 2023

ambrice commented Mar 29, 2023

maskimthedog commented Mar 29, 2023

maskimthedog commented Mar 29, 2023

maskimthedog commented Apr 13, 2023

otavio commented Apr 13, 2023

ambrice commented Apr 13, 2023

russdill commented Jun 29, 2023 •

edited by rakuco

russdill commented Jul 26, 2023

russdill commented Jul 26, 2023

asdasdomar commented Jul 30, 2023

escherstair commented Nov 10, 2023

VaginAY commented Mar 12, 2024

georgekelly1097 commented Apr 19, 2024

chromium 103 does not build for imx8qm #649

chromium 103 does not build for imx8qm #649

Comments

ambrice commented Aug 3, 2022

maskimthedog commented Aug 25, 2022

ensc commented Sep 22, 2022

ensc commented Sep 23, 2022

5o5uk3 commented Oct 18, 2022

Villemoes commented Oct 28, 2022

5o5uk3 commented Nov 3, 2022

amcelroy commented Mar 1, 2023 • edited

ambrice commented Mar 27, 2023

maskimthedog commented Mar 29, 2023

ambrice commented Mar 29, 2023

maskimthedog commented Mar 29, 2023

maskimthedog commented Mar 29, 2023

maskimthedog commented Apr 13, 2023

otavio commented Apr 13, 2023

ambrice commented Apr 13, 2023

russdill commented Jun 29, 2023 • edited by rakuco

russdill commented Jul 26, 2023

russdill commented Jul 26, 2023

asdasdomar commented Jul 30, 2023

escherstair commented Nov 10, 2023

VaginAY commented Mar 12, 2024

georgekelly1097 commented Apr 19, 2024

amcelroy commented Mar 1, 2023 •

edited

russdill commented Jun 29, 2023 •

edited by rakuco