Myy

THE MEDIA SCRIPT IS DEPRECATED, IN FAVOR OF THE OFFICIAL LEGACY MULTIMEDIA FRAMEWORK. PLEASE REFER TO THIS TOPIC:
 
 
 
The UN-official, UN-supported, UN-necessary, UN-popular, UN-precedented...
RK3288 MEDIA TESTING SCRIPT [2.0: Bionic update]
 
So here is the final release of the RK3288 media testing script. Basically, the script provides the following functionality:
Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@30 HEVC (the maximum supported by the SoC), and GLES 3.1 / OpenCL 1.2 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi 18.0 alpha preview. Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple). A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional small packages, that have no big interest from the developer prospective, but I find them interesting to play with: Support libraries for commercial web video streaming (tested with Netflix), and a simple Pulseaudio GTK equalizer using LADSPA.  
Here is a more thorough documentation:
 
Version 2.0 (Bionic):
 
Version 1.0 (Xenial):

>>> DOWNLOAD LINK (2.0, FOR BIONIC DESKTOP) <<<
 
> Older Download link (1.0, for Xenial) <
 
Instructions:
Download the file above Untar it: tar xvf media-rk3288_*.tar.xz cd media-script ./media-rk3288.sh  
Notes:
This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
Enjoy!
 
 
 

@Myy looky here.

Okay, I got it "kind of" working with a 4.17-rc4. I say "kind of" because I only tested scanning, which worked (with UTF-8 support too !).
I didn't get that much farther because... I'm no bluetooth user so I don't know how to test it in a meaningful way.
 
Anyway, here's the catch, you need to enable all the GPIO, including the RTS one, through the GPIO export. Note that I tested this without the "wireless-bluetooth" entry in the DTS.
 
Enable Bluetooth GPIO
 
cd /sys/class/gpio echo 139 > export echo 146 > export echo 149 > export echo 151 > export echo low > gpio139/direction echo high > gpio146/direction echo high > gpio149/direction echo high > gpio151/direction  
Then download Larry W Finger hciattach tool and use it like he says :
./rtk_hciattach -n -s 115200 /dev/ttyS0 rtk_h5  
Testing was done like that :
 
root@tinkerboard:~# hcitool scan Scanning ... C4:86:E9:5E:50:89 ?  
? is my Huawei phone with Bluetooth activated.

 
 
 
 

@Myy I wonder if this might be able to be adapted for Tinker mainline bluetooth?
 
So much time so little to do!...  Strike that, reverse it.
 

Alright, I think I got something working !
 
MPV using MPP seems to work and is able to read a 1080p WebM file and output a very fluid image !
However, I only tested this with 1m30s sample files so I'll have to test this more seriously.
 
Still, having the VPU driver works on 4.13 kernels is nice ! Now, I'll need testers !
 
So here's a patched kernel build, including the VPU driver in it :
https://github.com/Miouyouyou/RockMyy-Build/releases/tag/v4.13-VPU-Test
 
This build include patches that makes logging VERY NOISY when playing files. If everything works nicely, I'll remove the noise.
 
Here's the repository containing the patches applied :
https://github.com/Miouyouyou/RockMyy/tree/VPU_Work_tests
 
And here's the patch itself :
https://github.com/Miouyouyou/RockMyy/blob/VPU_Work_tests/patches/kernel/v4.13/0012-Slight-butchering-to-test-the-VPU-driver.patch
 
Here's the repository containing the working VPU code :
https://github.com/Miouyouyou/rockchip-vcodec/tree/retry
 
 
 
Testing the VPU
 
Now, in order to test the VPU driver, you'll need something that work with it !
I tested it with MPP and MPV. So if you want to test it like I did, you'll have to recompile MPP and MPV, and also know how to download and use ARM Mali user-space binary drivers and make them work through the DRM interface.
https://github.com/rockchip-linux/mpp
https://github.com/LongChair/mpv
https://github.com/rockchip-linux/libmali/
 
