Linux/AM5728: Updated EGL/GLES/PVR libraries

Bill Derby

Part Number: AM5728

Tool/software: Linux

The current EGL/GLES implementation library has bugs and has not been updated for multiple PDK releases (at lease since before the 02.00.00 era PDK) All release contain the 1.14@3699939 build includes the following user mode libraries (and symlinks):

-rwxr-xr-x 1 root root 6580 Aug 21 12:26 libEGL.so.1.14.3699939
-rwxr-xr-x 1 root root 425456 Aug 21 12:26 libGLES_CM.so.1.14.3699939
-rwxr-xr-x 1 root root 437592 Aug 21 12:26 libGLESv2.so.1.14.3699939
-rw-r--r-- 1 root root 84440 Jul 8 2016 libIMGegl.so.1.14.3699939
-rw-r--r-- 1 root root 8432 Jul 8 2016 libPVRScopeServices.so.1.14.3699939
-rw-r--r-- 1 root root 8364 Jul 8 2016 libdbm.so.1.14.3699939
-rw-r--r-- 1 root root 214356 Jul 8 2016 libglslcompiler.so.1.14.3699939
-rw-r--r-- 1 root root 20716 Jul 8 2016 libpvr2d.so.1.14.3699939
-rw-r--r-- 1 root root 16804 Jul 8 2016 libpvrDRMWSEGL.so.1.14.3699939
-rw-r--r-- 1 root root 17176 Jul 8 2016 libpvrGBMWSEGL.so.1.14.3699939 (linked to by /usr/lib/gbm/pvr_gbm)
-rw-r--r-- 1 root root 3592 Jul 8 2016 libpvr_wlegl.so.1.14.3699939
-rw-r--r-- 1 root root 12612 Jul 8 2016 libpvrws_WAYLAND.so.1.14.3699939
-rw-r--r-- 1 root root 110384 Jul 8 2016 libsrv_init.so.1.14.3699939
-rw-r--r-- 1 root root 221012 Jul 8 2016 libsrv_um.so.1.14.3699939
-rw-r--r-- 1 root root 974632 Jul 8 2016 libusc.so.1.14.3699939

There are multiple issues (bugs) with this implementation best seen in the patches for weston (e.g. multiple "card"'s found in the dev tree, and a supposedly "optional" EGL_NATIVE_VISUAL_ID, returned by eglGetConfigAttrib. This makes porting any library dealing with EGL a debugging and patching headache (i.e. Weston, Qt, Elementary, etc). The current Arago build does not build these from sources (I assume it's closed source) but just pulls the existing files into the tree and sets up symlinks. There are plenty of references to even older versions on Gitorious (git.ti.com/.../master) but everything is quite old now (circa 2015) but I assume they to just link to older pre-built libraries.

It appears that Imagination Technologies has open sourced their SDK (but again not the actual libraries) - even there the libraries are prebuilt. They do however look newer than the ones we have in the PDK. see: https://github.com/powervr-graphics.

Can we get fresh EGL/GLES builds for the PowerVR SGX 544MP and what mechanism do we have to submit bugs and resolve issues with the AM5728 EGL/GLES libraries. As an end user, a solid EGL/GLES foundation is essential to my (and I assume many others) usage for the Sirara, but it is anything but that at the moment and debugging issues related to these librarys has now consumed months of my time.

over 7 years ago

0 Yordan Kovachev over 7 years ago

TI__Guru**** 161600 points

Hi Bill,

I will consult with the factory team and update the thread.

Best Regards,
Yordan

0 Bill Derby over 7 years ago in reply to Yordan Kovachev

Intellectual 420 points

Hi Yordan,

It would of course go a long way if the EGL/GLES2 stack passed (or even started) a EGL/GLES2 testing suite like deqp.

available here among other places: android.googlesource.com/.../deqp

The deqp EGL/GLES2 tests won't event start due to the non standard way the EGL stack handles the get native display calls. I am working on hacking up the tests to get past init see what else fails but I've seen the same issues in multiple areas (again see the Arago patches for weston)

If I need to sign an NDA to help fix this I will do so - but we need to stop fixing these same bugs with patches in everything that touches the EGL stack i.e. fix the broken library not patch around it's bugs over and over again.

-Bill

0 Bill Derby over 7 years ago in reply to Bill Derby

Intellectual 420 points

FYI the same deqp suits is also here: github.com/.../VK-GL-CTS
(from the owners of the EGL spec....)

0 Bill Derby over 7 years ago in reply to Bill Derby

Intellectual 420 points

While I'm waiting for any official response - I am int meantime hacking up deqp to categorize the EGL/GLES2 issues on the AM5728. I have now patched around the problems with the deqp test suite and EGL init (avoid call to get native display) and am now running tests but failing a fair amount of tests - In particular, a lot of tests fail doing a glReadPixel call which results in the following display:

PVR:(Error): glReadPixels: Failed to get strided data [0, ]

The tests fail of course because the call doesn't return any data.

I instrumented the call and glReadPixels is passing what appears to correct arguments - format parameter is GL_RGBA and type is GL_UNSIGNED_BYTE. I attempted to call glGetError but the driver reports no errors.

I would note that this PVR error appears sporadically in other threads and it's meaning is not documented anywhere that I have seen.

Official feedback on any of this would be welcome.

0 Bill Derby over 7 years ago in reply to Bill Derby

Intellectual 420 points

I now have the deqp gles2 test running to completion (failing 89% of tests - most of which are related to the ReadPixel error.

the deqp egl test runs for quite a while (and also has MANY readpixel errors but sigsegv's in the multi-thread tests at the moment.

I've added more instrumentation to this to try and determine the parameters of the glReadPixels failure and can report the following:

a. glReadPixels fails silently - The PVR error message does not actually cause the call to fail from GL's point of view i.e.glGetError does not return any codes indicating failure.

b. the test program is specifying format: GL_RGBA and type : GL_UNSIGNED_BYTE which should be legal according to the spec.

c. I put in calls to read the GL_IMPLEMENTATION_COLOR_READ_FORMAT and GL_IMPLEMENTATION_COLOR_READ_TYPE and got a wacky (undefined) value for the format:

type = 0x1401 (GL_UNSIGNED_BYTE - as expected)

format = 0x80E1! - this is not a defined format type from the GL2 headers..

regardless, I proceeded to force these parameters into the read call and got the same PVR error, no data and no GL reported error

forcing the format to GL_RGB which should also work causes the the glReadPixels to report an error code (IIRC 0x502)

0 Bill Derby over 7 years ago in reply to Yordan Kovachev

Intellectual 420 points

Yordan - it's been 3 weeks - can you provide any feedback on this issue (factory team or otherwise)? Even if it's "the guy who did the original work left the company/was a contractor and there is no one to talk to who knows anything about it" would be better than no response at all. For my part I will put my patched deqp up on gittorious so that other can run the tests. I almost have the egl specific test running to completion though I have had to pull out many of the multi-threaded tests because they cause segv withing the GLESv2 library. Both deqp-egl and deqp-gles2 test suites produce large results file which shows the test log.

0 Yordan Kovachev over 7 years ago in reply to Bill Derby

TI__Guru**** 161600 points

Hi Bill,

I've sent a reminder, but haven't heard back (perhaps the graphics developers are overloaded). Let me escalate this.

Best Regards,
Yordan

0 Bill Derby over 7 years ago in reply to Yordan Kovachev

Intellectual 420 points

Thanks Yordan,

I am apparently unable to create a project on gitorious (not a TI employee) so have put up a repo for the hacked up deqp on githib:

github.com/.../deqp-am5728.git

The master branch is just the stock android source, use the AM5728 branch to build for the processor.

note that this is a cmake project and the branch adds a am5728 device/target. Ideally, once things are fixed in the libraries the only remaining patches required would be the am5728.cmake device file and the change to load the openglesv2 library dynamically at which point we can push the changes up to the origin.

Note this still does not run the test to completion but does run for a good 15 minutes before finally sigsegv during the test:

"performance.gles2_shared_render.shared_all.2_threads_2_contexts_big_call"

I built these natively on the am5728 and can provide a tarbal of the binaries and testing directory if it makes things easier if someone want to see what I'm talking about with out having to build everything.

-Bill

0 Eric Ruei over 7 years ago in reply to Bill Derby

TI__Intellectual 2810 points

Hi, Bill:

I am in the process to reproduce and debug the problems that you reported. Thanks a lot for the information!

Can you send us the cmake build options? I cannot figure out how you specify the ARM compiler path, options and the path to the target file system or sysroot.
Should we create a CMAKE_TOOLCHAIN_FILE under /framework/delibs/cmake.

Best regards,

Eric

0 Eric Ruei over 7 years ago in reply to Eric Ruei

TI__Intellectual 2810 points

Hi, Bill:

It is also not clear which platform you choose, is it Linux/Wayland? I have been finally able to build the test suite. However, it is still not clear how to run the test. Are all tests initiated from the test PC and run at the target device through the server? In that case, some of the test program should be compiler for the host machine and the others for the target machine. But I do not see that options at the build procedure. Can you send us a few examples how you run the test suite?!

Best regards,

Eric

0 Eric Ruei over 7 years ago in reply to Eric Ruei

TI__Intellectual 2810 points

Hi, Bill:

Never mind! We were able to build and reproduce the problem. It seems to have something to do with the internal memory allocation and usage at the SGX DDK. We are debugging this issue with Imagination.

Best regards,

Eric

0 Bill Derby over 7 years ago in reply to Eric Ruei

Intellectual 420 points

Hi Eric,

Thanks for following up -- Sorry for the delay I gave up looking for responses for a while and then was on a trip and didn't see a notification email that there updates to the thread - so I apologize for the delay.

To answer your questions - I build and run the test suit locally on the AM5728 using the TI v3.00 SDK as a basis/starting point. (So yes Linux/Wayland) - I am using the current versions of Wayland (1.14.0) and Weston (v. 3.0.0) as the ones in the SDK are also pretty old (v1.9) - this should not matter for the testing. I personally have everything built locally on SATA-II SSD filesystem but you should be able to cross-compile it and use with a NFS filesystem as well. Note gzipped gles2 qpa file is 47Meg so you need to have some disk space available prior to running tests.

For purposes below - I have the following build structure on my machine:

~/deqp (testing directory)
~/support/deqp/build (build directory)

The DEQP suit is a server/harnesss pair that is used to run all the tests locally (not on an external machine). The harness runs a LOT of tests sending results to a server and the server gathers all the results into an gzipped qpa (XML) log (which is HUGE even zipped). There are three apps/modules of interest: execserver, deqp-egl, and deqp-gles2 - The rest test for stuff that doesn't exist on the am5728.

Once DEQP is built you copy the bits and pieces out of the build directory into your test directory (in my case ~/deqp) in the following structure:

~/deqp/
execserver,
deqp-egl,
deqp-gles2,
gles2/
gles3/
gles31/
internal/
test results *.qpa.gz
updateapps* (see below)

these files and subdirectories come from the modules in the build tree. The directories basically contain shaders, etc. used for tests and don't change.
when I do a new build of deqp I just copy over the test apps in a script - updateapps - which is:

#!/bin/sh
cp ~/support/deqp/build/modules/egl/deqp-egl .
cp ~/support/deqp/build/modules/gles2/deqp-gles2 .

So here's is the breakdown:

execserver - this is run first and serves as the logging device (i.e. creates the results qpa). This just listens on a port can be run from anywhere (i.e. terminal)
The server does not shut down between test runs i.e. start after a boot and let in run...

so on my machine:

derbyw[~]$ ./execserver &
Listening on Port 50016

deqp-egl - this is run to execute the EGL test suite- execute from terminal in Wayland/Weston
deqp-gles2 - this is run to execute the GLES2 test suite - execute from terminal in Wayland/Weston

so to run either, from a weston terminal:

derbyw[~]$ cd /deqp
derbyw[~]$ ./deqp-egl
<test spew start.....>

..or..

derbyw[~]$ ./deqp-gles2
<test spew start.....>

**note that the test spew on the console is also being logged in the server (with additional info) as test get further along you will see regions and items pop up etc.

tests can pass, fail, or be not supported - obviously we care about the failing ones..

Build & Deploy

I put all the required changes into my branch on github - So please use the the AM5728 branch not master - i.e. deqp/AM5728.
This has the changes to make the build on the AM528 as well as the deqp patches to make even the simplest of tests pass.

*these patches are hopefully some of the things we can resolve in the library once the library is fixed they should no longer be necessary.

To assist you - I can put tarballs of both my test and build directories (above) on a share and send you a link - let me know if that would help.

-Bill

0 Eric Ruei over 7 years ago in reply to Bill Derby

TI__Intellectual 2810 points

Hi, Bill:

Thank you so much for your detailed instructions! I was able to run the test case and reproduce the problem as I indicated earlier. I did not use the server/client model, in stead, I just copied the deqp executable to the target platform and execute them directly.

I am sorry for the delayed response. It took some time for the SGX vendor to confirm that they were able to pass the specific dEQP test suite at their test platform with the latest SGX DDK. We found that the primary issue is related to a mmap permission problem which has something to do with TI DRM driver code. I am working with the TI kernel team to resolve the root issue. The good news is that there is an easy workaround which can be implemented at the SGX DDK UM and therefore attached find the updated UM libraries.

With the updated the libraries, we can pass most of the dEQP tests and I am looking into the remaining failure cases.

Best regards,

Eric

ddklib.tar

0 Bill Derby over 7 years ago in reply to Eric Ruei

Intellectual 420 points

Thanks Eric,

I think the auto-email that gets sent when a thread is replied to getting stuck in a spam folder somewhere - so I have to explicitly check the thread for replies. Anyway, I apologize for the late response - i'll check back more often.

Unfortunately, when I install the attached files Wayland/Weston will no longer start and it complains about not being able to load libpvrws_WAYLAND.so (more detail below) - which is really odd since it is obviously there in /usr/lib.
which leads me to question is it looking for it in a hardcoded path somewhere else (i.e. /usr/local/lib or some such). I did try putting symbolic links for the file in /usr/lib/gbm and /usr/local/lib but neither worked.

Note: restoring the 5 original files fixes the problem

installation info:
I downloaded the above and extracted to /usr/lib. I made sure all the symbolic links are good. (including the one in /usr/lib/gbm). I ran lddconfig and checked all the symbolic links and everything looks OK.

I would note that you didn't send me a complete set here are all the related files on my machine:

-rwxr-xr-x 1 root root 16780 Nov 22 14:32 libpvrDRMWSEGL.so.1.14.3699939
-rwxr-xr-x 1 root root 19452 Nov 22 14:32 libpvrGBMWSEGL.so.1.14.3699939
-rwxr-xr-x 1 root root 3616 Nov 22 14:32 libpvr_wlegl.so.1.14.3699939
-rwxr-xr-x 1 root root 12600 Nov 22 14:32 libpvrws_WAYLAND.so.1.14.3699939
-rwxr-xr-x 1 root root 8380 Nov 8 18:10 libdbm.so.1.14.3699939

-rwxr-xr-x 1 root root 437592 Aug 21 12:26 libGLESv2.so.1.14.3699939
-rwxr-xr-x 1 root root 6580 Aug 21 12:26 libEGL.so.1.14.3699939
-rwxr-xr-x 1 root root 425456 Aug 21 12:26 libGLES_CM.so.1.14.3699939
-rwxr-xr-x 1 root root 214356 Jul 8 2016 libglslcompiler.so.1.14.3699939
-rw-r--r-- 1 root root 84440 Jul 8 2016 libIMGegl.so.1.14.3699939
-rw-r--r-- 1 root root 8432 Jul 8 2016 libPVRScopeServices.so.1.14.3699939
-rw-r--r-- 1 root root 110384 Jul 8 2016 libsrv_init.so.1.14.3699939
-rw-r--r-- 1 root root 221012 Jul 8 2016 libsrv_um.so.1.14.3699939
-rw-r--r-- 1 root root 974632 Jul 8 2016 libusc.so.1.14.3699939

weston startup error information:

<clip normal start stuff>

loaded module : gbm_pvr.so
found valid GBM backend : gbm_pvr.so
PVR:(Error): Couldn't load WS module libpvrws_WAYLAND.so [0, ]
PVR:(Error): [ 1562-> 1562] < CreateBuffer():859|ERROR> Couldn't get buffer FD[0, ]
PVR:(Error): [ 1562-> 1562] < CreateDrawable():938|ERROR> Error mapping 0 buffer [0, ]

Any Ideas?

0 Eric Ruei over 7 years ago in reply to Bill Derby

TI__Intellectual 2810 points

Hi, Bill:

Let's replace all SGX libraries with the attached ones. The same shall be available at the next PSDK release (4.2).

By the way, we are working with the SGX vendor for the remaining failures.sgxlib.tar

Best regards,

Eric

0 Bill Derby over 7 years ago in reply to Eric Ruei

Intellectual 420 points

Thanks Eric,

I updated my system with the libraries, ran ldconfig, etc. and now it gets farther but weston now dies because it can't create a egl surface. Did the changes fix the errors in the init sequence (i.e. the ones that currently need to be patched?) i.e. should I back out the patches and rebuild weston? Note I am using the latest (or close) weston not the ancient one in the PD.

The following is my weston log after the library change:

[10:50:13.724] weston 3.0.90
http://wayland.freedesktop.org
Bug reports to: bugs.freedesktop.org/enter_bug.cgi
Build: 3.0.0-10-g30941eba-dirty limit new panels to top 75 pixels to avoid OSK coverup (2017-10-05 11:35:07 -0400)
[10:50:13.724] Command line: /usr/bin/weston -Bdrm-backend.so --log=/home/derbyw/weston.log
[10:50:13.725] OS: Linux, 4.4.12-g3639bea54a, #28 SMP PREEMPT Fri Oct 20 10:26:05 EDT 2017, armv7l
[10:50:13.725] Using config file '/home/derbyw/.config/weston.ini'
[10:50:13.729] Output repaint window is 7 ms maximum.
[10:50:13.731] Loading module '/usr/lib/libweston-3/drm-backend.so'
[10:50:13.737] initializing drm backend
[10:50:13.743] logind: session control granted
[10:50:13.745] using /dev/dri/card0
[10:50:13.746] Loading module '/usr/lib/libweston-3/gl-renderer.so'
[10:50:13.762] warning: either no EGL_EXT_platform_base support or specific platform support; falling back to eglGetDisplay.
[10:50:13.771] warning: EGL_EXT_buffer_age not supported. Performance could be affected.
[10:50:13.771] warning: neither EGL_EXT_swap_buffers_with_damage or EGL_KHR_swap_buffers_with_damage is supported. Performance could be affected.
[10:50:13.771] Retrieving EGL client extension string failed.
[10:50:13.771] EGL_KHR_surfaceless_context available
[10:50:13.779] EGL version: 1.4 build 1.14@3699939 (MAIN)
[10:50:13.779] EGL vendor: Imagination Technologies
[10:50:13.779] EGL client APIs: OpenGL_ES
[10:50:13.779] EGL extensions: EGL_IMG_client_api_ogl EGL_KHR_image
EGL_KHR_image_base EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image
EGL_KHR_vg_parent_image EGL_IMG_cl_image EGL_KHR_fence_sync
EGL_IMG_context_priority EGL_IMG_hibernate_process
EGL_IMG_image_plane_attribs EGL_KHR_surfaceless_context
EGL_KHR_wait_sync EGL_KHR_create_context
EGL_WL_bind_wayland_display EGL_EXT_image_dma_buf_import
[10:50:13.779] GL version: OpenGL ES 2.0 build 1.14@3699939 (MAIN)
[10:50:13.779] GLSL version: OpenGL ES GLSL ES 1.00 build 1.14@3699939 (MAIN)
[10:50:13.779] GL vendor: Imagination Technologies
[10:50:13.779] GL renderer: PowerVR SGX 544MP
[10:50:13.779] GL extensions: GL_OES_rgb8_rgba8 GL_OES_depth24
GL_OES_vertex_half_float GL_OES_texture_float
GL_OES_texture_half_float GL_OES_element_index_uint
GL_OES_mapbuffer GL_OES_fragment_precision_high
GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image
GL_OES_EGL_image_external GL_OES_required_internalformat
GL_OES_depth_texture GL_OES_get_program_binary
GL_OES_packed_depth_stencil GL_OES_standard_derivatives
GL_OES_vertex_array_object GL_OES_egl_sync GL_OES_texture_npot
GL_OES_surfaceless_context GL_EXT_discard_framebuffer
GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_multisampled_render_to_texture GL_EXT_shader_texture_lod
GL_EXT_texture_format_BGRA8888 GL_EXT_occlusion_query_boolean
GL_EXT_texture_rg GL_EXT_draw_buffers
GL_EXT_shader_framebuffer_fetch GL_IMG_shader_binary
GL_IMG_texture_compression_pvrtc
GL_IMG_texture_compression_pvrtc2 GL_IMG_texture_npot
GL_IMG_texture_format_BGRA8888 GL_IMG_read_format
GL_IMG_program_binary GL_IMG_uniform_buffer_object
GL_IMG_multisampled_render_to_texture GL_KHR_debug
[10:50:13.779] GL ES 2 renderer features:
read-back format: RGBA
wl_shm sub-image to texture: no
EGL Wayland extension: yes
[10:50:13.799] event0 - [10:50:13.799] palmas_pwron: [10:50:13.799] is tagged by udev as: Keyboard
[10:50:13.799] event0 - [10:50:13.799] palmas_pwron: [10:50:13.799] device is a keyboard
[10:50:13.856] event1 - [10:50:13.856] Logitech USB Receiver: [10:50:13.856] is tagged by udev as: Mouse
[10:50:13.856] event1 - [10:50:13.856] Logitech USB Receiver: [10:50:13.856] device is a pointer
[10:50:13.861] event2 - [10:50:13.861] Logitech USB Receiver: [10:50:13.861] is tagged by udev as: Keyboard
[10:50:13.861] event2 - [10:50:13.861] Logitech USB Receiver: [10:50:13.861] device is a keyboard
[10:50:13.866] event3 - [10:50:13.866] Logitech Logitech USB Keyboard: [10:50:13.866] is tagged by udev as: Keyboard
[10:50:13.866] event3 - [10:50:13.866] Logitech Logitech USB Keyboard: [10:50:13.866] device is a keyboard
[10:50:13.871] event4 - [10:50:13.871] Logitech Logitech USB Keyboard: [10:50:13.871] is tagged by udev as: Keyboard Mouse
[10:50:13.871] event4 - [10:50:13.871] Logitech Logitech USB Keyboard: [10:50:13.871] device is a pointer
[10:50:13.871] event4 - [10:50:13.871] Logitech Logitech USB Keyboard: [10:50:13.871] device is a keyboard
[10:50:13.936] event5 - [10:50:13.936] Logitech Logitech USB Keyboard: [10:50:13.936] is tagged by udev as: Mouse
[10:50:13.936] event5 - [10:50:13.936] Logitech Logitech USB Keyboard: [10:50:13.936] device is a pointer
[10:50:14.097] Registered plugin API 'weston_drm_output_api_v1' of size 12
[10:50:14.098] Chosen EGL config details:
RGBA bits: 8 8 8 8
swap interval range: 1 - 1
[10:50:14.098] failed to create egl surface
[10:50:14.098] failed to create gl renderer output state
[10:50:14.098] Failed to init output gl state
[10:50:14.098] Enabling output "HDMI-A-1" failed.
[10:50:14.098] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
presentation clock: CLOCK_MONOTONIC, id 1
presentation clock resolution: 0.000000001 s
[10:50:14.101] Loading module '/usr/lib/weston/desktop-shell.so'
[10:50:14.105] launching '/usr/bin/maliit-keyboard.sh'
[10:50:14.108] Loading module '/usr/lib/weston/notification-area.so'
[10:50:14.109] Loading module '/usr/lib/weston/dock-manager.so'
[10:50:14.110] Loading module '/usr/lib/weston/launcher-menu.so'
[10:50:14.110] caught signal: 11
[10:50:14.112] 0: /usr/bin/weston (on_caught_signal+0x2c) [0x13f20]
[10:50:14.119] 1: /lib/libc.so.6 (__default_sa_restorer+0x10) [0xb6c9f028]
[10:50:14.119] unw_get_proc_info: -10

for reference, after putting the original libraries back I get this log on weston startup:

[11:20:22.911] weston 3.0.90
http://wayland.freedesktop.org
Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=3.0.90
Build: 3.0.0-10-g30941eba-dirty limit new panels to top 75 pixels to avoid OSK coverup (2017-10-05 11:35:07 -0400)
[11:20:22.911] Command line: /usr/bin/weston -Bdrm-backend.so --log=/home/derbyw/weston.log
[11:20:22.911] OS: Linux, 4.4.12-g3639bea54a, #28 SMP PREEMPT Fri Oct 20 10:26:05 EDT 2017, armv7l
[11:20:22.912] Using config file '/home/derbyw/.config/weston.ini'
[11:20:22.912] Output repaint window is 7 ms maximum.
[11:20:22.912] Loading module '/usr/lib/libweston-3/drm-backend.so'
[11:20:22.916] initializing drm backend
[11:20:22.923] logind: session control granted
[11:20:22.926] using /dev/dri/card0
[11:20:22.926] Loading module '/usr/lib/libweston-3/gl-renderer.so'
[11:20:22.933] warning: either no EGL_EXT_platform_base support or specific platform support; falling back to eglGetDisplay.
[11:20:22.940] warning: EGL_EXT_buffer_age not supported. Performance could be affected.
[11:20:22.940] warning: neither EGL_EXT_swap_buffers_with_damage or EGL_KHR_swap_buffers_with_damage is supported. Performance could be affected.
[11:20:22.940] Retrieving EGL client extension string failed.
[11:20:22.940] EGL_KHR_surfaceless_context available
[11:20:22.945] EGL version: 1.4 build 1.14@3699939 (MAIN)
[11:20:22.945] EGL vendor: Imagination Technologies
[11:20:22.945] EGL client APIs: OpenGL_ES
[11:20:22.945] EGL extensions: EGL_IMG_client_api_ogl EGL_KHR_image
EGL_KHR_image_base EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image
EGL_KHR_vg_parent_image EGL_IMG_cl_image EGL_KHR_fence_sync
EGL_IMG_context_priority EGL_IMG_hibernate_process
EGL_IMG_image_plane_attribs EGL_KHR_surfaceless_context
EGL_KHR_wait_sync EGL_KHR_create_context
EGL_WL_bind_wayland_display
[11:20:22.945] GL version: OpenGL ES 2.0 build 1.14@3699939 (MAIN)
[11:20:22.945] GLSL version: OpenGL ES GLSL ES 1.00 build 1.14@3699939 (MAIN)
[11:20:22.945] GL vendor: Imagination Technologies
[11:20:22.945] GL renderer: PowerVR SGX 544MP
[11:20:22.945] GL extensions: GL_OES_rgb8_rgba8 GL_OES_depth24
GL_OES_vertex_half_float GL_OES_texture_float
GL_OES_texture_half_float GL_OES_element_index_uint
GL_OES_mapbuffer GL_OES_fragment_precision_high
GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image
GL_OES_EGL_image_external GL_OES_required_internalformat
GL_OES_depth_texture GL_OES_get_program_binary
GL_OES_packed_depth_stencil GL_OES_standard_derivatives
GL_OES_vertex_array_object GL_OES_egl_sync GL_OES_texture_npot
GL_OES_surfaceless_context GL_EXT_discard_framebuffer
GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_multisampled_render_to_texture GL_EXT_shader_texture_lod
GL_EXT_texture_format_BGRA8888 GL_EXT_occlusion_query_boolean
GL_EXT_texture_rg GL_EXT_draw_buffers
GL_EXT_shader_framebuffer_fetch GL_IMG_shader_binary
GL_IMG_texture_compression_pvrtc
GL_IMG_texture_compression_pvrtc2 GL_IMG_texture_npot
GL_IMG_texture_format_BGRA8888 GL_IMG_read_format
GL_IMG_program_binary GL_IMG_uniform_buffer_object
GL_IMG_multisampled_render_to_texture GL_KHR_debug
[11:20:22.946] GL ES 2 renderer features:
read-back format: RGBA
wl_shm sub-image to texture: no
EGL Wayland extension: yes
[11:20:22.963] event0 - [11:20:22.963] palmas_pwron: [11:20:22.964] is tagged by udev as: Keyboard
[11:20:22.964] event0 - [11:20:22.964] palmas_pwron: [11:20:22.964] device is a keyboard
[11:20:23.026] event1 - [11:20:23.026] Logitech USB Receiver: [11:20:23.026] is tagged by udev as: Mouse
[11:20:23.026] event1 - [11:20:23.026] Logitech USB Receiver: [11:20:23.026] device is a pointer
[11:20:23.031] event2 - [11:20:23.031] Logitech USB Receiver: [11:20:23.031] is tagged by udev as: Keyboard
[11:20:23.031] event2 - [11:20:23.031] Logitech USB Receiver: [11:20:23.031] device is a keyboard
[11:20:23.036] event3 - [11:20:23.036] Logitech Logitech USB Keyboard: [11:20:23.036] is tagged by udev as: Keyboard
[11:20:23.036] event3 - [11:20:23.036] Logitech Logitech USB Keyboard: [11:20:23.036] device is a keyboard
[11:20:23.040] event4 - [11:20:23.040] Logitech Logitech USB Keyboard: [11:20:23.040] is tagged by udev as: Keyboard Mouse
[11:20:23.040] event4 - [11:20:23.040] Logitech Logitech USB Keyboard: [11:20:23.040] device is a pointer
[11:20:23.041] event4 - [11:20:23.041] Logitech Logitech USB Keyboard: [11:20:23.041] device is a keyboard
[11:20:23.106] event5 - [11:20:23.106] Logitech Logitech USB Keyboard: [11:20:23.106] is tagged by udev as: Mouse
[11:20:23.106] event5 - [11:20:23.106] Logitech Logitech USB Keyboard: [11:20:23.106] device is a pointer
[11:20:23.257] Registered plugin API 'weston_drm_output_api_v1' of size 12
[11:20:23.257] Chosen EGL config details:
RGBA bits: 8 8 8 8
swap interval range: 1 - 1
[11:20:23.291] cursor buffers unavailable, using gl cursors
[11:20:23.291] Failed to initialize backlight
[11:20:23.291] EDID data 'ACR', 'Acer S231HL', 'LWKAA0014340'
[11:20:23.291] Output HDMI-A-1, (connector 27, crtc 29)
mode 1920x1080@60.0, preferred, current
mode 1680x1050@59.9
mode 1280x1024@60.0
mode 1440x900@59.9
mode 1280x800@59.9
mode 1152x864@75.0
mode 1280x720@60.0
mode 1024x768@70.1
mode 1024x768@60.0
mode 800x600@60.3
mode 800x600@56.2
mode 640x480@66.7
mode 640x480@60.0
mode 720x400@70.1
[11:20:23.292] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
presentation clock: CLOCK_MONOTONIC, id 1
presentation clock resolution: 0.000000001 s
[11:20:23.292] Loading module '/usr/lib/weston/desktop-shell.so'
[11:20:23.293] launching '/usr/bin/maliit-keyboard.sh'
[11:20:23.295] Loading module '/usr/lib/weston/notification-area.so'
[11:20:23.296] Loading module '/usr/lib/weston/dock-manager.so'
[11:20:23.296] Loading module '/usr/lib/weston/launcher-menu.so'
[11:20:23.297] launching '/usr/libexec/weston-desktop-shell'
[11:20:25.238] panel surface gone
[11:20:25.238] background surface gone
[11:20:25.258] event0 - [11:20:25.258] palmas_pwron: [11:20:25.258] device removed
[11:20:25.259] event1 - [11:20:25.259] Logitech USB Receiver: [11:20:25.259] device removed
[11:20:25.260] event2 - [11:20:25.260] Logitech USB Receiver: [11:20:25.260] device removed
[11:20:25.260] event3 - [11:20:25.260] Logitech Logitech USB Keyboard: [11:20:25.260] device removed
[11:20:25.261] event4 - [11:20:25.261] Logitech Logitech USB Keyboard: [11:20:25.261] device removed
[11:20:25.261] event5 - [11:20:25.261] Logitech Logitech USB Keyboard: [11:20:25.261] device removed

0 Eric Ruei over 7 years ago in reply to Bill Derby

TI__Intellectual 2810 points

Hi, Bill:

I have tried several combination, but not be able to reproduce your issue with the latest SGX DDK local builds.
There are only minor changes within the SGX DDK and most of them are bug fixes, including the fix to enable dmabuf RDWR, which resolves most of the dEQP failures. There were no API or Weston interface changes, therefore, you do need to keep all the Weston patches.

I do not know why Weston fail with new SGX DDK release, you may want to rebuild the Weston/Wayland against the SGX DDK binaries, although, it is not required for my test environment. You may also add some debug code around eglCreateWindowSurface() at gl-renderer.c. Is it possible that you can run your test on top of the PSDK release? It is pretty hard to debug at two different build and test environments. If you would like, I can send you the SGX binaries with some debug traces enabled.

Here is the latest Weston log with some SGX trace printouts:

[02:54:43.528] weston 1.11.0
               http://wayland.freedesktop.org
               Bug reports to: bugs.freedesktop.org/enter_bug.cgi
               Build: 1.10.93-2-g2d825ed configure.ac: bump to version 1.11.0 for the official release (2016-05-31 17:10:40 -0700)
[02:54:43.528] OS: Linux, 4.9.45-g0d315629c7, #1 SMP PREEMPT Tue Nov 14 15:53:23 EST 2017, armv7l
[02:54:43.529] Using config file '/etc//weston.ini'
[02:54:43.530] Output repaint window is 7 ms maximum.
[02:54:43.531] Loading module '/usr/lib/weston/drm-backend.so'
[02:54:43.539] initializing drm backend
[02:54:43.541] using /dev/dri/card0
[02:54:43.541] Loading module '/usr/lib/weston/gl-renderer.so'
failed to load module: /usr/lib/gbm/gbm_dri.so: cannot open shared object file: No such file or directory
failed to load module: /usr/lib/gbm/gbm_gallium_drm.so: cannot open shared object file: No such file or directory
loaded module : gbm_pvr.so
found valid GBM backend : gbm_pvr.so
root@am57xx-evm:/usr/lib/weston# [02:54:43.594] warning: either no EGL_EXT_platform_base support or specific platform support; falling back to eglGetDisplay.
PVR: IsDisplayValid 0x4d4d0
PVR: InitialiseDisplay
[02:54:43.613] warning: EGL_EXT_buffer_age not supported. Performance could be affected.
[02:54:43.613] Retrieving EGL client extension string failed.
[02:54:43.641] input device 'pixcir_tangoc', /dev/input/event1 is tagged by udev as: Touchscreen
[02:54:43.641] input device 'pixcir_tangoc', /dev/input/event1 is a touch device
[02:54:43.644] input device 'DELL Dell USB Entry Keyboard', /dev/input/event2 is tagged by udev as: Keyboard
[02:54:43.644] input device 'DELL Dell USB Entry Keyboard', /dev/input/event2 is a keyboard
[02:54:43.708] input device 'USB Optical Mouse', /dev/input/event3 is tagged by udev as: Mouse
[02:54:43.708] input device 'USB Optical Mouse', /dev/input/event3 is a pointer caps
[02:54:43.709] input device 'gpio_keys', /dev/input/event0 is tagged by udev as: Keyboard
[02:54:43.709] input device 'gpio_keys', /dev/input/event0 is a keyboard
PVR: IMGeglCreateWindowSurface
PVR: IMGeglCreateWindowSurface: call CreateWindowDrawable
PVR: CreateWindowDrawable: create surface
PVR: IMGeglCreateWindowSurface: call CreateWindowDrawable = 0
[02:54:43.766] EGL version: 1.4 build 1.14@3699939 (MAIN)
[02:54:43.766] EGL vendor: Imagination Technologies
[02:54:43.766] EGL client APIs: OpenGL_ES
[02:54:43.766] EGL extensions: EGL_IMG_client_api_ogl EGL_KHR_image
               EGL_KHR_image_base EGL_KHR_gl_texture_2D_image
               EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image
               EGL_KHR_vg_parent_image EGL_IMG_cl_image EGL_KHR_fence_sync
               EGL_IMG_context_priority EGL_IMG_hibernate_process
               EGL_IMG_image_plane_attribs EGL_KHR_surfaceless_context
               EGL_KHR_wait_sync EGL_KHR_create_context
               EGL_WL_bind_wayland_display EGL_EXT_image_dma_buf_import
[02:54:43.767] GL version: OpenGL ES 2.0 build 1.14@3699939 (MAIN)
[02:54:43.767] GLSL version: OpenGL ES GLSL ES 1.00 build 1.14@3699939 (MAIN)
[02:54:43.767] GL vendor: Imagination Technologies
[02:54:43.767] GL renderer: PowerVR SGX 544MP
[02:54:43.767] GL extensions: GL_OES_rgb8_rgba8 GL_OES_depth24
               GL_OES_vertex_half_float GL_OES_texture_float
               GL_OES_texture_half_float GL_OES_element_index_uint
               GL_OES_mapbuffer GL_OES_fragment_precision_high
               GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image
               GL_OES_EGL_image_external GL_OES_required_internalformat
               GL_OES_depth_texture GL_OES_get_program_binary
               GL_OES_packed_depth_stencil GL_OES_standard_derivatives
               GL_OES_vertex_array_object GL_OES_egl_sync GL_OES_texture_npot
               GL_OES_surfaceless_context GL_EXT_discard_framebuffer
               GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
               GL_EXT_multisampled_render_to_texture GL_EXT_shader_texture_lod
               GL_EXT_texture_format_BGRA8888 GL_EXT_occlusion_query_boolean
               GL_EXT_texture_rg GL_EXT_draw_buffers
               GL_EXT_shader_framebuffer_fetch GL_IMG_shader_binary
               GL_IMG_texture_compression_pvrtc
               GL_IMG_texture_compression_pvrtc2 GL_IMG_texture_npot
               GL_IMG_texture_format_BGRA8888 GL_IMG_read_format
               GL_IMG_program_binary GL_IMG_uniform_buffer_object
               GL_IMG_multisampled_render_to_texture GL_KHR_debug
[02:54:43.767] GL ES 2 renderer features:
               read-back format: RGBA
               wl_shm sub-image to texture: no
               EGL Wayland extension: yes
[02:54:43.767] Chosen EGL config details:
               RGBA bits: 8 8 8 8
               swap interval range: 1 - 1
[02:54:43.767] cursor buffers unavailable, using gl cursors
[02:54:43.768] Initialized backlight, device /sys/class/backlight/backlight
[02:54:43.768] Applying calibration: 0.995683 0.025841 -14.223816 0.013122 0.973577 -10.893066 (normalized -0.017780 -0.022694)
[02:54:43.769] Output UNNAMED-1, (connector 31, crtc 34)
               mode 800x480@59.5, preferred, current
[02:54:43.769] Compositor capabilities:
               arbitrary surface rotation: yes
               screen capture uses y-flip: yes
               presentation clock: CLOCK_MONOTONIC, id 1
[02:54:43.769] Loading module '/usr/lib/weston/desktop-shell.so'
[02:54:43.770] launching '/usr/libexec/weston-keyboard'
[02:54:43.771] launching '/usr/libexec/weston-desktop-shell'

Best regards,

Eric

0 Bill Derby over 7 years ago in reply to Eric Ruei

Intellectual 420 points

Eric,

Yes, An instrumented library build would be most useful: I have custom hardware so using the using the AM5728 PDK would not be a simple change - as each time I change I have to apply the patches from SOM vendor (compulab) and then reapply all my changes for my hardware as well including the changes to the DTB. The pdk I'm running on is : ti-processor-sdk-linux-am57xx-evm-03.00.00.04 and is heavily augmented to add the stuff I need for my project. (i.e. I needed current versions of libraries, apps, which necessitated upgrades to libraries, etc. - 60+ packages in all).

I would note that the following errors are coming out of the PVR libraries themselves:

PVR:(Error): [ <pid>-> <pid>] < CreateBuffer():859|ERROR> Couldn't get buffer FD[0, ]

PVR:(Error): [ <pid>-> <pid>] < CreateDrawable():938|ERROR> Error mapping 0 buffer [0, ]

Comparing the logs from the 2 runs:

the new libraries display: EGL_WL_bind_wayland_display EGL_EXT_image_dma_buf_import

vs. the original : EGL_WL_bind_wayland_display

this is expected per your changes but may be causing a new code execution path (which I will try to track down).

I have started to instrument weston and can confirm the code does die on : eglCreateWindowSurface

I added a few quick logs messages and egl_choose_config is picking the same config (0) out of 22 and the visual_id is the same for both cases)

my next mode is to compile a debug version and run GDB on it so I trace more effecively.

Prior to that I decided to give strace and apparently the it dies on an ioctl : DRM_IOCTL_PRIME_HANDLE_TO_FD

Running strace on weston gives the following beadcrumbs (showing :

<snip...>

ioctl(16, DRM_IOCTL_MODE_GETENCODER, 0xbea80474) = 0
ioctl(16, DRM_IOCTL_MODE_GETCRTC, 0xbea80418) = 0
ioctl(16, DRM_IOCTL_MODE_GETPROPERTY, 0xbea80450) = 0
ioctl(16, DRM_IOCTL_MODE_GETPROPERTY, 0xbea80450) = 0
ioctl(16, DRM_IOCTL_MODE_GETPROPERTY, 0xbea80450) = 0
ioctl(16, DRM_IOCTL_MODE_GETPROPERTY, 0xbea80450) = 0
ioctl(16, DRM_IOCTL_MODE_CREATE_DUMB, 0xbea80368) = 0
ioctl(16, DRM_IOCTL_MODE_CREATE_DUMB, 0xbea80368) = 0
ioctl(16, DRM_IOCTL_MODE_CREATE_DUMB, 0xbea80368) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
write(3, "[11:49:37.634] Chosen EGL config"..., 42) = 42
write(3, " RGBA bits: 8 8 8 "..., 34) = 34
write(3, " swap interval ran"..., 42) = 42
ioctl(16, DRM_IOCTL_PRIME_HANDLE_TO_FD, 0xbea80384) = -1 EINVAL (Invalid argument)
getpid() = 2288
gettid() = 2288
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 1), ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "PVR:(Error): [ 2288-> 2288] < "..., 107) = 107
getpid() = 2288
gettid() = 2288
write(1, "PVR:(Error): [ 2288-> 2288] < "..., 107) = 107
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
write(3, "[11:49:37.636] failed to create "..., 44) = 44
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
write(3, "[11:49:37.636] failed to create "..., 57) = 57
ioctl(16, DRM_IOCTL_MODE_DESTROY_DUMB, 0xbea80444) = 0
ioctl(16, DRM_IOCTL_MODE_DESTROY_DUMB, 0xbea80444) = 0
ioctl(16, DRM_IOCTL_MODE_DESTROY_DUMB, 0xbea80444) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
write(3, "[11:49:37.637] Failed to init ou"..., 46) = 46
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
write(3, "[11:49:37.637] Enabling output \""..., 50) = 50
rt_sigaction(SIGSEGV, {0x13ef4, [], SA_RESTORER|SA_RESETHAND|SA_SIGINFO, 0xb6cb6020}, NULL, 8) = 0
rt_sigaction(SIGABRT, {0x13ef4, [], SA_RESTORER|SA_RESETHAND|SA_SIGINFO, 0xb6cb6020}, NULL, 8) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
write(3, "[11:49:37.638] Compositor capabi"..., 40) = 40
write(3, " arbitrary surface"..., 47) = 47

