Myy

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.
 

I build mpv for LibreELEC using https://github.com/Kwiboo/LibreELEC.tv/blob/rockchip/projects/Rockchip/packages/mpv-rockchip/package.mk#L63 along with the configure options defined earlier in the file.
 
We are using a patch to update some of the EGL/GLES include files from RK's libmali repo using https://github.com/Kwiboo/LibreELEC.tv/blob/rockchip/projects/Rockchip/packages/mali-rockchip/patches/mali-rockchip-0001-update-include-files.patch
There is also some GL include files included because mpv do not play nice with only GLES headers, see https://github.com/Kwiboo/LibreELEC.tv/tree/rockchip/projects/Rockchip/packages/mpv-rockchip/GL

Alright. I've provided a first build of the 4.12.0-rc2 with the VPU included.
Now, if you don't want to clone an entire repo, I made a tarball release of this build, so just grab it and install it on your machine. You still need to get the user-space softwares installed correctly though.
 
The kernel loads up, enable the VPU services and the VPU module can be unloaded without issues.
 
Still, no optimization has been added for the moment, as I'm trying to get things working, before trying to get things working nicely.
 
So this week-end will be untangling the user-space.

Unfortunately it is not possible to link kodi krypton and mpv to the same ffmpeg version, mpv requires a rather new ffmpeg version and uses the newer send_packet/receive_frame api and automatic bit-streaming and kodi krypton uses the older video2_decode api.
There was also some audio delays and missed packets if kodi krypton is linked to the newer ffmpeg version, kodi leia will require the new ffmpeg version and the patches will be rebased and updated at a later date.
 
For optimal media playback there have been a few kernel changes required, see my rockchip-4.4 kernel tree at https://github.com/Kwiboo/linux-rockchip/commits/rockchip-4.4
Changed to use of performance gpu governor as a default, the simple_ondemand governor is too slow and limits the gpu rate to ~30fps for gui animations Switched primary and overlay drm planes so we can have gui on top of video Raise the vpu clock to 600Mhz for hevc decoding on rk3288 Allow framebuffer and videomodes not to have same size for scaling of gui from 1080p to 4k (implemented in plexmediaplayer and on my todo list for kodi) Skip waiting on vblank for set plane drm calls, this was recently merged in Rockchip's release-4.4 tree and allows for rendering video and gui planes using legacy drm api without double vsync

Hmm, given that the BTC Keyboard ID have been added 7 years ago, I guess it's more related to Bluetooth dongles getting detected correctly, indeed.

Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
 
The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
 
Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
 
So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
 
I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
 
Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
 
Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
 
 
So, basically, the main goals are :
! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
 
If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.

Cool, I will check how this VPU driver works with a 4.13 kernel on LibreELEC later this weekend.
 
I would suggest testing the VPU driver and mpp using Rockchip's gstreamer plugins or possibly LongChair's mpv/ffmpeg.
I don't know much about gstreamer but it seems to be what the Rockchip's developers use to test video decoding.
Both mpv/plexmediaplayer and kodi use DRM/KMS, gbm version of libmali and a few kernel hacks on LibreELEC for smooth 1080p/4k video playback, they most likely need modifications to run on x11/wayland.
 
For a version of ffmpeg that use mpp for decoding, see https://github.com/LongChair/FFmpeg/commits/rockchip or the rockchip-new branch.
LongChair also have a mpv version for both those branches of ffmpeg at https://github.com/LongChair/mpv/commits/rockchip or the rockchip-new branch.
I have a ffmpeg 3.1 backport at https://github.com/Kwiboo/FFmpeg/commits/rockchip-krypton and Kodi Krypton patches at https://github.com/Kwiboo/plex-home-theater/commits/rockchip-krypton.
The Kodi Leia patches in the rockchip-leia branch will be updated once we have achieved more stable playback on rk3328 devices using mpv and Kodi Krypton.

Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
 
The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
 
Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
 
So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
 
