Closed lbernstone closed 5 years ago
There are two mali blobs, one for fbdev and one for GBM. Check if you can run: https://github.com/avafinger/bananapi-zero-ubuntu-base-minimal#mali-gbm-test if you get a similar error you possibly lost the opengl links to mali, try that first and get the results.
Ok, checked the mali blobs. They look good. In slightly different locations, but everything seems to be linked back into the lib directory properly. Was missing libgbm.so link, so I made that. Now I get to a sun4i-drm driver issue:
$ ./kmscube
gbm: failed to open any driver (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
gbm: Last dlopen error: /usr/lib/dri/sun4i-drm_dri.so: cannot open shared object file: No such file or directory
failed to load driver: sun4i-drm
./kmscube: symbol lookup error: ./kmscube: undefined symbol: eglQueryString
If i recall correctly you can restore the links (if you have not changed things or removed opengles or so):
Please try this and run again, fbdev and gbm.
cd /lib/arm-linux-gnueabihf
sudo cp -avf /usr/mali/lib/* .
The mali-blob stuff all looks good. sun4i-drm_dri.so is not located anywhere on the system though.
Looks like you have fbdev mali blobs and not for the gbm. Please run the sudo glmark2-es2-fbdev
The modules seem to be loaded OK:
pi@bpi-m2z:~$ dmesg | grep sun[48]
[ 0.152414] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
[ 0.156672] sun8i-h3-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[ 0.158378] sun8i-h3-r-pinctrl 1f02c00.pinctrl: initialized sunXi PIO driver
[ 0.983723] dwmac-sun8i 1c30000.ethernet: PTP uses main clock
[ 0.989523] dwmac-sun8i 1c30000.ethernet: No regulator found
[ 0.995426] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported
[ 1.002666] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported
[ 1.009894] dwmac-sun8i 1c30000.ethernet: COE Type 2
[ 1.014853] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported
[ 1.021644] dwmac-sun8i 1c30000.ethernet: Normal descriptors
[ 1.027306] dwmac-sun8i 1c30000.ethernet: Chain mode enabled
[ 1.037089] dwmac-sun8i 1c30000.ethernet: Found internal PHY node
[ 1.046916] dwmac-sun8i 1c30000.ethernet: Switch mux to internal PHY
[ 1.053264] dwmac-sun8i 1c30000.ethernet: Powering internal PHY
[ 7.334168] sun4i-codec 1c22c00.codec: ASoC: codec-analog@1f015c0 not registered
[ 7.341742] sun4i-codec 1c22c00.codec: Failed to register our card
[ 7.429581] sun4i-codec 1c22c00.codec: ASoC: Failed to create component debugfs directory
[ 7.436032] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok
[ 7.508643] sun4i-drm display-engine: bound 1100000.mixer (ops sun8i_mixer_platform_driver_exit [sun8i_mixer])
[ 7.511304] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops sun4i_tcon_platform_driver_exit [sun4i_tcon])
[ 7.511461] sun8i-dw-hdmi 1ee0000.hdmi: 1ee0000.hdmi supply hvcc not found, using dummy regulator
[ 7.519626] sun8i-dw-hdmi 1ee0000.hdmi: Linked as a consumer to regulator.0
[ 7.530772] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy)
[ 7.537011] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI I2C bus driver
[ 7.537968] sun4i-drm display-engine: bound 1ee0000.hdmi (ops sun8i_dw_hdmi_ops [sun8i_drm_hdmi])
[ 8.198556] sun4i-drm display-engine: fb0: DRM emulated frame buffer device
[ 8.202875] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
[ 9.598875] dwmac-sun8i 1c30000.ethernet eth0: No Safety Features support found
[ 9.598900] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available
[ 9.598911] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW
Still same error with glmark2-es-fbdev as original post.
hmm, you have sun4i-drm loaded. You should have: /dev/dri/card0 Can you find it?
Yes.
pi@bpi-m2z:/dev/dri$ ls -l
total 0
crw-rw---- 1 root video 226, 0 Oct 19 22:33 card0
I am going to start over with the Kodi 4.20.17 image and see if that changes anything.
you have /dev/dri/card0 , so the mali blobs should be for GBM.
In case you did not run the command above, please run:
cd /lib/arm-linux-gnueabihf
sudo cp -avf /usr/mali/lib/* .
Ok, I made 100% sure that I am on a clean image, and using fbdev blobs.
# find / -name libMali.so
/usr/mali/lib/libMali.so
/usr/lib/arm-linux-gnueabihf/libMali.so
/home/ubuntu/mali-blobs/r8p1/arm/fbdev/libMali.so
/home/ubuntu/mali-blobs/r8p1/arm64/fbdev/libMali.so
/home/ubuntu/mali-blobs/r6p2/arm/fbdev/libMali.so
/home/ubuntu/mali-blobs/r6p2/arm/wayland/libMali.so
/home/ubuntu/mali-blobs/r6p2/arm/x11_dma_buf/libMali.so
/home/ubuntu/mali-blobs/r6p2/arm/x11_ump/libMali.so
/home/ubuntu/mali-blobs/r6p2/arm64/fbdev/libMali.so
/home/ubuntu/mali-blobs/r6p2/arm64/wayland/libMali.so
/home/ubuntu/mali-blobs/r6p2/arm64/x11_dma_buf/libMali.so
/lib/arm-linux-gnueabihf/libMali.so
root@bpi-m2z:~# diff /home/ubuntu/mali-blobs/r6p2/arm/fbdev/libMali.so /usr/mali/lib/libMali.so
root@bpi-m2z:~# diff /home/ubuntu/mali-blobs/r6p2/arm/fbdev/libMali.so /usr/lib/arm-linux-gnueabihf/libMali.so
root@bpi-m2z:~# diff /home/ubuntu/mali-blobs/r6p2/arm/fbdev/libMali.so /lib/arm-linux-gnueabihf/libMali.so
# ./kmscube
./kmscube: symbol lookup error: ./kmscube: undefined symbol: gbm_create_device
# /usr/bin/glmark2-es-fbdev
Error: eglCreateWindowSurface failed with error: 0x3003
Error: eglCreateWindowSurface failed with error: 0x3003
Error: CanvasGeneric: Invalid EGL state
Error: main: Could not initialize canvas
Ok, I made 100% sure that I am on a clean image, and using fbdev blobs.
fbdev blobs are for fbdev only, kmscube will not work.
try this approach:
cd /lib/arm-linux-gnueabihf
sudo cp -avf /home/ubuntu/mali-blobs/r6p2/arm/fbdev/* .
You need to link the opengles libraries to the libMali.so.
The diff shows that all the local instances are copies from that fbdev version. The rest of the libraries are just symlinks to that file. glmark2-es-fbdev still isn't working.
I will review fbdev with kernel 5.3.7 and see what i get;
Retropie builds it's own sdl2, so it can use whatever buffer/presentation device. I thought fbdev would be the easiest to get working without a windowing system, but I'll try to work around anything you can give me. The funny thing is it compiles cleanly, so it thinks it has the interfaces it needs, and if it could just initialize the device, it would work :smile:
I am not sure sdl2 runs on fbdev. Anyway, i think you should go back to kernel 4.18 where there is CMA reserved memory and a workaround variable set to 1.
Check if you have this:
dmesg|grep mali
[ 10.254492] mali: loading out-of-tree module taints kernel.
[ 10.267554] platform mali-utgard: assigned reserved memory node cma
[ 10.270625] Allwinner sunXi mali glue initialized
In Kernel 5.3.y i get:
EGL Version: "1.4 Linux-r6p2-01rel0"
EGL Vendor: "ARM"
EGL Extensions: "EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_lock_surface EGL_KHR_lock_surface2 EGL_EXT_create_context_robustness EGL_ANDROID_blob_cache EGL_KHR_create_context EGL_KHR_partial_update EGL_KHR_create_context_no_error "
Error: eglCreateWindowSurface failed: 0x00003003
Possibly due to no CMA and no drm_leak_fbdev_smem=1
You should try this one: https://github.com/avafinger/bananapi-zero-ubuntu-base-minimal#whats-new-with-this-image-v3
Ahh, i need to rebuild kernel and use r8p1 instead of r6p2, please read https://github.com/mripard/sunxi-mali/issues/56#issuecomment-450337216
I just tested kmscube on Ubuntu 19.10 (eon) with GBM and it works. I will now rebuild for the fbdev.
ubuntu@bpi-m2z:~/mali/kmscube$ sudo ./kmscube
Using display 0x1 with EGL version 1.4
===================================
EGL information:
version: "1.4 Linux-r6p2-01rel0"
vendor: "ARM"
client extensions: "EGL_EXT_client_extensions EGL_EXT_platform_base EGL_KHR_platform_gbm EGL_KHR_platform_wayland "
display extensions: "EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_EXT_image_dma_buf_import EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_swap_buffers_with_damage EGL_EXT_swap_buffers_with_damage EGL_KHR_lock_surface EGL_KHR_lock_surface2 EGL_EXT_create_context_robustness EGL_ANDROID_blob_cache EGL_KHR_create_context EGL_WL_bind_wayland_display EGL_KHR_partial_update EGL_KHR_create_context_no_error "
===================================
OpenGL ES 2.x information:
version: "OpenGL ES 2.0"
shading language version: "OpenGL ES GLSL ES 1.00"
vendor: "ARM"
renderer: "Mali-400 MP"
extensions: "GL_OES_texture_npot GL_OES_vertex_array_object GL_OES_compressed_ETC1_RGB8_texture GL_EXT_compressed_ETC1_RGB8_sub_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_OES_vertex_half_float GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_rgb8_rgba8 GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_ARM_mali_program_binary GL_EXT_shader_texture_lod GL_EXT_robustness GL_OES_depth_texture_cube_map GL_KHR_debug GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_OES_mapbuffer GL_KHR_no_error"
===================================
^C
ubuntu@bpi-m2z:~/mali/kmscube$ uname -ra
Linux bpi-m2z 5.3.5 #1 SMP Mon Oct 7 21:22:23 -03 2019 armv7l armv7l armv7l GNU/Linux
ubuntu@bpi-m2z:~/mali/kmscube$
I updated the blobs to r8p1 but unfortunately, mali freezes the board.
ubuntu@bpi-m2z:~/mali/mali-test$ sudo ./test
[sudo] password for ubuntu:
EGL Version: "1.4 Linux-r8p1-00rel0"
EGL Vendor: "ARM"
EGL Extensions: "EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_lock_surface EGL_KHR_lock_surface2 EGL_EXT_create_context_robustness EGL_ANDROID_blob_cache EGL_KHR_create_context EGL_KHR_partial_update EGL_KHR_create_context_no_error "
Surface size: 480x480
GL Vendor: "ARM"
GL Renderer: "Mali-400 MP"
GL Version: "OpenGL ES 2.0 "mali450-r5p1-01rel0-lollipop-233-g52c929d""
GL Extensions: "GL_OES_texture_npot GL_OES_vertex_array_object GL_OES_compressed_ETC1_RGB8_texture GL_EXT_compressed_ETC1_RGB8_sub_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_OES_vertex_half_float GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_rgb8_rgba8 GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_ARM_mali_program_binary GL_EXT_shader_texture_lod GL_EXT_robustness GL_OES_depth_texture_cube_map GL_KHR_debug GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_OES_mapbuffer GL_KHR_no_error"
same for the r6p2
FIXED on Kernel 5.3.7
fbdev and gbm works!
I will push an OS Image 8GB with Ubuntu 19.10 (eoan) - Kernel 5.3.7 ready to run fbdev. Please report back if you can run sdl2 on fbdev.
root@bpi-m2z:/home/ubuntu/mali/yagears-fbdev# ./yagears-fbdev -b egl-fbdev -e glesv2
^CGears demo: 56.10 fps
OpenGL ES 2.0 "mali450-r5p1-01rel0-lollipop-233-g52c929d"
OpenGL ES GLSL ES 1.00
EGL 1.4 (depth 24, red 8, green 8, blue 8, alpha 8)
Hmm, ok. I think is possible. https://github.com/mihailescu2m/libsdl2-2.0.2-dfsg1/commit/bfd676cad31430e31065ccf7e5ee5dcc01f75d82
Good to hear. Here's a protip- if you dd if=/dev/zero of=zeros; rm zeros
before you make an image, it will reduce the size of your image and compression will be able to pack up all the empty space.
I started it a few minutes ago, already 50%. I was not aware of your tip... unfortunately is packing the zeroes.
The 8GB image is here: https://github.com/avafinger/bananapi-zero-ubuntu-base-minimal/releases/tag/v2.5
Please, give feedback about the sdl2 running with fbdev.
I think this is very close. I can get everything in core to compile except for retroarch. emulationstation starts, and I get the graphical startup screens (yay). retroarch fails on this single file (retroarch/gfx/drivers_context/drm_ctx.c, which fails in the linking looking for some gbm_ functions. Do you think it is correct that these gbm symbols are not available? I can open an issue at libretro if it should be fixed on that side. My build log errors:
CC gfx/drivers_context/drm_ctx.c
LD retroarch
/usr/bin/ld: obj-unix/release/gfx/drivers_context/drm_ctx.o: in function `drm_fb_get_from_bo':
drm_ctx.c:(.text+0xb2): undefined reference to `gbm_bo_get_width'
/usr/bin/ld: drm_ctx.c:(.text+0xba): undefined reference to `gbm_bo_get_height'
/usr/bin/ld: drm_ctx.c:(.text+0xc4): undefined reference to `gbm_bo_get_stride'
/usr/bin/ld: drm_ctx.c:(.text+0xce): undefined reference to `gbm_bo_get_handle'
/usr/bin/ld: drm_ctx.c:(.text+0x110): undefined reference to `gbm_bo_set_user_data'
/usr/bin/ld: obj-unix/release/gfx/drivers_context/drm_ctx.o: in function `gfx_ctx_drm_wait_flip':
drm_ctx.c:(.text+0x23a): undefined reference to `gbm_surface_release_buffer'
/usr/bin/ld: obj-unix/release/gfx/drivers_context/drm_ctx.o: in function `gfx_ctx_drm_swap_buffers':
drm_ctx.c:(.text+0x2a4): undefined reference to `gbm_surface_lock_front_buffer'
/usr/bin/ld: drm_ctx.c:(.text+0x2aa): undefined reference to `gbm_bo_get_user_data'
/usr/bin/ld: drm_ctx.c:(.text+0x2de): undefined reference to `gbm_surface_has_free_buffers'
/usr/bin/ld: obj-unix/release/gfx/drivers_context/drm_ctx.o: in function `gfx_ctx_drm_destroy_resources.part.0':
drm_ctx.c:(.text+0x3ee): undefined reference to `gbm_surface_destroy'
/usr/bin/ld: drm_ctx.c:(.text+0x3fa): undefined reference to `gbm_device_destroy'
/usr/bin/ld: obj-unix/release/gfx/drivers_context/drm_ctx.o: in function `gfx_ctx_drm_set_video_mode':
drm_ctx.c:(.text+0x50a): undefined reference to `gbm_surface_create'
/usr/bin/ld: drm_ctx.c:(.text+0x520): undefined reference to `gbm_surface_lock_front_buffer'
/usr/bin/ld: drm_ctx.c:(.text+0x52a): undefined reference to `gbm_bo_get_user_data'
/usr/bin/ld: obj-unix/release/gfx/drivers_context/drm_ctx.o: in function `gfx_ctx_drm_init':
drm_ctx.c:(.text+0x872): undefined reference to `gbm_create_device'
/usr/bin/ld: drm_ctx.c:(.text+0x890): undefined reference to `gbm_surface_destroy'
/usr/bin/ld: drm_ctx.c:(.text+0x89a): undefined reference to `gbm_device_destroy'
/usr/bin/ld: obj-unix/release/gfx/drivers_context/drm_ctx.o: in function `gfx_ctx_drm_destroy':
drm_ctx.c:(.text+0x998): undefined reference to `gbm_surface_destroy'
/usr/bin/ld: drm_ctx.c:(.text+0x9a4): undefined reference to `gbm_device_destroy'
collect2: error: ld returned 1 exit status
make: *** [Makefile:196: retroarch] Error 1
You are confusing fbdev with gbm.
The image targets mali fbdev only and not mali gbm. So any reference to link gbm_some_function will fail. Unless you changed to mali gbm now.
Please clarify.
I am no expert in this. If you think those functions should not be present, I'll go ask the authors of that code what the fbdev equivalents are. This code should all be "mali-ready", as it does compile on odroid and cubieboard systems.
fbdev does not use DRM. GBM uses DRM.
Generically speaking, fbdev is a memory area mapped to the screen (say GPU in the PC world) and anything you write to this area will be seen on the screen. Mali shares this area or writes to this area too.
In case of the GBM you need the DRM portion of the kernel to write to the screen.
Mali is for 3D functions.
This code should all be "mali-ready", as it does compile on odroid and cubieboard systems.
That depends on the mali-blob in use, it looks like you should use mali-gbm. I have never used or compiled retroarch, so you better ask them what mali-blob is needed in this case.
Compiled successfully- just needed a flag to disable that drm. Thanks for all your help and patience. I'll post an image and an instructable when I get everything put together. Was this build a special variant, or will fbdev be regularly available in your images in the future?
GBM is newer than fbdev. If you get SDL2 to work with mali-fbdev i will provide updates with mali-fbdev. KODI runs with gbm , so there is more support for gbm than fbdev.
Consider it a special variant... But i prefer fbdev if i can have a working sdl2.
Hot off the presses :smile: https://github.com/lbernstone/SDL-mirror
So is it just a different kernel .config, or multiple changes? Can you post a patch/diff here for google to remember?
My first pass. The basics work. I haven't really looked at the framerates, but I don't think there will be a whole lot of acceleration, so performance may be terrible. https://github.com/lbernstone/bpi-m2z-retropie
I have not tested sdl2 fbdev yet, but my thinking is that it won't have any "acceleration" , only if you use the mali 3D functions, otherwise, it will be just bliting to a frame and have mali to blit this frame buffer to the screen. I may be wrong...
I'm using your image with kernel 4.19.12. I'd like to get retropie running, but am getting fbdev errors. When I try to run your stress tools (or any fbdev app, really), I get the following error:
Am I missing something to enable to framebuffer for EGL?