<snip...>

0 Bill Derby over 7 years ago in reply to Bill Derby

Intellectual 420 points

Actually looking at your logs and the program execution I am definitely NOT seeing the highlighted PVR calls that happen way earlier than the
eglCreate call.
i.e.

PVR: IsDisplayValid 0x4d4d0
PVR: InitialiseDisplay

(and the following PVR: IMGeg* messages)

Which means I'm debugging in the wrong spot. -- can you tell me what calls cause the missing PVR: log messages? in the meantime I will make sure there are no old libraries in /usr/local/bin etc. that may be getting pulled in..

0 Eric Ruei over 7 years ago in reply to Bill Derby

TI__Intellectual 2810 points

Hi, Bill:

Thank you for the detailed debug information! I did not realize that you used such an old version of PSDK with lots of custom libraries.

It is clear that we still face some sort of DRM permission issue, which I have tried to address for almost a month, according to your error log.

ioctl(16, DRM_IOCTL_PRIME_HANDLE_TO_FD, 0xbea80384) = -1 EINVAL (Invalid argument)

The primary change we made was to add new flag DRM_RDWR to this call and I heard from the vendor that this flag did not work for kernel 4.5 and/or some DRM drivers. Please note that this flag is required for TI PSDK 3.x releases with kernel 4.4 and PSDK 4.x with kernel 4.9 to resolve the dEQP glReadPixels() issue, and the following error will show without it.

