Black window in EGL apps - cubietruck (2GB of RAM)

[tomee]

As per http://irclog.whitequark.org/linux-sunxi/2013-11-17#;tomee I am filing a bug: EGL/GLES apps render as black windows/rectangles, no matter if ran with or without window manager (via xinit or startx (xfwm4) + xterm). When sunxi-mali is compiled for framebuffer, test/test DOES WORK. Apps tried: sunxi-mali/test/test.c, glmark2-es2. Output of apps to console is normal (no errors), nothing is rendered though. Output of Xorg log: http://sprunge.us/PjPG Output of test/test: http://sprunge.us/UVhe Linking seems correct: http://sprunge.us/ZGdM Modules loaded: http://sprunge.us/ZGea Various fex variants tried, same effect. E.g.: http://sprunge.us/COXO or http://sprunge.us/fEZC

Hardware: cubietruck Kernels tried: linux-sunxi 3.4.67+ stage-3.4 (compiled myself) and cubietech/linaro 3.4.61+ (Linux version 3.4.61+ (matson@ubt) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP PREEMPT Sat Nov 2 16:59:23 CST 2013)

Can anyone point me how to debug further or provide a "worksforme" image?

[rzk]

I can confirm this, my cubietruck does the same with the NAND image from cubietech. I bet that this is the problem of this particular image only. We need to test the standard combo of our u-boot/kernel and mali blobs all from the scratch with some popular rootfs like linaro.

[tomee]

I think the cubietech linux is based on linaro... but maybe they broke something in the way. But perhaps Debian would be a safer bet... Also, maybe it's a pll/dram/mali clock issue? The cubietruck is downclocked (dram 432MHz, mali 312MHz), maybe this somehow breaks proper timings in X11?

[rzk]

No, mali renders everything right, you can check that by seeing different framerate at different tests (try glmark2-es2, es2gears). IIRC, 2GB systems had a problem with buffers allocating/copying inside the kernel that was patched by a little define added by Benn Huang, that is where this problem comes from. If we had problems with dram/clocking/etc, it would affect the whole system, Benn patched only CedarX and Mali with his 2GB stuff. I will find these patches when I will have time to play with my CubieTruck and report back.

[tomee]

Hmm, so is there a way to forcibly disable 2GB (fex? kernel parameter) and see if that makes a difference? Also, I think the kernel is using some sort of NUMA (400MB + 1500MB) ?

[tomee]

Funny thing - I tried this build today: http://www.gplsquared.com/eoma_boot/eoma_boot.html#Ubunt_13_04_3D It's apparently boasting about 3d acceleration but all I get is... black surface inside of glmark2 window. I did some messing around with the image (ie. used the cubietech bootloader - still can't get the linux-sunxi one to work properly, the filenames and offsets in tutorials differ which confuses me. Also, I am not using boot.scr, only uEnv.txt + uImage). Does this sched some light on the issue? The eoma board and cubieboard2 are both 1GB so my best bet would be that it's the DRAM issue after all... but I yet have to rule out the bootloader influence and test a debian image (eoma image was linaro-based). It would be great if anyone out there could provide me with a "worksforme" setup on cubietruck...

[tomee]

I can confirm that this also happens with a debian wheezy image created with debootstrap. The behavior is exactly the same. HOWEVER: Reverting this patch https://github.com/linux-sunxi/u-boot-sunxi/commit/9af5adb5253608fd812aa0fa25d510a033fde1a3 and editing dram_cubietruck.c (fake 1GiB) fixes the issue! Apart from having 1GB instead of 2GB RAM available, of course. The "patch": http://heroin.pl/upl/cubietruck/sunxidram.patch The bootloader: http://heroin.pl/upl/cubietruck/u-boot-sunxi-with-spl-no2GiB.bin So this is definitely memory mapping related. Now, for someone more competent to REALLY fix that instead of me just halving the available RAM...

[rzk]

As I said, for 2GB systems we had these patches added:

https://github.com/linux-sunxi/linux-sunxi/commit/cba0a9bac475fe14c6a25c221cd499b1d5dfecf4 https://github.com/linux-sunxi/linux-sunxi/commit/482ce7ac54fe637a3ea0aa01c380aa4a919bc230

If this is really memory mapping problem - this is the only thing to play with.

Try removing the instances of phys_to_bus/bus_to_phys and running our latest community u-boot with 2gb support enabled.

Also, please write this issue to mailing list (http://linux-sunxi.org/Mailing_list), as this is certanly not a fbturbo issue, but rather a kernel/bootloader side one.

[tomee]

You mean getting rid of the macro calls in the kernel and seeing if a 2gb-enabled bootloader works correctly with such modified kernel? I can try that.

[fruit-bat]

I tried removing the instances of phys_to_bus/bus_to_phys and it was very bad. Random mess on the screen during boot. Also tried taking out the condition but leaving in the 1GB offset which allows system to boot but still black windows for glmark-es2 etc.

[ssvb]

Should be fixed by http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/5480 (or by some other patch addressing the same problem in the kernel if this one is no good).

[ssvb]

OK, the kernel patch had been accepted in the stage/sunxi-3.4 kernel branch. Feel free to reopen this bug if anything is still wrong.

[tomee]

Thank you, I will test the patch ASAP. Been working around the clock lately so had no time to post updates, sorry