@lex

I think VIDEO_SUN6I_CSI=m is missing. I did not see it in the patch. * I mean if you load it as module you can see it loaded if =y i cant see it. In other words: CONFIG_VIDEO_SUN6I_CSI=m CONFIG_V4L_MEM2MEM_DRIVERS=y CONFIG_VIDEO_MEM2MEM_DEINTERLACE=m CONFIG_VIDEOBUF2_CORE=m CONFIG_VIDEOBUF2_V4L2=m CONFIG_VIDEOBUF2_MEMOPS=m CONFIG_VIDEOBUF2_DMA_CONTIG=m CONFIG_VIDEOBUF2_VMALLOC=m CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_VIDEO_V4L2=m CONFIG_VIDEO_TUNER=m CONFIG_V4L2_MEM2MEM_DEV=m CONFIG_V4L2_FWNODE=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_DVB_CORE=m

That's interesting. And then the fun begins, i gave it a try using r8p1 with kernel 4.4 on A64 and it works... a bit slow but works, though i don't know for how long. Framebuffer only. The weird thing (it's kind of frankenstein): ======================================================= glmark2 2012.12 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-400 MP GL_VERSION: OpenGL ES 2.0 "mali450-r5p1-01rel0-lollipop-233-g52c929d" ======================================================= [build] use-vbo=false: FPS: 60 FrameTime: 16.667 ms [build] use-vbo=true: FPS: 60 FrameTime: 16.667 ms [texture] texture-filter=nearest: FPS: 60 FrameTime: 16.667 ms [texture] texture-filter=linear: FPS: 60 FrameTime: 16.667 ms [texture] texture-filter=mipmap: FPS: 60 FrameTime: 16.667 ms [shading] shading=gouraud: FPS: 60 FrameTime: 16.667 ms Does Anyone one know a complete recipe for building KODI or similar (framebuffer) to check if this is really working?

Here is a diff patch for mainline kernel. Apply from the kernel root tree. Enter menuconfig to Enable VIDEO / CSI , don't know about your camera. or how you wire it. patch -p0 -i sun6i_csi.dif.patch sun6i_csi.dif.patch.tar.gz

If anyone is wondering how is the performance of the driver, just take a look: ---- cap parameters ----- width: 1920 height: 1080 v4l2 buffers: 4 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sun6i-video" Card: "sun6i-csi" Bus: "platform:camera" Version: 1.0 Capabilities: 84200001 Input: 0 V4L2 pixel formats: 0: [0x59565955] 'UYVY' (UYVY 4:2:2) 1: [0x32314D48] 'HM12' (YUV 4:2:0 (16x16 Macroblocks)) 2: [0x3231564E] 'NV12' (Y/CbCr 4:2:0) 3: [0x3132564E] 'NV21' (Y/CrCb 4:2:0) 4: [0x32315559] 'YU12' (Planar YUV 4:2:0) 5: [0x32315659] 'YV12' (Planar YVU 4:2:0) 6: [0x3631564E] 'NV16' (Y/CbCr 4:2:2) 7: [0x3136564E] 'NV61' (Y/CrCb 4:2:2) 8: [0x50323234] '422P' (Planar YUV 4:2:2) 9: [0x56595559] 'YUYV' (YUYV 4:2:2) 10: [0x32314D48] 'HM12' (YUV 4:2:0 (16x16 Macroblocks)) 11: [0x3231564E] 'NV12' (Y/CbCr 4:2:0) 12: [0x3132564E] 'NV21' (Y/CrCb 4:2:0) 13: [0x32315559] 'YU12' (Planar YUV 4:2:0) 14: [0x32315659] 'YV12' (Planar YVU 4:2:0) 15: [0x3631564E] 'NV16' (Y/CbCr 4:2:2) 16: [0x3136564E] 'NV61' (Y/CrCb 4:2:2) 17: [0x50323234] '422P' (Planar YUV 4:2:2) V4L2 pixel sizes: Sensor size: 1920x1080 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 3110400 Bytesused: 3110400 Address: 0x55b01b9670 FPS[0]: 25.77 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b9680 FPS[1]: 30.06 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b9690 FPS[2]: 30.01 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b96a0 FPS[3]: 29.79 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b9670 FPS[4]: 30.32 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b9680 FPS[5]: 30.04 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b9690 FPS[6]: 29.95 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b96a0 FPS[7]: 30.14 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b9670 FPS[8]: 29.81 Length: 3110400 Bytesused: 3110400 Address: 0x55b01b9680 FPS[9]: 0.72 ------- Avg FPS: 30.02 --------

Today I had a chance to test OV5640 on mainline kernel 4.17.2 and see the status of OV5640 and CSI drivers, thanks to FE work and the author of the driver (help name here...). I tested on NanoPi K1 Plus (H5) to verify the images in very low light conditions, so don't expect good quality. I could take some images using fswebcam and you should expect basic v4l2 functionality already works if not all. I think motion (did not test / had time to test it) can work with current OV5640 on mainline kernel. Grabbing Image is very fast, currently, Image size I can get are 320x240 and 640x480 pixels, above this i get a dark image. I have not looked at the driver source code to see if it is implemented or not. Basically, you need to add the sun6i_csi and ov5640 drivers to the kernel and adjust DT to have the endpoint. FE has already done it and left H5 for homework, but is the same as H3. To check the functionality, install v4l2-utils and when the driver sun6i_cs loads, it creates the device node /dev/video0 and you can check that: sudo v4l2-ctl -d /dev/video0 -D Driver Info (not using libv4l2): Driver name : sun6i-video Card type : sun6i-csi Bus info : platform:camera Driver version: 4.17.2 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format You should see the modules loaded like this: lsmod Module Size Used by sun6i_csi 24576 0 videobuf2_dma_contig 20480 1 sun6i_csi videobuf2_memops 16384 1 videobuf2_dma_contig ov5640 36864 1 videobuf2_v4l2 24576 1 sun6i_csi videobuf2_common 40960 2 videobuf2_v4l2,sun6i_csi v4l2_fwnode 20480 2 ov5640,sun6i_csi v4l2_common 16384 1 ov5640 videodev 196608 6 v4l2_fwnode,v4l2_common,ov5640,videobuf2_v4l2,sun6i_csi,videobuf2_common sunxi_cir 16384 0 media 36864 3 videodev,ov5640,sun6i_csi rc_core 40960 2 sunxi_cir sch_fq_codel 20480 6 8189es 1118208 0 So time to revisit the camera drivers on mainline. Here are some images (remember, low light condition!): *update: All possible window sizes are working for streaming!

I have spent a lot of time on this and latest package should fix that, hopefully: https://patchwork.kernel.org/patch/10128825/

This message only means cfg89211 will be using regulatory.bin instead and wifi will work without "full power". Your wifi issue is not related to the message. You have to rebuild the regulatory.db. Refer to this: https://github.com/torvalds/linux/commit/007f6c5e6eb45c81ee89368a5f226572ae638831#diff-55082e23fa6f38caacaeaed852a04418

just for reference, I've based on 4.17.0.rc7 and this seems to work: ths: ths@1c25000 { #thermal-sensor-cells = <0>; compatible = "allwinner,sun8i-h3-ths"; reg = <0x01c25000 0x400>, <0x01c14234 0x4>; reg-names = "ths", "calibration"; interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>; resets = <&ccu RST_BUS_THS>; reset-names = "ahb"; clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>; clock-names = "ahb", "ths"; };

Yes, but this patch seems to do a lot more, you can apply the SUN8I THS.

You need to apply the THS patch.

last numbers: openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 21097762 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 13885050 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 5712407 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1744124 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 232965 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 116966 aes-256-cbc's in 3.00s OpenSSL 1.1.0g 2 Nov 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 112521.40k 296214.40k 487458.73k 595327.66k 636149.76k cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.54 ms. hardware limits: 480 MHz - 1.37 GHz available frequency steps: 480 MHz, 648 MHz, 720 MHz, 768 MHz, 912 MHz, 1.08 GHz, 1.20 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.37 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.37 GHz. cpufreq stats: 480 MHz:4.74%, 648 MHz:1.64%, 720 MHz:0.35%, 768 MHz:0.59%, 912 MHz:0.48%, 1.08 GHz:0.44%, 1.20 GHz:0.38%, 1.37 GHz:91.36% (3239) at least, 4.17 pretty stable... I think there is room for improvement, board does not get Temp over 54 ºC so lets the experts handle this...

./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 1099.0 MB/s (0.9%) C copy backwards (32 byte blocks) : 1095.5 MB/s (0.9%) C copy backwards (64 byte blocks) : 1086.3 MB/s (0.4%) C copy : 1097.6 MB/s (1.2%) C copy prefetched (32 bytes step) : 892.8 MB/s (0.3%) C copy prefetched (64 bytes step) : 993.4 MB/s C 2-pass copy : 1096.8 MB/s C 2-pass copy prefetched (32 bytes step) : 758.1 MB/s C 2-pass copy prefetched (64 bytes step) : 714.6 MB/s C fill : 3859.1 MB/s (0.1%) C fill (shuffle within 16 byte blocks) : 3856.1 MB/s C fill (shuffle within 32 byte blocks) : 3856.9 MB/s C fill (shuffle within 64 byte blocks) : 3854.5 MB/s --- standard memcpy : 1116.0 MB/s (0.3%) standard memset : 3858.4 MB/s (0.1%) --- NEON LDP/STP copy : 1124.8 MB/s (0.2%) NEON LDP/STP copy pldl2strm (32 bytes step) : 799.7 MB/s (0.4%) NEON LDP/STP copy pldl2strm (64 bytes step) : 963.3 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 1164.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 1164.5 MB/s NEON LD1/ST1 copy : 1109.6 MB/s (0.5%) NEON STP fill : 3860.1 MB/s (0.1%) NEON STNP fill : 3584.2 MB/s (0.7%) ARM LDP/STP copy : 1126.1 MB/s (0.2%) ARM STP fill : 3858.9 MB/s ARM STNP fill : 3584.7 MB/s (0.8%) ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read, [MADV_NOHUGEPAGE] 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 5.0 ns / 8.4 ns 131072 : 7.7 ns / 11.7 ns 262144 : 9.0 ns / 13.1 ns 524288 : 10.6 ns / 15.0 ns 1048576 : 94.4 ns / 145.3 ns 2097152 : 139.6 ns / 187.6 ns 4194304 : 168.3 ns / 208.4 ns 8388608 : 183.7 ns / 217.9 ns 16777216 : 192.6 ns / 224.3 ns 33554432 : 197.2 ns / 228.1 ns 67108864 : 201.0 ns / 232.2 ns block size : single random read / dual random read, [MADV_HUGEPAGE] 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 5.0 ns / 8.4 ns 131072 : 7.7 ns / 11.7 ns 262144 : 9.0 ns / 13.1 ns 524288 : 10.6 ns / 14.8 ns 1048576 : 94.4 ns / 145.3 ns 2097152 : 139.0 ns / 186.9 ns 4194304 : 161.5 ns / 200.8 ns 8388608 : 172.7 ns / 205.8 ns 16777216 : 177.9 ns / 208.0 ns 33554432 : 180.3 ns / 209.1 ns 67108864 : 181.5 ns / 209.6 n cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.54 ms. hardware limits: 480 MHz - 1.37 GHz available frequency steps: 480 MHz, 648 MHz, 720 MHz, 768 MHz, 912 MHz, 1.08 GHz, 1.20 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.37 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.37 GHz. cpufreq stats: 480 MHz:7.33%, 648 MHz:2.53%, 720 MHz:0.54%, 768 MHz:0.92%, 912 MHz:0.75%, 1.08 GHz:0.68%, 1.20 GHz:0.59%, 1.37 GHz:86.66% (3239)

Tweaked DTS, some other numbers: cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 294543 iterations per second for 256-bit key PBKDF2-sha256 525865 iterations per second for 256-bit key PBKDF2-sha512 215578 iterations per second for 256-bit key PBKDF2-ripemd160 171335 iterations per second for 256-bit key PBKDF2-whirlpool 75328 iterations per second for 256-bit key argon2i 4 iterations, 229155 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) argon2id 4 iterations, 231680 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) # Algorithm | Key | Encryption | Decryption aes-cbc 128b 328.1 MiB/s 378.3 MiB/s serpent-cbc 128b 29.1 MiB/s 31.2 MiB/s twofish-cbc 128b 43.4 MiB/s 47.1 MiB/s aes-cbc 256b 287.6 MiB/s 351.6 MiB/s serpent-cbc 256b 29.1 MiB/s 31.2 MiB/s twofish-cbc 256b 43.4 MiB/s 47.1 MiB/s aes-xts 256b 344.4 MiB/s 345.0 MiB/s serpent-xts 256b 31.0 MiB/s 31.9 MiB/s twofish-xts 256b 47.7 MiB/s 48.4 MiB/s aes-xts 512b 321.7 MiB/s 322.3 MiB/s serpent-xts 512b 31.0 MiB/s 31.9 MiB/s twofish-xts 512b 47.6 MiB/s 48.4 MiB/s