PVR:(Error): PVRSRVMapDmaBuf: Failed to acquire user CPU mapping (errno 13) [0, ]

To fix the dEQP issues, we have made the following two set of changes.

1. add DRM_RDWR flag to API call drmPrimeHandleToFD() to enable R/W permission.
2. remove PVRSRV_MAP_NOUSERVIRTUAL flag from PVR Map calls, which disables the CPU access to framebuffer and so that breaks glReadPixels()

Please note that both change #1 and the PVRSRV_MAP_NOUSERVIRTUAL flag are not required at the vendor test environment.
For TI test environment, we need ether both changes or PVRSRV_MAP_NOUSERVIRTUAL flag to avoid the error shown above.

It seems to me that your test environment is more like the one at our vendor. Attached please find a set of libraries with change #2 only, i.e. the same as the original release from our vendor.

Please try to see whether it resolve the system startup issue.

Best regards,

Eric

sgxlib2.tar

0 Bill Derby over 7 years ago in reply to Eric Ruei

Intellectual 420 points

Sadly no - mine dies with PVR:(Error): PVRSRVMMapDmaBuf: Failed to acquire user CPU mapping (errno 13) [0, ]

I assume the DRM ioctl is calling into the PVR kernel module - so is there something amiss there? i.e. why is the TI case different than the vendor system?

