Igor

I see like this: I guess this https://forum.armbian.com/index.php?/discover/&view=condensed is closes to it. We can change that but let's wait.

It's fixed but I haven't try it yet.

I hope you like the upgrade, which was done on urgent notice due to database failure and we started from this morning's backup. We apologise for some deleted posts and users, wrong settings and possible bugs. Since our previous forum was 5-6 years old, upgrade is tremendous but we will try to keep it similar on function level. There was a plan for redesign but this will be done once in the future. Enjoy!

We don't deal with KODI whatsoever and AFAIK you need to fix lot's of things so better stick to Openelec. It can't be more simple that that. You can watch videos and Youtube videos with HW acceleration within Armbian desktop (A10/A20/H3) but not within any browser. Preinstalled mpv only. https://forum.armbian.com/index.php/topic/3260-orange-pi-plus-armbian-how-to-watch-youtube-videos-very-slow/?hl=youtube

It looks like headers are broken in recent build ... workaround is to start with older build (and not update) or if you find out why we have broken headers.

Thank you. We fixed this problem - but after the release. We will try to push some bug fix update ASAP. https://github.com/igorpecovnik/lib/commit/282e530d02f78e61faf6a5475a08cec0ee81d485

If you started with our clean image, headers are already in place, right where they should be. But it looks like the problem is elsewhere.

If you have recent build, you have to change verbosity=x in /boot/armbianEnv.txt since this overrides settings in boot.cmd ... if you want to get rid of early boot messages with armbian logo, you need to start here: https://docs.armbian.com/Developer-Guide_Build-Preparation

It's: nand-sata-install

sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 71.6801s total number of events: 10000 total time taken by event execution: 286.6122 per-request statistics: min: 25.38ms avg: 28.66ms max: 85.60ms approx. 95 percentile: 32.45ms Threads fairness: events (avg/stddev): 2500.0000/6.56 execution time (avg/stddev): 71.6530/0.02 Where / which 2Ghz patch? ... I can try it later. Just received eMMC for XU4 to try to fix that problem.

Yes, you are correct. It was on powersave, those are now on proper speed: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 79215.37k 86050.52k 89357.40k 90211.33k 90456.06k bf-cbc 50721.71k 57495.64k 59830.53k 60454.91k 60631.72k

Overscan solves small screen irregularity, which is not the case. Here is how to use this: https://docs.armbian.com/Hardware_Allwinner/#how-to-reconfigure-video-output

(modern) betas uses auto detection and a driver which was adopted by @jernej to work on H3 boards and a kernel make use of this screen initialisation (simplefb driver). Video driver has certain limitations, but for normal work is perfectly fine. On kernel 3.4.113, we use stock video driver provided by Allwinner and patch by community. They support only few screen sizes, the rest was added by us. If you don't need to watch movies or play games, stick to betas and forget about ... otherwise start with the task list

ARMBIAN 5.26 stable Ubuntu 16.04.2 LTS 4.4.51-rockchip openssl speed -elapsed -evp bf-cbc aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 4194998 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 1163073 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 302774 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 76480 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 9587 aes-128 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 3308303 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1000628 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 263953 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 66903 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 8398 bf-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Jan 27 00:26:25 2017 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 22373.32k 24812.22k 25836.71k 26105.17k 26178.90k bf-cbc 17644.28k 21346.73k 22523.99k 22836.22k 22932.14k

We added a lot of new resolutions but some of them might not be fully tested. I can only test few of them ... Anyway in such case you need hacking power. No simple solution yet. At least not known to me. 1. Search the forum for similar problems - how to set custom resolution. There was some success stories for bringing some odd screen sizes to the kernel driver. 2. Calculate and provide new / working parameters for your display 3. Recompile kernel - boot - try - change - recompile ... until you got the proper picture. Do you have a proper screen at bootloader ? Is it detected properly? Have you checked betas: https://www.armbian.com/orange-pi-lite/#nightly

"Rewriting the driver" manual does not exists. In 4.x driver was fixed up to certain level and it's still not perfect, but it works better. But kernel 4.x is in general still Work In Progress / beta / testing. How to jump into betas: https://forum.armbian.com/index.php/topic/2422-more-proper-testing-better-armbian-experience/

And the only one? I am sure there is room for improvement, but just don't expect that you will jump on experienced developer level in one day. This script become complex if you go out of default zone. This build system is used by us on daily basis and there more and more 3rd party users who are using it for their purpose. If something goes wrong, we fix it or they fix it - with specific fixes, since saying "this script sux" is useless information. Feel free to use and compare to alternative solution if you make them work http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=2451&extra= http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=394

What is the screen resolution of your display?

By rewriting wireless driver since it's buggy. In kernel 4.x this problem should be gone.

Safe to ignore and safe to delete those directories.

5.14 is old build and those boot scripts are different, upgrade is also not recommended. Perhaps better to start with fresh image ...

https://forum.armbian.com/index.php/topic/2344-pwm-on-allwinner-h3/ And use this search engine to get other posts regarding pwm: https://www.armbian.com/search_gcse/

I completely understand your wish but what you want to achieve is hard even for hardcore Linux users, since there is no working (stable and with HW acceleration) packaged KODI for Debian / Ubuntu for those boards (H3). This doesn't mean it's impossible, but if you are a newbie, forget about ... Get some other platform, preferable Intel, where this is near to easy install ... or use one H3 board for server with Armbian and another one for media centre running Openelec.

If you want KODI on this board, check down.nu if there is an Openelec build for this board. This is only possible working solution.

Main repository was updated - all kernels were fixed and updated to latest versions.