I would like to throw some numbers here gathered with kernel 4.17.rc6 though i don't know if it is good or bad. Seems to be very conservative. I did not find any suitable cpuburn on ubuntu 18.04. sudo sysbench --test=cpu --cpu-max-prime=20000 --threads=4 run && cat /sys/devices/virtual/thermal/thermal_zone0/temp WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options. sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Prime numbers limit: 20000 Initializing worker threads... Threads started! CPU speed: events per second: 1081.94 General statistics: total time: 10.0031s total number of events: 10829 Latency (ms): min: 3.67 avg: 3.69 max: 23.10 95th percentile: 3.68 sum: 39997.95 Threads fairness: events (avg/stddev): 2707.2500/10.85 execution time (avg/stddev): 9.9995/0.00 44700 cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.54 ms. hardware limits: 120 MHz - 1.37 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 528 MHz, 648 MHz, 672 MHz, 720 MHz, 768 MHz, 792 MHz, 816 MHz, 864 MHz, 912 MHz, 936 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.08 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 120 MHz and 1.37 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 648 MHz. cpufreq stats: 120 MHz:41.54%, 240 MHz:20.22%, 480 MHz:9.63%, 528 MHz:5.36%, 648 MHz:2.36%, 672 MHz:1.31%, 720 MHz:1.67%, 768 MHz:0.65%, 792 MHz:0.57%, 816 MHz:1.10%, 864 MHz:1.34%, 912 MHz:0.60%, 936 MHz:0.36%, 960 MHz:0.43%, 1.01 GHz:0.58%, 1.06 GHz:0.30%, 1.08 GHz:0.26%, 1.10 GHz:0.32%, 1.15 GHz:0.52%, 1.20 GHz:0.57%, 1.22 GHz:0.32%, 1.25 GHz:0.69%, 1.30 GHz:0.34%, 1.34 GHz:0.00%, 1.37 GHz:8.98% (12516) running 12 x sysbench sudo sysbench --test=cpu --cpu-max-prime=20000 --threads=4 run && cat /sys/devices/virtual/thermal/thermal_zone0/temp WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options. sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Prime numbers limit: 20000 Initializing worker threads... Threads started! CPU speed: events per second: 1078.11 General statistics: total time: 10.0034s total number of events: 10791 Latency (ms): min: 3.67 avg: 3.71 max: 23.34 95th percentile: 3.68 sum: 39996.37 Threads fairness: events (avg/stddev): 2697.7500/23.50 execution time (avg/stddev): 9.9991/0.00 58513 cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.54 ms. hardware limits: 120 MHz - 1.37 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 528 MHz, 648 MHz, 672 MHz, 720 MHz, 768 MHz, 792 MHz, 816 MHz, 864 MHz, 912 MHz, 936 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.08 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 120 MHz and 1.37 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.37 GHz. cpufreq stats: 120 MHz:45.29%, 240 MHz:20.85%, 480 MHz:8.56%, 528 MHz:4.79%, 648 MHz:2.15%, 672 MHz:1.32%, 720 MHz:1.37%, 768 MHz:0.72%, 792 MHz:0.51%, 816 MHz:0.94%, 864 MHz:1.01%, 912 MHz:0.42%, 936 MHz:0.25%, 960 MHz:0.34%, 1.01 GHz:0.40%, 1.06 GHz:0.19%, 1.08 GHz:0.18%, 1.10 GHz:0.16%, 1.15 GHz:0.27%, 1.20 GHz:0.35%, 1.22 GHz:0.31%, 1.25 GHz:0.63%, 1.30 GHz:0.21%, 1.34 GHz:0.00%, 1.37 GHz:8.78% (37950)