regarding my system, most of the custom libraries other than libc are much higher up the application stack. and I didn't see anything in the strace that would implicate that stuff.

since this is permission related, I should note the following as well - the PSDK (at least the v.3) had a pretty goofy
inid script for starting weston which ended up starting it directly as root - i.e. apps including terminal ran as root!.

On my system I fixed all that and weston is started with user permissions using the proper weston-launch code. The init at the user level looks like so:

# run this from a virtual console..
# Start the D-Bus session daemon
eval `dbus-launch`
export DBUS_SESSION_BUS_ADDRESS
#export WAYLAND_DEBUG=client

export EGL_LOG_LEVEL=debug

# tell GTK about the wayland input module
#export GTK_IM_MODULE=wayland

# generate extra Maliit info...
#export MALIIT_DEBUG=1

# kick off weston as this user
weston-launch -v -- -Bdrm-backend.so --log=/var/tmp/weston.log

# Kill the D-Bus session daemon
kill $DBUS_SESSION_BUS_PID

< end of script >

FYI - In case this was an issue, I also started weston as root with the same results.

it looks like to move forward I would be best served by biting the bullet and moving my system to to a newer PSDK to resolve this - sadly this may take days/weeks to do and I would avoid it if I possibly could. I suppose I can try the vanilla PSDK over NFS and get the the dtb and kernel built and then try the libraries to see if they work before moving all the rest of the stuff.