I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
 
Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
 
Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
 
 
So, basically, the main goals are :
! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
 
If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.

Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
 
The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
 
Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
 
So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
 
I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
 
Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
 
Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
 
 
So, basically, the main goals are :
! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
 
If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.

Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
 
The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
 
Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
 
So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
 
I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
 
Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
 
Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
 
 
So, basically, the main goals are :
! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
 
If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.

But wait... you got Bluetooth working on 4.12 kernels ? Are you using an external Bluetooth dongle or did you just start your Bluetooth keyboard and it worked out the box ?
 
Edit : Ah, didn't read correctly, you're using an external dongle. Well given the bad feedback I got from the tinkering forum on the internal Bluetooth, I guess it's the best choice.

Try to execute lsmod on the working kernel. Since most drivers are compiled modules, that should tell you what is the driver, I think. Then, from the module name, you can retrace the config option required and its dependencies.
 
It might also be possible to determine the driver used using /sys nodes. But I don't know how exactly. udevadm can also help you.
 
But yeah, try lsmod first.

*High-Five*
 
I'm testing the 4.4 legacy kernel with the emergency patch, I added all the changes we made to it so as to protect the MiQi (And I think it's just smart).
 
I'll be working on 4.13 later today to get Dev set up.
 
I forgot to change the compatible line in the dts, so it didn't run the code.  Well, I guess that works.

I flashed the file from the download link above: Armbian_5.32.170724_Tinkerboard_Ubuntu_xenial_next_4.12.3_desktop.7z 
 
After entering root/1234/etc and getting to the desktop, the first thing I tried was a reboot, and it successfully rebooted back to the desktop. I tried again from the newly rebooted desktop, and success again. 

Yay ! So we got a 4.13 kernel that can reboot on ASUS Systems then ?

By that time, ASUS will already be using 4.9 kernels !
 
That said, if
echo b > /proc/sysrq-trigger  
works, one workaround will be to put this as the last action before rebooting.
 

AFAIK it's not related to systemd. Some loglevel overrides come from Debian/ubuntu default, i.e. on Xenial it's caused by /etc/sysctl.d/10-console-messages.conf (added by the "procps" package), and lack of kernel messages on any console can be caused by multiple console= defines on the kernel command line, since without explicit forwarding (i.e. by journald) kernel will print its boot log only on one console.

I used
echo b > /proc/sysrq-trigger to trigger reboot on 4.12.2 with the ugly hack installed, and it worked.  Without the hack it does not.  Let me see if I can apply it to the normal reboot process.

Ok... turns out that the mainlined rk3288.dtsi references a "job" IRQ that is completely unknown and fail the Mali GPU detection...
 
However, I did it the same way before and it worked. So I don't know what they've added that could fail...
 
Anyway, I've started to do some prep work for my new repositories. The first one is here and contains my new patches :
https://github.com/Miouyouyou/RockMyy
 
EDIT :
Well my 4.12 DTB file works so it's clearly an issue generated by the new definition...
 
Oh... please...
/tmp/RockMyy/linux/drivers/gpu/arm/midgard/mali_kbase_core_linux.c
if (!strncmp(irq_res->name, "JOB", 4)) { irqtag = JOB_IRQ_TAG; } else if (!strncmp(irq_res->name, "MMU", 4)) { irqtag = MMU_IRQ_TAG; } else if (!strncmp(irq_res->name, "GPU", 4)) { irqtag = GPU_IRQ_TAG; } else { dev_err(&pdev->dev, "Invalid irq res name: '%s'\n", irq_res->name); return -EINVAL; }  
I replaced the strncmp calls by strncasecmp and... it works...
 
Well, I'll reassemble the patches, and commit this.

Well, the reboot issue will be a problem if you want some kind of unattended web server that you can upgrade through SSH.
If you can unplug / plug the cable back, it will be a hassle, but not a blocker though. Since servers don't reboot that often, and personal servers on personal networks, shielded from the outside, almost never reboot, you might not even face it.
 