I think that was the FE approach. I took a step further, i pulled linus 4.17.rc5, applied the 8189es patch and sy8189a patch, adjusted DT and it's working smooth. Just a small note, i could not get SPI to work, i suspect there is something with rtl8189etv. I wired the 2.8" LCD and wlan stopped working but could be some of my mistakes. the rtl wifi keeps spitting ==> rtl8188e_iol_efuse_patch , removing the LCD wlan worked again. [ 6.767828] RTL8211E Gigabit Ethernet 0.2:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=0.2:00, irq=POLL) [ 6.769361] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available [ 6.769375] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW [ 6.769932] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 6.899748] random: crng init done [ 6.899755] random: 7 urandom warning(s) missed due to ratelimiting [ 7.193944] ==> rtl8188e_iol_efuse_patch [ 7.481112] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 7.965815] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 7.972452] rtc-ds1307: probe of 0-0068 failed with error -110 [ 34.781921] ==> rtl8188e_iol_efuse_patch [ 39.737899] ==> rtl8188e_iol_efuse_patch [ 52.573897] ==> rtl8188e_iol_efuse_patch [ 62.545893] ==> rtl8188e_iol_efuse_patch [ 76.741896] ==> rtl8188e_iol_efuse_patch [ 81.502589] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 81.502625] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 96.705898] ==> rtl8188e_iol_efuse_patch [ 111.133896] ==> rtl8188e_iol_efuse_patch i have chosen ubuntu 18.04 but i found it bloated, systemd has a lot of useless or unnecessary services , ubuntu 16.04 still better tuned. Without hdmi (enabled) Temp is way low in idle node. Unfortunately, i could not grab any info from this kernel... I think NEO2 with sy8189 will really shine.

