Re: [chromium-dev] content_shell doesn't startup with ozone_gbm

[Yuly Novikov]

bcc:chromium-dev

cc:ozone-dev

On Sun, Nov 15, 2015 at 5:58 AM, Markus Pfau <mpf...@gmail.com> wrote:

- odroid XU3 exynos 5422 ARM board with MALI T628 GPU

- linux ubuntu 15.01

- EGL h/w is supported through: /usr/lib/arm-linux-gnueabihf/mali-egl/libEGL.so

- crosscompiled content_shell on ubuntu 14.04 server (x64) with: 'use_x11=0 embedded=1 enable_google_now=0 use_ozone=1 use_ash=0 use_aura=1 ozone_platform_gbm=1 ozone_platform_test=1 ffmpeg_branding="Chrome" remove_webcore_debug_symbols=1 chromeos=0 enable_webrtc=0'

My goal is to get content_shell run without X.

After copying the executable and dependencies to my ARM machine, got following errors:

# ./content_shell --ozone-platform=gbm --enable-logging --v=1
 
[1:1:1115/114124:35246949728:VERBOSE1:zygote_main_linux.cc(564)] ZygoteMain: initializing 0 fork delegates
[1778:1778:1115/114124:35246955828:VERBOSE1:drm_device_handle.cc(59)] Succeeded authenticating /dev/dri/card0
[1778:1778:1115/114124:35246997639:VERBOSE1:gpu_info_collector_linux.cc(86)] PCI bus scanning is not supported
[1:1:1115/114124:35247132314:VERBOSE1:sandbox_linux.cc(68)] Activated seccomp-bpf sandbox for process type: renderer.
[1:1:1115/114124:35247134786:VERBOSE1:child_thread_impl.cc(377)] Mojo is disabled on child
[1778:1798:1115/114124:35247231234:VERBOSE1:proxy_service.cc(945)] PAC support disabled because there is no system implementation
[1804:1804:1115/114124:35247233454:ERROR:gl_surface_egl.cc(434)] eglInitialize Default failed with error EGL_NOT_INITIALIZED
[1804:1804:1115/114124:35247233707:ERROR:gl_surface_egl.cc(434)] eglInitialize Default failed with error EGL_NOT_INITIALIZED
[1804:1804:1115/114124:35247233768:ERROR:gl_surface_ozone.cc(626)] GLSurfaceEGL::InitializeOneOff failed.
[1804:1804:1115/114124:35247233850:VERBOSE1:gpu_main.cc(321)] gfx::GLSurface::InitializeOneOff failed
[1804:1804:1115/114124:35247234435:ERROR:sandbox_linux.cc(338)] InitializeSandbox() called with multiple threads in process gpu-process
[1804:1804:1115/114124:35247235312:VERBOSE1:child_thread_impl.cc(377)] Mojo is disabled on child
[1804:1804:1115/114124:35247236384:ERROR:gpu_child_thread.cc(257)] Exiting GPU process due to errors during initialization
[1804:1831:1115/114124:35247237460:ERROR:gbm_device.cc(27)] Unable to initialize GBM for /dev/dri/card0: Invalid argument
[1804:1831:1115/114124:35247238052:ERROR:drm_device_manager.cc(52)] Could not initialize DRM device for /dev/dri/card0

I have looked around my drivers but its really hard to understand, which driver the libosmesa.so, wich was compiled during the content_shell ninja run, is searching for.

Do I have to change my mesa configuration using the gyp files to point mesa to the correct driver (the mali driver)?

Thanks in advance for your tme and help!

Markus

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Stéphane Marchesin]