Have fun !
 
Whether everything works or you got a crash, don't hesitate to reply on this thread.
If you something went wrong, please provide any crash message that might appear in dmesg !

Mainline does not support that touchscreen yet, the changes to the drm system from 4.4 to 4.14, and the "special code" used in the 4.4 made me pause before patching any changes in.  There are tons of mipi/DSI patches in the pipework, so I'll have to revisit it.  For now pulling that node is perfectly acceptable.

Well, after upgrading to artful, I discovered that the official FFMPEG project pulled a patch provided by LongChair which enable MPP support in FFMPEG directly...
 
So I now need to recompile FFMPEG... On Ubuntu... I'll try to recompile ffmpeg with just h264 support for now.

I've ported the new code provided by Ayaka but I still need to test it. Since I'm using a different MiQi, I have to recompile mpp (done) and mpv.
 
The last one is posing several issues since it wants a pretty recent version of FFMPEG. I'll see whether I compile a new local version of ffmpeg of if I upgrade from Ubuntu Xenial to Ubuntu Artful to resolve this issue.

This is now different:
root@tinkerboard:/home/tido/myy-s/mali# LD_LIBRARY_PATH=. glmark2-es2-drm Error: eglGetDisplay() failed with error: 0x3000 Error: eglGetDisplay() failed with error: 0x3000 Error: main: Could not initialize canvas Error: Failed to restore original CRTC: -13 I try after  chvt 1, et voila:
root@tinkerboard:/home/tido/myy-s/mali# LD_LIBRARY_PATH=. glmark2-es2-drm ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-T760 GL_VERSION: OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).810f535757d8c9adaaa72f5da29c688e ======================================================= [build] use-vbo=false: FPS: 55 FrameTime: 18.182 ms [build] use-vbo=true: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=nearest: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=linear: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=mipmap: FPS: 55 FrameTime: 18.182 ms [shading] shading=gouraud: FPS: 55 FrameTime: 18.182 ms [shading] shading=blinn-phong-inf: FPS: 55 FrameTime: 18.182 ms [shading] shading=phong: FPS: 55 FrameTime: 18.182 ms [shading] shading=cel: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=high-poly: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=normals: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=height: FPS: 55 FrameTime: 18.182 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 55 FrameTime: 18.182 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 50 FrameTime: 20.000 ms [pulsar] light=false:quads=5:texture=false: FPS: 55 FrameTime: 18.182 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 27 FrameTime: 37.037 ms [desktop] effect=shadow:windows=4: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms [ideas] speed=duration: FPS: 55 FrameTime: 18.182 ms [jellyfish] <default>: FPS: 55 FrameTime: 18.182 ms [terrain] <default>: FPS: 13 FrameTime: 76.923 ms [shadow] <default>: FPS: 55 FrameTime: 18.182 ms [refract] <default>: FPS: 27 FrameTime: 37.037 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 55 FrameTime: 18.182 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 55 FrameTime: 18.182 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 55 FrameTime: 18.182 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms ======================================================= glmark2 Score: 51 =======================================================  
Wow, in  htop  CPU is close to Zero !
Temperature: around 50° C  steady.
It does need more RAM than before, but not more than 352
 

OK, testing against MiQi to make sure nothing outrageous is going on, screen is working with DRM rather nicely.  Plugging in the HDMI at the same time is...  well unique, the 7" display just lives in the top left corner of the larger external display, and the touch feature applies to the full larger desktop.  In any case, if it passes testing on 4.4 it might be fun to get it to work on 4.13/14
 
[Edit]  MiQi is working perfectly, no issues with the entries in the Tinker DT if the screen is not connected, I'll upload the patch.

Hi ! I am so pleased that somebody trying to fix this opengl things for Tinkerboard
 
Can do testing as I do have Tboard and HDMI interface.  Hopefully will also pickup 3v serial today.