I don't see a driver for it on the mainline kernel, any ideas? ahh, ok, seems to be RTL8189ES...

ahh, OK, i will try and see the results.

Sorry if i confused you. SPI_LCD works really great (thanks for the lib). It's fbtft (framebuffer) that has the issue i tried to describe for the same FPS and the same frequency. as SPI_LCD. Can't find a reason.

Just a little observation, i received two samples of the ili9341, the first sample runs for about 01:15 until it starts to draw white stripes on refreshing the buffer and finally gets a white screen, this happens on fbft . I started to think fbft still have some bug as in 3.x . Surprisingly your SPI_LCD runs for 2 hrs without any glitches, i have put your example in a loop. I then started to experiment with different FPS and SPI max speed until i reached a stable performance with the second display sample. i am still in doubt if it is a hardware issue (display) or fbft issue for the ili9341.

@Larry Bank If you allow me I would suggest changing source code format to be something self-explanatory, what about: #ifdef USE_NANOPINEO // NanoPi NEO // define 40 pins since the 12 pin header has 2 GPIOs available and so does // the 4-pin TTY header static int iGenericPins[] = { -1, /* Physical pin <-> GPIO pin */ /* 1 , 2 */ -1, -1, /* 3 , 4 */ 12, -1, /* 5 , 6 */ 11, -1, /* 7 , 8 */ 203, 198, /* 9 , 10 */ -1, 199, /* 11 , 12 */ 0, 6, /* 13 , 14 */ 2, -1, /* 15 , 16 */ 3, 200, /* 17 , 18 */ -1, 201, /* 19 , 20 */ 64, -1, /* 21 , 22 */ 65, 1, /* 23 , 24 */ 66, 67, -1, -1, -1, -1, -1, 363, 17, -1, -1, -1, -1, -1, -1, -1, 4, 5 }; #endif // USE_NANOPINEO but it is up to you. This is for the anxious person like me... @yam1 Curious about your dual-head solution...

Ok, I figured out what I missed with @Larry Bank SPI_LCD. According to my wiring, I needed to adjust: rc = spilcdInit(LCD, 0, 0, 36000000, 22, 7, 11); // LCD type, flip 180, SPI Channel, D/C, RST, LED That was it! @yam1 , Nice work. I just noticed all your photo has LCD turned off, what are you running on it, X11 or fb?

Sorry, just compiled straight. Will do it, must be that. It's going to be a busy week, not in a hurry. Thanks. Just an update, I changed to NanoPi NEO, compiled and ran, the same problem. Did that, the backlight is on, still the same output and error. Yes, but late in the night the room was dark with LED lights and the camera (cell phone) is cheap, the only way to see something was with flash. Probably so. I will revise everything and try to contact you that way.

Only enabled spidev, unless uart2 is default on Armbian but it did not show uart selected on Armbian-config, will check again. Sorry, just compiled straight. Will do it, must be that. It's going to be a busy week, not in a hurry. Thanks.

Please, forgive the quality of the pictures:

pin: 7 for LCD_RESET (that i suppose is your lcd) pin 11 for LED_EN (that i suppose is your led) pin 22 for LCD_D/C (that i suppose is your dc) Taken from the http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2 and here base on the Matrix-2'8_SPI_Key_TFT-1706, but the LCD is without Touch.