The gbm platform is meant to be used with Chrome OS. That means you
need a set of things you probably don't have to run it:
- a DRM driver for exynos (in upstream kernels under drivers/gpu/drm/exynos)
- a gbm implementation on top (for Chrome OS we use minigbm)
- a freon-compatible GLES driver (I think you can only get this from
Chrome OS prebuilts, and I'm not sure if that'll work with your board.

Stéphane

>>
>> Thanks in advance for your tme and help!
>>
>> Markus
>>
>> --
>> --
>> Chromium Developers mailing list: chromi...@chromium.org
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/a/chromium.org/group/chromium-dev
>
>
> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

> ---
> You received this message because you are subscribed to the Google Groups
> "Chromium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-dev...@chromium.org.

[mpf...@gmail.com]

Thanks for your quick reply, I really appreciate this!

It seems to be a general issue with samsungs driver that they didn't support gdm in their binary mali userspace blob.

There has been some posts about this issue between chrome / chromium team members / including your person abouit this issue (https://code.google.com/p/chromium/issues/detail?id=395688) but I'm still not sure if you really got it to work. Did you? If so - are you using any special driver from samsung?

[Stéphane Marchesin]

On Wed, Nov 25, 2015 at 7:01 AM, <mpf...@gmail.com> wrote:
> Thanks for your quick reply, I really appreciate this!
>
> It seems to be a general issue with samsungs driver that they didn't support gdm in their binary mali userspace blob.
>
> There has been some posts about this issue between chrome / chromium team members / including your person abouit this issue (https://code.google.com/p/chromium/issues/detail?id=395688) but I'm still not sure if you really got it to work. Did you? If so - are you using any special driver from samsung?

Yes we have all the bits for Chrome OS. I recommend you get a Chrome
OS checkout and look at the board named peach_pi/peach_pit which is
probably the closest to your hardware.

Stéphane

[Markus Pfau]

Hi,

in the meantime I pulled the latest sources and yes, its ozone-platform headless instead test now - but this doesn't matter as I try to get GBM working.

- I got minigbm configured for use with exynos devices.

- not said before: I'm using the latest r6p0 fbdev mali driver from samsung because of enabled DMA

Currently content-shell fails while initializing the basic surface texture in chromium code search

The DMA buf seems to be OK regarding gdb:

(gdb) p *((ui::GbmPixmap*)pixmap)

$14 = {<ui::NativePixmap> = {<base::RefCountedThreadSafe<ui::NativePixmap, base::DefaultRefCountedThreadSafeTraits<ui::NativePixmap> >> = {<base::subtle::RefCountedThreadSafeBase> = {ref_count_ = 2,

        in_dtor_ = false}, <No data fields>}, _vptr$NativePixmap = 0x6299e2c <vtable for ui::GbmPixmap+8>}, buffer_ = {ptr_ = 0x680c4d0}, dma_buf_ = {data_ = {<base::internal::ScopedFDCloseTraits> = {<No data fields>}, generic = 61}},

  dma_buf_pitch_ = 3200, surface_manager_ = 0x652ec50, processing_callback_ = {<base::internal::CallbackBase> = {bind_state_ = {ptr_ = 0x0}, polymorphic_invoke_ = 0x0}, <No data fields>}}

and syslog (GEM required).

unfortunately  egl_image_ = eglCreateImageKHR(gfx::GLSurfaceEGL::GetHardwareDisplay(),

                                 EGL_NO_CONTEXT,
                                 target,
                                 buffer,
                                 attrs);

fails (EGL_BAD_PARAMETER).

I have contaced mali developers, but somehow I have the feeling, that you guys may have better information than I 'll ever get from them.

Any idea if there is simply not implemented on driver side or are there some mandatory attributes missing?

Thanks in advance for your support!

Markus

[Stéphane Marchesin]

On Fri, Nov 27, 2015 at 3:06 PM, Markus Pfau <mpf...@gmail.com> wrote:
> Hi,
>
> in the meantime I pulled the latest sources and yes, its ozone-platform
> headless instead test now - but this doesn't matter as I try to get GBM
> working.
>
> - I got minigbm configured for use with exynos devices.
> - not said before: I'm using the latest r6p0 fbdev mali driver from samsung
> because of enabled DMA

You can't use fbdev, you need the Chrome OS driver.

>
> Currently content-shell fails while initializing the basic surface texture
> in chromium code search
>
> The DMA buf seems to be OK regarding gdb:
>
> (gdb) p *((ui::GbmPixmap*)pixmap)
> $14 = {<ui::NativePixmap> = {<base::RefCountedThreadSafe<ui::NativePixmap,
> base::DefaultRefCountedThreadSafeTraits<ui::NativePixmap> >> =
> {<base::subtle::RefCountedThreadSafeBase> = {ref_count_ = 2,
> in_dtor_ = false}, <No data fields>}, _vptr$NativePixmap = 0x6299e2c
> <vtable for ui::GbmPixmap+8>}, buffer_ = {ptr_ = 0x680c4d0}, dma_buf_ =
> {data_ = {<base::internal::ScopedFDCloseTraits> = {<No data fields>},
> generic = 61}},
> dma_buf_pitch_ = 3200, surface_manager_ = 0x652ec50, processing_callback_
> = {<base::internal::CallbackBase> = {bind_state_ = {ptr_ = 0x0},
> polymorphic_invoke_ = 0x0}, <No data fields>}}

You should start by running the gbm unit tests and check they work.
They are called graphics_Gbm in Chrome OS. Then run modetest and check
that this works too.

Stéphane