Anyway, I don't see any problem in using that board for a test web server, though Tinkerboard owners might be aware of network issues that I don't.
 
Note that you can run :
 
systemctl set-default multi-user.target  
To boot your system directly in text mode, instead of booting in desktop mode. From there, you might be able to delete desktop packages and keep only the server packages you need.

I'll take care of the patches this week. I thought that the rc1 would be released today, but it seems to have been released yesterday.
 
I'll incorporate the Mali r18p0 drivers this time, as they have incorporated various patches and are now directly usable with 4.11 kernels, lowering the number of patches required to integrate it with 4.13 kernels ! Yay !
 
For the reboot fixes, I'll wait until I get more logs from the Tinkering branch, in order to have a clearer understanding of the shutdown process.
For the bluetooth fixes, since nobody got it working with the weird Rockchip RFKill thingy, I'll try another way.
 
That said, the main focus with this release will be :
The hardware video decoder/encoder chip.
RK3288 boards are mostly advertised for their abilities to play videos smoothly, and a lot of tinkerboard owners just want to watch movies on Netflix with it. Trying to start pushing patches to arm-soc .
The more patches are integrated into the arm-soc branch, the less we'll have to maintain in the future. And the less, the merrier, when it comes to maintaining patches. Now, this might take a few days to get the first release coming, and the new releases will be done in a new repository that will be splitted in two. One of the kernel build scripts and patches, and one with the actual kernel files. That way, people looking for the builds won't have to download 100M of data and people looking for prebuilt kernels will have a clean repo and releases.

Well, I guess it already fits as it is - so there is no need for me to compile the Kernel?
Burned the SDcard with armbian 4.12 nightly (unfortunately desktop image, quite large).
What I did:
git clone -b Tinkering --depth 1 https://github.com/Miouyouyou/MyyQi cd MyyQi tar cJpvf kernel.tar.xz boot lib usr Followed by: sudo dolphin create a folder on the SDcard (home directory) copy the kernel.tar.xz into that. Connect the UART cable.
Insert the SDcard in tinker board, Power.
Boot the tinker board (reboot doesn't work so while extending the SDcard it 'dies').
Power off - Power on - login as root.
cd /home/tido/ Unpack all the files: tar xJpvf kernel.tar.xz open a second SSH look into the folder:
cd /usr/ ls -la copy the files
cp -r usr/* /usr/ cp -r lib/* /lib/ in the second SSH cd /boot ls -la cd /home/tido/boot/ ls -la cp -r zImage /boot/ cp -r rk3288-tinker.dtb /boot/dtb/ Armbian uses currently not the dtb called: tinker. Instead rk3288-miniarm.dtb rk3288-miqi.dtb. cp -r rk3288-miniarm.dtb /boot/dtb/ cp -r rk3288-miqi.dtb It is actually an easy instruction for everyone
uname -a
Linux tinkerboard 4.12.0-rc6-The-Twelve-MyyQi+ #1 SMP PREEMPT Fri Jun 30 19:37:05 UTC 2017 armv7l armv7l armv7l GNU/Linux
 
UART connection
reboot, it died at:
[  OK  ] Started Session c2 of user tido.

reboot - now I can login
armbianmonitor -u
/var/log/armhwinfo.log has been uploaded to http://sprunge.us/NAFa
 
Is this already in the file ? 
Add the following boot option to your boot loader : rockchip_tinkerrebootfix=on  
Just the shutdown
 
 
reboot command:
 

Hi @Myy,
I would like to test, but compiling and such is new to me.
I saw this in another forum:
This so called release is not an image but all you need to create a Kernel, right ?
 
I saw your posting with:

For someone like me who knows quite a bit but not as much as you do
Can or must I compile this on my x86 PC and burn it on the SDcard or  ..which is the correct way to proceed?
Hmm, or is this just the Kernel and DeviceTree that need to be compiled and copied into an armbian 4.12 as example?