Hard Lock - [build] use-vbo=false:

Question

Hard Lock - [build] use-vbo=false:

kjngineering opened this issue 4 years ago · comments

Hi

So I've been working on getting the Mali blob to run on our target board; OrangePi Zero H3 Plus2.
The goal is to get FBDEV acceleration using the existing binary blobs, currently a 800x800 LCD running over HDMI.

The build environment is Buildroot which is compiling kernel 5.4.13, Mali kernel drivers are the Mripard r6p2, userspace is the corresponding Bootlin blob for fbdev.

CMA and DMA_CMA flags are enabled, CMA is set at 128mb, FBDEV_OVERALLOC is 200.
Device tree is mainline and the device is probed successfully by mdev:

Starting mdev... OK
[    2.942554] mali: loading out-of-tree module taints kernel.
[    2.972766] Allwinner sunXi mali glue initialized
[    2.979874] Mali:
[    2.979882] Found Mali GPU Mali-400 MP r1p1
[    2.986758] Mali:
[    2.986762] 2+0 PP cores initialized
[    2.993136] Mali:
[    2.993141] Mali device driver loaded

I forked the glmark2-es2-fbdev code to my github and patched the waf libraries and config to compile under python3 so I could build a buildroot package - I added the following calls to the waf build script:

GLMARK2_FBDEV_CONF_OPTS += \
	--prefix=/usr \
	--with-flavors=$(subst $(space),$(comma),$(GLMARK2_FBDEV_FLAVORS)) \
	--with-mali \
	--no-werror

--with-mali as it seemed like an appropriate flag, --no-werror just to deal with some compiler warnings.

The package is now compiling and being installed to the target file system. However when I run I get the following:

# glmark2-es2-fbdev
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-400 MP
    GL_VERSION:    OpenGL ES 2.0
=======================================================
[build] use-vbo=false:

Screen goes black.
The system HARD locks, chip gets hot, nothing works! Cant force quit.
I tried again with nohup, to see if we were at 100% cpu but nohup hangs in the same way.

I'm a bit lost now, any ideas on how I can diagnose this one (or even check if the Mali driver is working?)

Thanks

avafinger · Answer 1 · Mon Dec 14 2020 22:01:44 GMT+0800 (China Standard Time)

Triple check your kernel is built with CONFIG_DRM_FBDEV_OVERALLOC=200 and you use the FBDEV blobs.
https://github.com/mripard/sunxi-mali#installing-the-user-space-components

avafinger · Answer 2 · Mon Dec 14 2020 22:07:23 GMT+0800 (China Standard Time)

You can test if mali is working:
test.c.tar.gz

Build instructions are at beginning of the file...

KJNgineering · Answer 3 · Tue Dec 15 2020 05:58:09 GMT+0800 (China Standard Time)

Hi Avafinger,

Thanks for the quick response.

Just out of curiosity -- have you ever successfully built and tested on a mainline kernel? All the indicated tests are for quite old (commonly) legacy versions. If you have some test hardware I would be more than happy to help you with a quick buildroot config you could test!

On to solving my issue:

I'm very confident on the CONFIG_DRM_FBDEV_OVERALLOC >=200, when it is at 100 I get a completely different error:

Error: eglInitialize() failed with error: 0x3003
Error: main: Could not initialize canvas

Which is characteristic behavior based on the notes I have read on Maxime's respository.

I'm also pretty confident on the FBDEV version as the buildroot script will ONLY collect and install the FBDEV driver:

Buildroot: sunxi-mali-mainline.mk
Buildroot: sunxi-mali-mainline-driver.mk

I've verified on device that there are libraries installed in the usr/lib directory as there should be.

	mkdir -p $(STAGING_DIR)/usr/lib $(STAGING_DIR)/usr/include

	cp -rf $(@D)/$(SUNXI_MALI_MAINLINE_REV)/$(SUNXI_MALI_MAINLINE_ARCH)/fbdev/*.so* \
		$(STAGING_DIR)/usr/lib/
	cp -rf $(@D)/include/fbdev/* $(STAGING_DIR)/usr/include/

	$(INSTALL) -D -m 0644 package/sunxi-mali-mainline/egl.pc \
		$(STAGING_DIR)/usr/lib/pkgconfig/egl.pc
	$(INSTALL) -D -m 0644 package/sunxi-mali-mainline/glesv2.pc \
		$(STAGING_DIR)/usr/lib/pkgconfig/glesv2.pc

I've tried r8p1 in addition to the r6p2, but the version for r8p1 indicated some strange values on the driver name and wouldn't automatically probe the device at boot time. Either way the result of a hard lock was the same with both drivers.

I found Luc's test file in the legacy sunxi branch last night - so I am going to build a package today to see if I can make it work.

Thanks again -- I will report back.

KJNgineering · Answer 4 · Tue Dec 15 2020 09:16:10 GMT+0800 (China Standard Time)

So I compiled the test.c:

Again the screen clears ready to draw, the board hard locks right in the middle of printing a string and begins to heat up agian.

Any ideas?

# malitest
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 "
Surface size: 800x800
GL Vendor: "ARM"
GL Renderer: "Mali-400 MP"
GL Version: "OpenGL ES 2.0"
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_pr

avafinger · Answer 5 · Tue Dec 15 2020 20:29:08 GMT+0800 (China Standard Time)

Just out of curiosity -- have you ever successfully built and tested on a mainline kernel?

I have tried it but could not fix the compiling error that is generated, some of them I have fixed but not all.
If you can look at it (the compiling errors) and fix that I can try again. Mainline 5.10 would be fine.

KJNgineering · Answer 6 · Wed Dec 16 2020 05:33:00 GMT+0800 (China Standard Time)

So I am building against 5.4.13 mainline the driver now has patch sets up to 5.7.

So it is definitely possible to build up to a very recent mainline.

I will try on 5.10 and see if it works and let you know; if so I am happy to help getting the buildroot environment setup for whatever board you have.

Edit: 5.10.1 ran into some code errors. 5.7.19 compiles and runs fine (although still crashes).

avafinger · Answer 7 · Thu Dec 17 2020 05:10:30 GMT+0800 (China Standard Time)

Edit: 5.10.1 ran into some code errors. 5.7.19 compiles and runs fine (although still crashes).

Yeap, I knew that. That's the errors I was talking about... ;)

Anyway, if you fix the errors I can build and test the fbdev with this kernel. Don't waste time with 5.9, you get similar errors.

KJNgineering · Answer 8 · Thu Dec 17 2020 05:54:07 GMT+0800 (China Standard Time)

It might be beyond my skillset to be honest, its not just compiler stuff. It looks like it is inherent to the changes in kernel functions from 5.7>5.10 - let's see what Maxime says.

As this issue is not with the benchmark code - but likely the sunxi-mali driver/kernel/hardware implementation. I think we can close this?

For anyone looking for more information this is followed in the mripard github here