Did you try using the rk3288-tinker.dtb provided with my build, or a 4.14.x ready rk3288-miniarm.dtb ? If you use a 4.13 or lower version DTB, it might fail to boot due to Rockchip 32 bits DTS using 64 bits addressing now, in order to use LPAE on some 32 bits boards. LPAE provides the ability to use more than 4 GB of memory on 32 bits systems, through magic, memory windows and ugly hacks.
 
Anyway, I tested my latest release (4.14.0-rc7) with glmark2 and the Rockchip's r14p0-wayland user-space binary drivers and it works. I'll try to install Rockchip xserver and test glmark2 on X11 this week, if I got the time.
 
During these tests, I discovered the magic of chvt, which changes the current virtual terminal displayed on the screen, which is very useful when you have control on a machine with SSH access, but no USB keyboard plugged on the machine, and want to switch to a terminal from X11. So basically instead of trying to find a keyboard, plug it and hit CTRL+ALT+F1, you just have to type :
sudo chvt 1 I also checked that using a shitty micro-USB cable will cause the MiQi to reboot instantly when doing 3D intensive work. Yay !
Remember kids, don't do drugs use bad micro-USB cables !

Small changes:
 
- friendly URLs with backward compatibility
Before: https://forum.armbian.com/index.php/topic/3328-cubox-i-unable-to-boot-latest-test-images-with-kernel-495 After https://forum.armbian.com/topic/3328-cubox-i-unable-to-boot-latest-test-images-with-kernel-495/ - remove "Forums" from the main page

Found the real culprit. It was the patch that... enable the VPU services... Some issues with IOMMU definitions made it bork the entire IOMMU group, which included the video output IOMMU. So when the DRM driver tried to use the Video Output, no video output was usable anymore and it bailed out.
 
I'll perform some GLES tests tomorrow and if everything is working, I'll try the rc5 and release a rc5 !
 
 

Circling back on this one, I've had quite a lot to do around the house with winter approaching, here in a few weeks it should settle down. (Just in time for the holiday season here in the US...)
 
@Myy, thanks for the info, I will attempt this with the DT rather than the explicit code.  I might drop a line to Wzyy about it too, since they are now using DT overlays on their kernel.  What this means is that, for now, this would have to be enabled via editing the DT file by the user after I get it working in this manner.

Its an arm7 / arm8 thing, anything after the Cortex-a15 ish supports HYP mode in hardware.
 
I have managed to get it working today but that was under a buildroot based system with legacy kernel not armbian, but it is possible. Something in Armbian's u-boot is ignoring or blocking the nonsec PL2/HYP boot mode. With a "clean" u-boot from rockchips github repo it works as expected after setting CONFIG_ARMV7_VIRT. I will compare the difference between the 2 when I get a chance.

Alright, I think I got something working !
 
MPV using MPP seems to work and is able to read a 1080p WebM file and output a very fluid image !
However, I only tested this with 1m30s sample files so I'll have to test this more seriously.
 
Still, having the VPU driver works on 4.13 kernels is nice ! Now, I'll need testers !
 
So here's a patched kernel build, including the VPU driver in it :
https://github.com/Miouyouyou/RockMyy-Build/releases/tag/v4.13-VPU-Test
 
This build include patches that makes logging VERY NOISY when playing files. If everything works nicely, I'll remove the noise.
 
Here's the repository containing the patches applied :
https://github.com/Miouyouyou/RockMyy/tree/VPU_Work_tests
 
And here's the patch itself :
https://github.com/Miouyouyou/RockMyy/blob/VPU_Work_tests/patches/kernel/v4.13/0012-Slight-butchering-to-test-the-VPU-driver.patch
 
Here's the repository containing the working VPU code :
https://github.com/Miouyouyou/rockchip-vcodec/tree/retry
 
 
 
Testing the VPU
 