I assume I should use the latest (I have psdk 4.01.00.06 installed but not modified yet) perhaps I can just upgrade the kernel and drivers and try to keep the rest the same?

0 Eric Ruei over 7 years ago in reply to Bill Derby

TI__Intellectual 2810 points

Hi, Bill:

The error "PVR:(Error): PVRSRVMMapDmaBuf: Failed to acquire user CPU mapping (errno 13) [0, ]" is triggered by the permission error from mmap and that is why we would need to add DRM_RDWR flag to the function drmPrimeHandleToFD which should invoke the ioctl call to the DRM device driver. The ioctl DRM_IOCTL_PRIME_HANDLE_TO_FD with the DRM_RDWR flag is rejected by your drm (kernel) driver. Could you find where and how that happened with the previous libraries that I sent to you. Then we can go from that.

With all PSDK releases that I tried, we can maintain the two fixes that I mentioned earlier and the glReadPixels() issue is resolved.
At our vendor test environment, the DRM_RDWR flag is not required and their mmap does not return permission error and therefore there is no issue for glReadPixels().
At your test environment, the DRM_RDWR flag is not allowed for drmPrimeHandleToFD(), however, the mmap will return permission error without this flag. It may be caused by mismatched user mode and kernel drivers.

Best regards,

Eric

0 Bill Derby over 7 years ago in reply to Eric Ruei

Intellectual 420 points

>The ioctl DRM_IOCTL_PRIME_HANDLE_TO_FD with the DRM_RDWR flag is rejected by your drm (kernel) driver. Could you find where and how that happened with the previous libraries that I sent to you. Then we can go from that.

It's not quite clear what you want me to do. just so I understand, a few questions: Do you want me to find the call in the original working library or the sgxlib.tar. I can run strace on them or trace into it with gdb - and do a full stack dump at the call.

I have attached the complete strace from the first sgxlib.tar you sent:

here is the call:

write(3, "[11:49:37.634] Chosen EGL config"..., 42) = 42
write(3, " RGBA bits: 8 8 8 "..., 34) = 34
write(3, " swap interval ran"..., 42) = 42
ioctl(16, DRM_IOCTL_PRIME_HANDLE_TO_FD, 0xbea80384) = -1 EINVAL (Invalid argument)
getpid() = 2288
gettid() = 2288

so the call happens right after log_egl_config_info in gl_renderer_create_window_surface - which is our old friend eglCreateWindowSurface. -- which lives in the sgxlibraries..

Assuming the gdb trace approach is easier - Could you send the files compiled with -g to tracing this easier? if that's not possible due to licensing can you turn on any debugging and or add log messages?

