Myy

@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.

I think this may have gone up recently: http://opensource.rock-chips.com/wiki_Mpp
 
It doesn't mean anything to me, but the vpu is mentioned so maybe it's useful, or if not, maybe will become useful if they add further documentation.

Hey there,
 
WireGuard author here. Sorry to hear you're having problems. This certainly seems like strange behavior. Could you send me the output of:
cat /proc/version cat /lib/modules/$(uname -r)/build/.config || zcat /proc/config.gz || cat /boot/config-$(uname -r) ip -d addr ip -d route sysctl net Then I can get to the core of the issue.
 
However, in looking for a workaround, you might try mitigating this issue by removing "::/0" from the AllowedIPs= line of your config file, so that it only reads "AllowedIPs=0.0.0.0/0". I'd be interested to learn whether this "fixes" the problem.
 
Also, the best place to get help in real time is on the WireGuard IRC channel -- it's #wireguard on Freenode.
 
-Jason

Yep, that's fine for me. I'm a bit dated, hence shying away from all this ipv6 thing.