fbdev does not initialize #28
Comments
|
There are two mali blobs, one for fbdev and one for GBM. |
|
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: |
|
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. |
|
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 |
|
The modules seem to be loaded OK: |
|
Still same error with glmark2-es-fbdev as original post. |
|
hmm, you have sun4i-drm loaded. You should have: /dev/dri/card0 |
|
Yes. 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: |
|
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: 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 😄 |
|
I am not sure sdl2 runs on fbdev. Check if you have this: |
|
In Kernel 5.3.y i get: 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 mripard/sunxi-mali#56 (comment) |
|
I just tested kmscube on Ubuntu 19.10 (eon) with GBM and it works. I will now rebuild for the fbdev. |
|
I updated the blobs to r8p1 but unfortunately, mali freezes the board. 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.
|
|
Hmm, ok. I think is possible. mihailescu2m/libsdl2-2.0.2-dfsg1@bfd676c |
|
Good to hear. Here's a protip- if you |
|
I started it a few minutes ago, already 50%. |
|
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: |
|
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. 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.
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. |
|
GBM is newer than fbdev. If you get SDL2 to work with mali-fbdev i will provide updates with mali-fbdev. Consider it a special variant... But i prefer fbdev if i can have a working sdl2. |
|
Hot off the presses 😄 |
|
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. |
|
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?
The text was updated successfully, but these errors were encountered: