@lex

Members
  • Content count

    348
  • Joined

  • Last visited

About @lex

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

938 profile views
  1. 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!):
  2. I have spent a lot of time on this and latest package should fix that, hopefully: https://patchwork.kernel.org/patch/10128825/
  3. 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
  4. 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"; };
  5. Yes, but this patch seems to do a lot more, you can apply the SUN8I THS.
  6. You need to apply the THS patch.
  7. @lex

    NanoPi K1 Plus to be released soon

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

    NanoPi K1 Plus to be released soon

    ./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)
  9. @lex

    NanoPi K1 Plus to be released soon

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

    NanoPi K1 Plus to be released soon

    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)
  11. @lex

    NanoPi K1 Plus to be released soon

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

    NanoPi K1 Plus to be released soon

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

    Display ili9341 on H5

    ahh, OK, i will try and see the results.
  14. @lex

    Display ili9341 on H5

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

    Display ili9341 on H5

    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.