This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: Wayland and Chromium 53 on Yocto/Arago

Part Number: AM5728

Tool/software: Linux

Hello,

I'm a part of a development team currently investigating the possibilities of running a modern web-based UI on a Sitara AM5728 device. The specific hardware we are using for evaluation is Compulab's CL-SOM-AM57x with the SB-SOM-AM57x carrier board. On the software side, we are currently using a Linux distribution built with Yocto/Arago, using the following meta layer setup:

meta-arago/meta-arago-distro
meta-arago/meta-arago-extras
meta-browser
meta-qt5
meta-openembedded/meta-networking
meta-openembedded/meta-ruby
meta-openembedded/meta-python
meta-openembedded/meta-oe
meta-openembedded/meta-gnome
meta-ti
meta-linaro/meta-linaro-toolchain
meta-linaro/meta-optee
openembedded-core/meta

The setup is based around the "Morty" branch of Yocto, the TI 2017.00 release of meta-arago and TI's 4.4.41 Linux kernel (with Compulab patches and board-specific device tree).

We have modified the PowerVR kernel driver recipe (ti-sgx-ddk-km_1.14.3699939.bb) to use the proper 4.4 kernel branch from git.ti.com/graphics/omap5-sgx-ddk-linux.git like so:

BRANCH = "ti-img-sgx/${PV}/k4.4"

For building Chromium for Wayland 53.0.2785.143, we are using recipes from the meta-browser layer (master branch, commit hash 880a7bd1d3b9a1b2003f5b0620350f03158bbd43).

The packages in our Yocto image are:
IMAGE_INSTALL += "\
packagegroup-arago-base \
packagegroup-arago-console \
omapdrm-pvr \
libexif \
wayland \
weston \
chromium-wayland \
"

With this setup we are currently attemping to get a working Chromium browser and have been unsuccessful so far. The chromium-wayland recipe builds successfully and Weston runs fine with EGL support, however Chromium crashes with the following error:

root@dev-am57x:~# google-chrome
[1027:1027:0425/213344:ERROR:sandbox_linux.cc(343)] InitializeSandbox() called with multiple threads in process gpu-process.
[1027:1027:0425/213344:ERROR:gpu_child_thread.cc(390)] Exiting GPU process due to errors during initialization
[1002:1002:0425/213344:ERROR:desktop_window_tree_host_ozone.cc(579)] Not implemented reached in virtual void views::DesktopWindowTreeHostOzone::SetWindowIcons(const gfx::ImageSkia&, const gfx::ImageSkia&)
[1002:1002:0425/213344:ERROR:ozone_webui.cc(61)] Not implemented reached in virtual void views::OzoneWebUI::GetDefaultFontDescription(std::__cxx11::string*, int*, int*, gfx::Font::Weight*, gfx::FontRenderParams*) const
[1002:1002:0425/213344:ERROR:ozone_webui.cc(51)] Not implemented reached in virtual gfx::FontRenderParams views::OzoneWebUI::GetDefaultFontRenderParams() const
[1002:1002:0425/213344:ERROR:ozone_webui.cc(51)] Not implemented reached in virtual gfx::FontRenderParams views::OzoneWebUI::GetDefaultFontRenderParams() const
[1002:1002:0425/213344:ERROR:ozone_webui.cc(51)] Not implemented reached in virtual gfx::FontRenderParams views::OzoneWebUI::GetDefaultFontRenderParams() const
[1002:1002:0425/213345:ERROR:desktop_window_tree_host_ozone.cc(579)] Not implemented reached in virtual void views::DesktopWindowTreeHostOzone::SetWindowIcons(const gfx::ImageSkia&, const gfx::ImageSkia&)
[1002:1002:0425/213345:ERROR:ozone_webui.cc(51)] Not implemented reached in virtual gfx::FontRenderParams views::OzoneWebUI::GetDefaultFontRenderParams() const
[1002:1002:0425/213345:ERROR:ozone_webui.cc(51)] Not implemented reached in virtual gfx::FontRenderParams views::OzoneWebUI::GetDefaultFontRenderParams() const
/usr/bin/google-chrome: line 11: 1002 Segmentation fault (core dumped) /usr/bin/chromium/chrome ${CHROME_EXTRA_ARGS} $@

I've searched around these boards a bit and found this thread with a similar issue (with Chromium 48, however) from last year. There a TI rep explained that GPU graphics libraries were the cause and it was being worked on by the GPU vendor.

Can you confirm that our issue is also caused by PowerVR graphics libraries and has there been any fix to that since then?

With regards,
Alo L.

  • Hi,

    The software team have been notified. They will respond here.
  • Alo,

    Have you looked at using QtWebEngine? It includes a fully operational Chromium browser. We include this Chromium demo browser as part of our Linux SDK. Currently we're on Qt 5.6 which bundles Chromium 45. Qt 5.8 bundles Chromium 53, so I believe that would address your request. I'm checking with the development team to understand what version of Qt will be in our next major SDK release in July. I am pretty sure it is Qt 5.8, but will send a note once I get confirmation.

    Longer term we are working toward inclusion of "native" Chromium. However, there are some other issues to work through first. For example, we need to migrate our Graphics DDK to the next major revision (it was released by Imagination a few weeks ago). Also, the Chromium project itself currently doesn't have proper Wayland support, so that's another facet to this issue. I would venture to guess we won't see native Chromium until 2018. However, if QtWebEngine will work for you, that should be available in July.

    Brad
  • Hello Brad,

    Thank you for the information.

    We haven't taken a look at QtWebEngine yet, but certainly will now. Chromium version isn't very important for us at least in this stage.

    Do you know if the Qt/QtWebEngine parts of the current TI Linux SDK example filesystem are also reproducible through Arago (the closest I've found so far might be the tisdk-rootfs-image.bb image recipe?) or do you only offer them as a pre-built filesystem?

    With regards,
    Alo
  • Yes, QtWebEngine in PLSDK can be built through Arago. Look for qtwebengine recipe for same.
  • It is also in the prebuilt file system:

    /usr/share/qt5/examples/webenginewidgets/demobrowser/demobrowser

    If you're behind a firewall, you can export variables like http_proxy and https_proxy before you launch it from the command line.

    Note that you'll get a lot of error messages on secure web pages if you don't have the date/time set appropriately. If you have /etc/ntpd.conf configured with an appropriate NTP server you can simply run "ntpd -s" to set the date/time.
  • For completeness, our July release will use the Yocto Morty branch which incorporates Qt 5.7.1.  The QtWebEngine from that release corresponds to Chromium 49.