@lex

Members
  • Content Count

    414
  • Joined

  • Last visited


Reputation Activity

  1. Like
    @lex got a reaction from guidol in htop has strange "layout"   
    Type in the shell:
    printf   "This is ASCII representation:\n|\n\`\n\`-\nThis is UTF-8 representation:\n\xe2\x94\x82\n\xe2\x94\x9c\n\xe2\x94\x94\xe2\x94\x80\n"
     
    You should see this:
    This is ASCII representation:
    |
    `
    `-
    This is UTF-8 representation:


    └─
     
    If you don't see the above representation, you should set UTF-8 for your language in Terminal.
  2. Like
    @lex got a reaction from pazzoide in htop has strange "layout"   
    htop was built without support for ncursessw (shared libraries for terminal handling (wide character support)).
    I realized that is not the problem, i found out if you run htop from ssh terminal and from a console terminal you get ASCII on one and UTF-8 on the other (or vice-versa) and both have UTF-8 support.
    Can you please check if you have the same behavior?  
     
     
  3. Like
    @lex got a reaction from guidol in htop has strange "layout"   
    Type in the shell:
    printf   "This is ASCII representation:\n|\n\`\n\`-\nThis is UTF-8 representation:\n\xe2\x94\x82\n\xe2\x94\x9c\n\xe2\x94\x94\xe2\x94\x80\n"
     
    You should see this:
    This is ASCII representation:
    |
    `
    `-
    This is UTF-8 representation:


    └─
     
    If you don't see the above representation, you should set UTF-8 for your language in Terminal.
  4. Like
    @lex got a reaction from guidol in [Experiment] armbian on NanoPi A64   
    My last update on this issue in case someone is working to get sound on A64 (>= 4.20).
    I tried every patch out there,  triple checked the code , same situation, no sound. 
    I must have missed something or overlooked something.
    I finally tried Vasily's kernel and for my surprise no sound. Last hope, i tried Vasily ARCH img, no luck, no sound even on Pine64.
    Maybe it works on Pinebook,.... 
     
  5. Like
    @lex reacted to zador.blood.stained in NanoPC T4   
    Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
  6. Like
    @lex got a reaction from Tido in Monitoring your system health with HTOP (big.LITTLE)   
    Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time.
    You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core.
     
    HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager.
    DEB package and source code in case you want to extend or fix things.
    Be aware the process list and task can be very intrusive if you want to monitor many things at once.
    It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version.
     
    https://github.com/avafinger/htop-2.1.1_enhanced-version
     

  7. Like
    @lex got a reaction from Tido in Monitoring your system health with HTOP (big.LITTLE)   
    Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time.
    You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core.
     
    HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager.
    DEB package and source code in case you want to extend or fix things.
    Be aware the process list and task can be very intrusive if you want to monitor many things at once.
    It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version.
     
    https://github.com/avafinger/htop-2.1.1_enhanced-version
     

  8. Like
    @lex got a reaction from Werner in Orange pi one plus - 1800 MHz   
    Ok then, here is my take on the matter.
     
    You have to build the new image or wait for @Igor
     
    * Apply the patch described on the thread
    * Change the regulator like this:
     
                reg_dcdca: dcdca {                 regulator-always-on;                 regulator-min-microvolt = <810000>;                 regulator-max-microvolt = <1160000>;                 regulator-name = "vdd-cpu";             };  
    * rebuild Image
     
    There you have it:
    7z b 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=C.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs LE) LE CPU Freq:  1717  1796  1796  1796  1796  1796  1796  1796  1796 RAM size:     964 MB,  # CPU hardware threads:   4 RAM usage:    882 MB,  # Benchmark threads:      4                        Compressing  |                  Decompressing Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating          KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS 22:       2679   333    783   2607  |      70708   388   1554   6033 23:       2615   333    800   2665  |      66860   388   1489   5785 24:       2545   333    821   2736  |      63737   390   1436   5595 25:       2420   329    839   2763  |      57802   388   1324   5144 ----------------------------------  | ------------------------------ Avr:             332    811   2693  |              389   1451   5639 Tot:             360   1131   4166  
  9. Like
    @lex got a reaction from Werner in Orange pi one plus - 1800 MHz   
    You might ask @tkaiser, he did that on PineH64 and that applies to Opi One Plus.
     
     
  10. Like
    @lex got a reaction from Werner in Orange pi one plus - 1800 MHz   
    It is fine.
     
    For the torture test, better use a good heatsink.
    I just would like to comment that if you have an image without HDMI (no fb) and a good heatsink you get slightly better values.
    Now is time to move on and learn new platforms... 
  11. Like
    @lex got a reaction from tkaiser in Trying to compile Pine H64   
    OrangePi One Plus BSP 4.9, kernel 4.9.56 stock for analisys. 
    Here is DRAM initialization in use (hope is what you meant):
    [271]PMU: AXP806 [275]set pll start [278]set pll end [279]rtc[0] value = 0x00000000 [282]rtc[1] value = 0x00000000 [285]rtc[2] value = 0x00000000 [288]rtc[3] value = 0x00000000 [292]rtc[4] value = 0x00000000 [295]rtc[5] value = 0x00000000 [298]DRAM VERSION IS V2_5 [300]PMU:Set DDR Vol 1200mV OK. [304]PMU:Set DDR Vol 1200mV OK. [314]BYTE0 GATE ERRO IS = 00000002 [318]BYTE1 GATE ERRO IS = 00000002 [321]BYTE2 GATE ERRO IS = 00000002 [324]BYTE3 GATE ERRO IS = 00000002 [336]DRAM CLK =744 MHZ [338]DRAM Type =7 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3) [343]DRAM zq value: 003b3bfb [350]IPRD=006f006e--PGCR0=00000f5d--PLL=b0003d00 [354]DRAM SIZE =1024 M,para1 = 000030fa,para2 = 04000000 [366]DRAM simple test OK. [369]dram size =1024 tinymembench, running first time with interactive governor:

    CPU:
    Running subsequent tinymembench with performance governor:
     
    CPU:
     
     
    Things you should consider in your analysis that could favor some results or not.
     
    * axp806 not detected by kernel
    [    0.431724] [axp806] chip id not detect 0xff ! [    1.496996] input: axp80x-powerkey as /devices/platform/soc/pmu0/axp80x-powerkey/input/input0 [    4.925539] axp80x_aldo1: unsupportable voltage range: 858992688-3300000uV * eth not functional
    [    0.816207] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:csi0 [    0.824909] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdc0 [    0.833599] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdio0 [    0.843450] gmac-power2: NULL [   11.600421] libphy: gmac0: probed And the usual:
     
     
    I am pretty sure it runs at 1.8 GHz:
    CPU1 freq      : 1800 MHz  CPU2 freq      : 1800 MHz  CPU3 freq      : 1800 MHz  CPU4 freq      : 1800 MHz  CPU count      : 4   Governor       : performance   SOC Temp       : 55 C  Next time i get results from 3.10...
  12. Like
    @lex got a reaction from tkaiser in Trying to compile Pine H64   
    I am running @Icenowy kernel, 1.5 GHz, 3.10.65 with some minor modification and 4.4.y 4.9.y without ethernet and axp805/6 not recognized .
    I will run  tinymembench possibly tomoorow (lack of time)...
  13. Like
    @lex got a reaction from Werner in OrangePi One Plus network questions   
    FYI, Orange Pi One Plus ethernet Gbit is already working on mainline kernel.
    Thanks to Jagan Teki and Icenowy for their work!
     ./iperf3 -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 [  4] local 192.168.254.253 port 32808 connected to 192.168.254.100 port 5201 [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd [  4]   0.00-1.00   sec   112 MBytes   942 Mbits/sec    0    112 KBytes        [  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   6.00-7.00   sec   112 MBytes   942 Mbits/sec    0    202 KBytes        [  4]   7.00-8.00   sec   112 MBytes   942 Mbits/sec    0    202 KBytes        [  4]   8.00-9.00   sec   112 MBytes   941 Mbits/sec    0    202 KBytes        [  4]   9.00-10.00  sec   112 MBytes   942 Mbits/sec    0    202 KBytes        - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bandwidth       Retr [  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec    0             sender [  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver iperf Done. ./iperf3 -R -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 Reverse mode, remote host 192.168.254.100 is sending [  4] local 192.168.254.253 port 32816 connected to 192.168.254.100 port 5201 [ ID] Interval           Transfer     Bandwidth [  4]   0.00-1.00   sec   107 MBytes   895 Mbits/sec                   [  4]   1.00-2.00   sec   107 MBytes   896 Mbits/sec                   [  4]   2.00-3.00   sec   106 MBytes   892 Mbits/sec                   [  4]   3.00-4.00   sec   106 MBytes   890 Mbits/sec                   [  4]   4.00-5.00   sec   106 MBytes   893 Mbits/sec                   [  4]   5.00-6.00   sec   107 MBytes   894 Mbits/sec                   [  4]   6.00-7.00   sec   106 MBytes   889 Mbits/sec                   [  4]   7.00-8.00   sec   107 MBytes   894 Mbits/sec                   [  4]   8.00-9.00   sec   106 MBytes   891 Mbits/sec                   [  4]   9.00-10.00  sec   106 MBytes   892 Mbits/sec                   - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bandwidth       Retr [  4]   0.00-10.00  sec  1.04 GBytes   893 Mbits/sec  4257             sender [  4]   0.00-10.00  sec  1.04 GBytes   893 Mbits/sec                  receiver iperf Done.  
  14. Like
    @lex got a reaction from Igor in OV5640 on mainline kernel   
    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!
     
     
     


  15. Like
    @lex got a reaction from Moklev in New Mali blobs (Allwinner, mainline)   
    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?
  16. Like
    @lex got a reaction from Igor in OV5640 on mainline kernel   
    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!
     
     
     


  17. Like
    @lex got a reaction from Igor in OV5640 on mainline kernel   
    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!
     
     
     


  18. Like
    @lex got a reaction from manuti in 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... 
     
  19. Like
    @lex got a reaction from raschid in regulatory.db - wifi not working with DEV-kernel   
    I have spent a lot of time on this and latest package should fix that, hopefully:
     
    https://patchwork.kernel.org/patch/10128825/
     
  20. Like
    @lex reacted to LeopoldVonBuschLight in BPi R16   
    I'm not sure about the specs for the battery, I just used a 4400mAh lipo I found on ebay or aliexpress a while back. I didn't configure anything on the m2m for this specific battery, so it might blow up eventually...
     
    I bought some 6 pin 1.25mm JST connectors that were mentioned here: http://forum.banana-pi.org/t/battery-cable-circuit/3737 (even though this is for a different board). 
     
    This is from the m2magic schematic located here: https://bananapi.gitbooks.io/banana-pi-bpi-m2-magic-iot-development-board/content/chapter1/bpi-m2-magic-schematic-diagram.html

     
     
     
    Here are the pins on the board:

     
    The battery I'm using at the moment only has two wires (no temp sensor). I put pins 1-3 to bat +, pins 4 and 5 to bat - and a 10k resistor between pin 6 and gnd. It looks like that was wrong though, and pin 6 should go straight to gnd with no resistor?
     
    Here is one of the 6 pin 1.25mm JST connectors:

     
    Sorry for the bad pictures! 
  21. Like
    @lex reacted to LeopoldVonBuschLight in BPi R16   
    Oh and here is a connector that should work: https://www.ebay.com/i/162705482126?chn=ps&dispItem=1
     
  22. Like
    @lex got a reaction from MickMake in The mmBoard   
    ... better ask on another thread...
  23. Like
    @lex got a reaction from chwe in GC2035 camera driver is unavailable at sunxi-next 4.13.6 kernel ?   
    There is no CSI available for Kernel 4.x 4.1x  yet, it is a WiP.
     
  24. Like
    @lex got a reaction from guidol in kernel 4.14.0 on H2+   
    Fixed. NanoPi DUO with kernel 4.14.0, fast, solid as rock.
    That's it. Job accomplished.
     
     
    ethernet:
     
  25. Like
    @lex got a reaction from guidol in kernel 4.14.0 on H2+   
    Fixed. NanoPi DUO with kernel 4.14.0, fast, solid as rock.
    That's it. Job accomplished.
     
     
    ethernet: