> Am 09.03.2019 um 22:08 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>: > > On Sat, 9 Mar 2019 21:48:28 +0100 > H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> wrote: > >> Hi Phillipp and all, >> >>> Am 25.02.2019 um 21:42 schrieb Philipp Rossak <embed3d@xxxxxxxxx>: >>> >>> >>> >>> On 25.02.19 14:12, H. Nikolaus Schaller wrote: >>>> Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and >>>> jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to >>>> find replacements or API changes. Compile for Intel is not tested. >>> >>> I will have a look on the sunxi issue in the next days. >> >> do you already have done some test and got findings/patches/suggestions? Or something where I could help? >> >> >> I have some progress to get the DDK1.14 on v5.0 running on omap3/4/5. >> >> The main issue so far was that I did not have matching "compatible" entries in the device tree so >> that probing the module did not succeed. And I had to port the CONFIG_RESET_CONTROLLER >> setup for omap. >> >> But then it started working. >> >> >> Here on omap5: >> >> root@letux:~# ./gpu-demo >> autodetected driver package: omap5-sgx544-116 >> compatible driver: omap_omap5_sgx544_116 >> module name: pvr_omap_omap5_sgx544_116 >> pvrsrvctl: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender >> System Version String: None >> Running gles1test1 >> gles1test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender >> Running gles2test1 >> --------------------- started --------------------- >> gles2test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender >> Running eglinfo >> eglinfo: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender >> root@letux:~# >> >> And on omap3: >> >> root@letux:~# ./gpu-demo >> autodetected driver package: omap3630-sgx530-125 >> compatible driver: omap_omap3630_sgx530_125 >> module name: pvr_omap_omap3630_sgx530_125 >> pvrsrvctl: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender >> System Version String: None >> Running sgx_clipblit_test >> ----------------- SGX CLipBlit test ----------------- >> ---------------------- Start ------------------------ >> Call PVRSRVConnect with a valid argument: >> sgx_clipblit_test: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so: undefined symbol: drmOpenRender >> Running gles1test1 >> gles1test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender >> Running gles2test1 >> --------------------- started --------------------- >> gles2test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender >> Running eglinfo >> eglinfo: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender >> root@letux:~# >> >> >> I am not sure where the user-space library problems come from. I think I have the correct DDK1.14 user space for >> omap from >> >> git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git >> >> but you never know: >> >> http://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/p/567306/2081687 >> >> But maybe it is simply because the -D flags of my in-kernel Makefile are not yet exactly correct. >> > Hmm, usually this symbol comes from the standard libdrm.so. Yes, that is what I also was thinking. For some reason the libdrm.so on my Debian Jessie has all symbols stripped: root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm.so nm: /usr/lib/arm-linux-gnueabihf/libdrm.so: no symbols root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm.so.2 nm: /usr/lib/arm-linux-gnueabihf/libdrm.so.2: no symbols root@letux:~# nm /usr/lib/arm-linux-gnueabihf/libdrm_omap.so nm: /usr/lib/arm-linux-gnueabihf/libdrm_omap.so: no symbols root@letux:~# And the package libdrm-dbg does not provide a version with symbols. > Maybe it is > somehow not compatible/not found/whatever, or the libsrv_um.so.1 > library is not linked against that, so the application has to. Ok, the application shows: root@letux:~# ldd /usr/local/omap3-pvrsgx/bin/gles1test1 libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0xb6f82000) libgbm.so.2 => /usr/local/omap3-pvrsgx/lib/libgbm.so.2 (0xb6f68000) libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0xb6f4e000) libwayland-server.so.0 => /usr/lib/arm-linux-gnueabihf/libwayland-server.so.0 (0xb6f34000) libdrm_omap.so.1 => /usr/lib/arm-linux-gnueabihf/libdrm_omap.so.1 (0xb6f21000) libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0xb6f0b000) libsrv_um.so.1 => /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1 (0xb6ed4000) libdbm.so.1 => /usr/local/omap3-pvrsgx/lib/libdbm.so.1 (0xb6ec2000) libusc.so.1 => /usr/local/omap3-pvrsgx/lib/libusc.so.1 (0xb6e09000) libIMGegl.so.1 => /usr/local/omap3-pvrsgx/lib/libIMGegl.so.1 (0xb6de4000) libEGL.so.1 => /usr/local/omap3-pvrsgx/lib/libEGL.so.1 (0xb6dd2000) libGLES_CM.so.1 => /usr/local/omap3-pvrsgx/lib/libGLES_CM.so.1 (0xb6d69000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6c79000) /lib/ld-linux-armhf.so.3 (0xb6fb1000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6c05000) libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xb6bdd000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6bca000) libwayland-client.so.0 => /usr/lib/arm-linux-gnueabihf/libwayland-client.so.0 (0xb6bb1000) libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0xb6b74000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6b51000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6b3b000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6b12000) root@letux:~# Ah, maybe an strace reveals more. BR and thanks, Nikolaus