egl_strace.2288.gz

0 Bill Derby over 7 years ago in reply to Bill Derby

Intellectual 420 points

For comparison, here is the strace on the original sgx libraries - with passing DRM_IOCTL_PRIME_HANDLE_TO_FD call.

original_egl_strace.gz

0 Eric Ruei over 7 years ago in reply to Bill Derby

TI__Intellectual 2810 points

Hi, Bill:

What I meant was whether you can trace the kernel driver code for the ioctl DRM_IOCTL_PRIME_HANDLE_TO_FD processing to find out where it is rejected due to the flag DRM_RDWR? Then we need to trace the kernel driver regarding the mmap call with the last package sgxlib2.tar.\

Best regards,

Eric

0 Eric Ruei over 7 years ago in reply to Eric Ruei

TI__Intellectual 2810 points

Hi, Bill:

I am able to reproduce the same problem as you observed with the PSDK 3.0.0.4 release. The DRM_RDWR flag is rejected for ioctl DRM_IOCTL_PRIME_HANDLE_TO_FD but the PVRSRVMapDmaBuf call returns error without it and the glReadPixels() will not be supported with the original workaround . The problem is most likely at the omapdrm driver, which has been fixed at the newer release. I shall look for the fixes and evaluate whether a few simple patches are possible.

It may be better for you to upgrade to the latest PSDK release with the first sgxlib.tar I sent earlier. If you must use kernel 4.4, you may try PSDK 3.3.0.4.

Best regards,

Eric

0 Bill Derby over 7 years ago in reply to Eric Ruei

Intellectual 420 points

Thanks Eric,

Thanks I already started doing just that against the 4.01.00.66 PSDK. It seemed like that was the way things were heading - hopefully it won't be too painful. I have the first stab at the kernel/dts changes and am trying to test/boot now. Once I get a system that can get me to a prompt I'll give the SGX things a try (before adding all my other stuff in)

-Bill

0 Eric Ruei over 7 years ago in reply to Bill Derby

TI__Intellectual 2810 points

Hi, Bill:

Attached please find the simple patch which is applicable to kernel 4.4.12 (PSDK 3.0.0,4) and will resolve the DRM permission problem.
It should work with the first sgxlib.tar that I sent you earlier.

Best regards,

Eric

drm_patch.tar

0 Bill Derby over 7 years ago in reply to Eric Ruei

Intellectual 420 points

Hi Eric,

Thanks! The supplied patch coupled with the first sgxlib now allows weston to start - so we're making progress! I am also working on moving the system to the latest PSDK but ran into device tree issues in the process (separate thread). Now my Deqp results are as follows:

EGL

Test run totals:

Passed: 1006/3843 (26.2%)

Failed: 84/3843 (2.2%)

Not supported: 2753/3843 (71.6%)

Warnings: 0/3843 (0.0%)

GLES2

Test run totals:

Passed: 7286/7782 (93.6%)

Failed: 446/7782 (5.7%)

Not supported: 50/7782 (0.6%)

Warnings: 0/7782 (0.0%)

So not completely passing yet but definitely MUCH better results than before - However this is running with the patched deqp - I had to comment out a bunch of tests so the deqp apps would run to completion (i.e. the tests caused sigsegv crashes) - see the github for the mods. Anyway I'll see if I can remove these and see if the change fixed the crashes.

Also, in all the churn with the sgx patches I want to draw attention to the fact that I had to patch the deqp apps to even run in the first place. The init sequence for all these apps is broken by 2 issues in the TI psdk which are addressed in the following patches (to weston):

0001-udev-seat-restrict-udev-enumeration-to-card0

Background:

the GPU's in the system show up in /dev/dri as cardX all the low level graphics apps look for this to initialize the GPU with this code

(or a very close varient): udev_enumerate_add_match_sysname(e, "card[0-9]*");

On typical systems there is only one card (/dev/dri/card0) and all goes well.

On the AM5728 though there are 2 cards: card0 and card1 but these are not the same thing.

card0 is the actual GPU and card1 is ??? (a render node is implied) it is unclear what uses this "card" that's not a display GPU.

unfortunately the call udev_enumerate_add_match_sysname(e, "card[0-9]*"); chooses the highest card (i.e. card1) and the init fails.

The referenced patch forces the call to only match card0 by changing it to:

udev_enumerate_add_match_sysname(e, "card0");

which works, but now that patch now needs to be applied to everything that would do an EGL init. (weston, DEQP, enlightenment, X)

the rational for the patch is as follows:

In case of separate GPU and Display devices as found in embedded systems, we

could have modeset node and render node controlled by different drivers.

There is a distinct possibility that udev enumeration returns the DRM device

corresponding to render node as the primary DRM device.

note: "a distinct possibility" == 100%!

This make sense until it is noted that there ARE dri render devices (/dev/dri/renderD128) so there is no need for the second "card"

in the first place. (see dvdhrm.wordpress.com/.../ from 2013 for background) if something wants a render device it should not be

looking for a cardx. I would note that there is a /dev/dri/renderD128 node on my machine - so what is card1 anyway?

Note: Removing or changing the card1 to a render node would allow any new code to work unpatched and because the card0 would be the only card, the patched

code would also continue to work. The only change would be that any code explictly looking for a render node would need to look not for card1 but renderxxx.

0002-Weston1.9.0-Allow-visual_id-to-be-0.patch

this one is also a killer of all egl inits and has zero rationale from what I can tell. The patch info is as follows:

The inquiry of visual id from egl API eglGetConfigAttrib(EGL_NATIVE_VISUAL_ID)

is an optional feature. The visual id will be set to 0 if this feature is

not supported. Therefore, the return condition @function match_config_to_visual()

should be (id == visual_id || id == 0) instead of (id == visual_id)

So what this function is supposed to do is return the "native" visual id so that the configuration can choose the one that

matches the native hardware ie. "best" match to capabilities. the visual ID is then used to select from a list of

available configurations (I get 22 on my machine).

The patch asserts EGL_NATIVE_VISUAL_ID is "optional" but I see absolutely nothing to support that in the spec. It is not optional,

it is just broken in the EGL imlementation. If the library doesn't support EGL_NATIVE_VISUAL_ID is should return EGL_FALSE, but it instead it passes

and returns 0 - which not a valid visual ID - and so the patch simply "matches" the first config in the list. This works but is clearly a hack:

why is the first one the best?, if the first is why not return it properly and avoid hacking up everyone else's init code.

The eglGetConfigAttrib function is documented here: www.khronos.org/.../eglGetConfigAttrib.xhtml

Like the above, fixing eglGetConfigAttrib(EGL_NATIVE_VISUAL_ID) to return a valid visual ID (even if it's just the ID of the first config) will not

break any existing patched code (since visual_id will no longer be 0) but will remove the need for future patches.

Processors

Processors forum

Linux/AM5728: Updated EGL/GLES/PVR libraries