fatugazuhati

Thank you @dbsharpe, I was been able to recompile the kernel on the device with that sources, but I'm not able to crosscompile the kernel with any toolchain, the compilation finish succesfully but I haven't an Image file for the kernel not any ko files for the modules. Do you have some idea of because this occours?

Thanks a lot, yesterday I searched for all the day but I wasn't be able to find this repo. Thank you.

Thanks for answering me but unfortunately that is the binary and can't help me. Anyway are you sure that it has support for vlan 8021q? About the sources for khadas-3.14, this is a big lost, in my opinion the Armbian versions with kernel 3.14 are the better one for s905/s912 devices, with them everything works and it is possible install Armbian in the emmc. The kernel 3.14 is outdated but COREElec too still uses a kernel 3.14 for theese devices. Honestly I don't understand why that branch has been deleted and not only archived.

Does someone have the sources for the old kernel khadas-3.14? It was just few mega. In the past I was able to git it with a simple: git clone -b khadas-3.14 https://github.com/150balbes/Amlogic_s905-kernel.git unfortunately I have never saved it and now it isn't more available in the @balbes150 repo, I never thought it would be removed. I'm using an s905 device with Armbian installed in the emmc and I would stay with this old version because with it everything works, but now I should recompile my kernel to add support for 8021q vlan. If someone has this kernel, please could he upload it somewhere? I really need it. I hope in a hand from you all.

About the wifi you have to lad the correct module, everything is explained in the first post. About the dtb, the best dtb is the one from your manufacturer so if it works you will never use a different dtb.

Try to boot Armbian with kernel 3.14 without any dtb, if it will fail please extract the dtb from your device and post it here.

You can use in armbian the dtb from libreelec.

Simply that it isn't present in your boot img. Yes, you can but it is not so simple and if I'm not in error you should found the answer in the s905/s905x thread.

It is a kernel process and you can check the problem in this way: ps aux | grep " D" root 2534 0.0 0.0 0 0 ? D 14:29 0:03 [vdec-core] root 6948 0.0 0.0 4312 648 pts/0 S+ 15:59 0:00 grep D @balbes150, if can help in dmesg I have this: dmesg | grep vdec [ 5.735325] codec:get gate vdec control ok ffffffc09319c000 [ 5.739991] codec:vdec_request_irq ffffffc00184efa8, vsync [ 5.861875] codec:used fix clk for vdec clk source! Instead using the kernel from Jessie with wich this problem isn't present in dmesg I have this: dmesg | grep vdec [ 5.657064] codec:get gate vdec control ok ffffffc0b3816500 [ 5.661865] codec:used fix clk for vdec clk source!

Did you noticed that also in a clean install at system in idle we always have a system load that never goes under 1 caused by vdec-core in uninterruptible sleep? This is a kernel related problem appeared in last versions and I have reported it here. Do you have some idea about what do to?

After a clean install of debian stretch you can notice a strange load when the system is in idle, also if the cpu is at 0% and we have almost all the ram free we can notice a strange load average. The load should be 0 but it never goes under 1. You can notice this with the commands "top" or "uptime" but I'm sure that you know this :-) With the command "ps -e v" I noticed that there is the process vdec-core that always waits for disk access (D) and in effect you can continuosly see this process in the top and should be for this that the load never goes to 0. After some search I discovered that this should be something kernel related, but I'm not sure what this is. Remembering that in jessie everythings was working correctly and that in the same conditions I had a load of 0, I have simply tried to using the kernel from jessie in stretch to see what happened, I have simply replaced the zimage and in this way the process vdec-core has disappeard and with the cpu at 0% now i have a load of almost 0, how this should be. At the moment to solve this problem I'm using the zimage from jessie in stretch but I'd like to stay with an updated kernel. What should we do to solve the problem? Do you know what vdec-core is?

Has something been changed in the kernel to solve the abnormal load caused by vdec-core?

Same abnormal load caused by vdec-core also in Armbian_5.41_S9xxx_Debian_stretch_3.14.29_server_20180212.img, to avoid the problem I'm using the kernel from jessie but is there any chance to solve this problem in the stretch kernel?

No one noticed a strange load in stretch? Wit a clean install, the cpu at 0% and with almost all the ram free the load never goes under 1. In jessie in the same conditions I have a load of 0. I'm trying to understand why this happens. Ok, the culprit is vdec-core that always waits for disk access and the problem is in the kernel, using the kernel from jessie everything works correctly. I would use an updated kernel, how can this problem been solved?

I'm comparing jessie with stretch from yesterday but without much success. Anyway I have just tried with Armbian_5.37_S9xxx_Ubuntu_xenial_3.14.29_mate_20180205.img and the remote still doesn't work, for example if I press the power-off button nothing happens and in the syslog I have this: Feb 5 20:51:01 localhost kernel: [ 563.265710@0] remote: press ircode = 0x18, Feb 5 20:51:01 localhost kernel: [ 563.265735@0] remote: scancode = 0x0074,maptable = 0,code:0xe718ff00 Feb 5 20:51:01 localhost kernel: [ 563.265777@0] Feb 5 20:51:01 localhost kernel: [ 563.625406@0] remote: release ircode = 0x18, Feb 5 20:51:01 localhost kernel: [ 563.625430@0] remote: scancode = 0x0074, maptable = 0,code:0x00000000 Feb 5 20:51:01 localhost kernel: [ 563.625445@0] Solved :-) I had to write a new rule, thanks for your hard work.