Now, in order to test the VPU driver, you'll need something that work with it !
I tested it with MPP and MPV. So if you want to test it like I did, you'll have to recompile MPP and MPV, and also know how to download and use ARM Mali user-space binary drivers and make them work through the DRM interface.
https://github.com/rockchip-linux/mpp
https://github.com/LongChair/mpv
https://github.com/rockchip-linux/libmali/
 
Have fun !
 
Whether everything works or you got a crash, don't hesitate to reply on this thread.
If you something went wrong, please provide any crash message that might appear in dmesg !

And please ask them to consider being compatible to the rest of the (Linux) world using thermal_zone0. Most probably still using thermal_zone1 is for backwards compatiblity since they had it that way on their 4.4 kernel already (a tribute to badly written software expecting things at hardcoded locations). But since every software/script out there naively expects CPU temp available as thermal_zone0 it would be better to become compatible to this (even more a tribute to badly written software expecting things at hardcoded locations )

Alright, I think I got something working !
 
MPV using MPP seems to work and is able to read a 1080p WebM file and output a very fluid image !
However, I only tested this with 1m30s sample files so I'll have to test this more seriously.
 
Still, having the VPU driver works on 4.13 kernels is nice ! Now, I'll need testers !
 
So here's a patched kernel build, including the VPU driver in it :
https://github.com/Miouyouyou/RockMyy-Build/releases/tag/v4.13-VPU-Test
 
This build include patches that makes logging VERY NOISY when playing files. If everything works nicely, I'll remove the noise.
 
Here's the repository containing the patches applied :
https://github.com/Miouyouyou/RockMyy/tree/VPU_Work_tests
 
And here's the patch itself :
https://github.com/Miouyouyou/RockMyy/blob/VPU_Work_tests/patches/kernel/v4.13/0012-Slight-butchering-to-test-the-VPU-driver.patch
 
Here's the repository containing the working VPU code :
https://github.com/Miouyouyou/rockchip-vcodec/tree/retry
 
 
 
Testing the VPU
 
Now, in order to test the VPU driver, you'll need something that work with it !
I tested it with MPP and MPV. So if you want to test it like I did, you'll have to recompile MPP and MPV, and also know how to download and use ARM Mali user-space binary drivers and make them work through the DRM interface.
https://github.com/rockchip-linux/mpp
https://github.com/LongChair/mpv
https://github.com/rockchip-linux/libmali/
 
Have fun !
 
Whether everything works or you got a crash, don't hesitate to reply on this thread.
If you something went wrong, please provide any crash message that might appear in dmesg !

No, I mean the stock Armbian OS of course! Armbian for the win!

Stock OS ? You mean ASUS Debian image ? Yeah, I guess you can give it a try.
 
I got ready-to-use kernel files here :
https://github.com/Miouyouyou/RockMyy-Build
 
That said, my configuration and ARMbian kernel configuration might differ in some places.
Also, I'm only testing my kernels on MiQi devices so I can't guarantee that everything will work on Tinkerboard systems.

So the issue is now resolved in linux-next, which is one of the official git repository that pull the changes that will happen in the next version following the current Release or Release Candidate.
 
I imported the patch and here it is :
https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/0012-net-phy-Deal-with-unbound-phy-driver-in-phy_attached.patch
 
The official patch being :
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=fcd03e362b1cd17de487953aac34f2d4574895cf

Why can't things just work???    Thanks for the heads up @Myy

I've just finished writing my SHT31-D (I2C) Nagios plugin.
As promised, it can be found here for anyone else interested.

Nice catch ! This might prove useful, yeah.
 
Reading this document, I still don't understand why they're dead focused on having technology specific buffers, where all those techs use DMA buffers in the end though. At least internally.
 
I'm currently looking at DRM PRIME and trying to understand if you can, as a user-space application, allocate a DMA buffer, pass it to something else (user-space or kernel-space) so that it writes some bitmap in it and then display the bitmap on the screen using DRM calls. If that can be done, I'm throwing out the DRM/ION part of the VPU driver and let the user-space app/MPP do the buffers allocation.