5kft

Members
  • Content Count

    120
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by 5kft

  1. 5kft

    NanoPi Neo2 Armbian set max freq

    Unfortunately the core voltage of the NEO2 v1.0 is limited to 1.1v. As defined by the DT used by Armbian, the maximum CPU frequency for the H3/H5 at 1.1v is 816MHz - this is why you're not able to increase it further via cpufreq. (If you upgrade to a v1.1 board it's possible to take it all the way to 1.3GHz )
  2. I recently purchased a number of Orange Pi and Nano Pi boards, and discovered the awesome work of the Armbian team :-) The Orange Pi Plus2 H5 is a rather nice board - built in eMMC, H5, etc. (I wish it had 1GB of RAM but that's a different subject.) I'd love to use these boards for a number of projects. As a test, I modified the DTS for the board (mainline kernel) to enable support for the 1.1v/1.3v switch for VDD-CPUX using the SY8113B on the board. I also enabled the allowed clock changes to 1.2GHz for cpufreq. All of this worked great, but the board was very unstable at anything over 1GHz, which seemed strange, given that the CPU voltage should be switching to 1.3v. I found that when measuring the voltage of the "1V2C" testpoint on the board that VDD-CPUX was always at 1.1v - it never switched to 1.3v. I did some further examination of the board, and I was surprised to find that the "Q5" BSN20 MOSFET was not populated on the board! I checked all of the other passives and they are present - it is like Xunlong simply decided not to stuff this part when they built the board. So, as a test, I desoldered this part from my Orange Pi Zero rev 1.4 board and soldered it in the missing "Q5" spot on my Orange Pi Zero Plus2 board. And now it works great! VDD-CPUX properly switches between 1.1v/1.3v (measured at the "1V2C" TP), and I can clock the board to 1.296GHz without any problems. Would anyone have an idea why Xunlong doesn't solder this part on the board by default? They include all the other parts in this part of the power circuit, just not this MOSFET. I was going to buy a few more of these boards, and I'd like to be able to clock them up. Perhaps I should just order a set of these BSN20 MOSFETs and solder them on myself when I receive the boards...? Or perhaps I should just forget Xunlong/Orange Pi and use Nano Pis? My Nano Pi Neo Plus2 has been working perfectly since I powered it up (I enabled clocking to 1.296GHz by default as well in the DTS). By the way, I did some extensive tests and it looks like with both of these boards DVFS and thermal throttling works fine - the clock throttles back properly at the different temperature thresholds. Thank you!
  3. Thanks @km1kze However I would like to thank the Armbian team for their awesome work in providing a great platform for supporting all of these boards...it is simply amazing! BTW, I just looked and now I recall why I didn't create a 1.4v/1.4GHz overlay - it's essentially included by default in the mainline now. The default maximum clockspeed for 1.4v-capable boards (out of the box) is 1.368GHz. My Core2 boards clock just fine to 1.400GHz at 1.4v, but I figured that it isn't worth introducing another overlay for such a small difference.
  4. Hi @km1kze, yes - that's correct. I made the overlay change as with the newer kernel and board support there are a number of boards that provide implicit support for 1.3v regulators, and as such this overlay explicitly should be used with 1.3v regulators. Similarly, I could make a 1.4v overclock overlay (e.g., for the NEO Core2) that would support 1.4GHz - I just haven't gotten around to doing this yet. In any case, I'm glad to hear that this is working for you now!
  5. 5kft

    Nanopi NEO2 CPU frequency issue

    Not surprising at all, and not just for the NEO2...! Please feel free to contribute (https://www.armbian.com/get-involved/#submit)
  6. 5kft

    NanoPi NEO4

    Hi @dolphs, you are very welcome! Good news, your boards should work great at 1.3GHz. When we moved to the new kernel and updated the DTs I added the appropriate regulator entry for the NEO2 v1.1 board by default, and was able to simplify the instructions for the NEO2 v1.1 board. I just posted updated instructions; please give these a try:
  7. 5kft

    Nanopi NEO2 CPU frequency issue

    Per request, here are updated instructions for overclocking the NEO2 v1.1 LTS board to 1.3GHz, for the latest builds of Armbian (kernel 4.19+, build 5.70+): 1. Please note that this will not work on a NEO2 v1.0 board - the first version of the board doesn't include a regulator nor circuit that supports voltage switching. Only follow these instructions if you are using a v1.1 board! 2. Edit /boot/armbianEnv.txt, and add these lines: overlay_prefix=sun50i-h5 overlays=cpu-clock-1.3GHz-1.3v If you have other overlays specified in your /boot/armbianEnv.txt, simply append these two new ones following them, for example: overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost1 usbhost2 cpu-clock-1.3GHz-1.3v 3. Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000, e.g.: # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1300000 GOVERNOR=ondemand 4. Configure APT so that /etc/default/cpufrequtils will not be reverted to the system default when the package is upgraded (e.g., via "apt upgrade"): dpkg-divert --add /etc/default/cpufrequtils 5. Reboot the board. That should be it! Following reboot, you can verify proper operation at the higher CPU clock speeds using "cpufreq-info" (for example).
  8. 5kft

    NanoPi NEO4

    Hi @dolphs, here are results from some of the tests that you requested, running on my NEO4 (full image build from ToT): root@nanopineo4:~# cat /proc/version Linux version 4.20.0-rk3399 (root@elrond) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.75.190210 SMP Sat Feb 9 01:24:09 UTC 2019 root@nanopineo4:~# root@nanopineo4:~# grep -m1 -o aes /proc/cpuinfo aes root@nanopineo4:~# root@nanopineo4:~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 20486565 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 14675445 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 7906405 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2861360 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 411854 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 208079 aes-128-cbc's in 3.00s OpenSSL 1.1.0j 20 Nov 2018 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-128-cbc 109261.68k 313076.16k 674679.89k 976677.55k 1124635.99k 1136388.78k root@nanopineo4:~# root@nanopineo4:~# echo 0 >/sys/devices/system/cpu/cpu0/online root@nanopineo4:~# echo 0 >/sys/devices/system/cpu/cpu1/online root@nanopineo4:~# echo 0 >/sys/devices/system/cpu/cpu2/online root@nanopineo4:~# echo 0 >/sys/devices/system/cpu/cpu3/online root@nanopineo4:~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 67833990 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 41104921 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 15078940 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 4187372 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 552193 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 276850 aes-128-cbc's in 3.00s OpenSSL 1.1.0j 20 Nov 2018 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-128-cbc 361781.28k 876904.98k 1286736.21k 1429289.64k 1507855.02k 1511970.13k root@nanopineo4:~# root@nanopineo4:~# cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 maximum transition latency: 40.0 us. hardware limits: 408 MHz - 1.51 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 600 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz. cpufreq stats: 408 MHz:0.39%, 600 MHz:62.20%, 816 MHz:0.13%, 1.01 GHz:0.15%, 1.20 GHz:0.09%, 1.42 GHz:0.04%, 1.51 GHz:37.01% (265) root@nanopineo4:~# cpufreq-info -c 4 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 4: driver: cpufreq-dt CPUs which run at the same hardware frequency: 4 5 CPUs which need to have their frequency coordinated by software: 4 5 maximum transition latency: 540 us. hardware limits: 408 MHz - 2.02 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 600 MHz and 2.02 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz (asserted by call to hardware). cpufreq stats: 408 MHz:0.40%, 600 MHz:79.51%, 816 MHz:0.72%, 1.01 GHz:0.32%, 1.20 GHz:0.02%, 1.42 GHz:0.03%, 1.61 GHz:0.04%, 1.80 GHz:0.02%, 2.02 GHz:18.94% (209) root@nanopineo4:~# For reference, here's the openssl run on one of my NEO2s (clocked at 1.3GHz max): root@nanopineo2:~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 16484521 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 13180969 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6907016 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2458428 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 353299 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 178478 aes-128-cbc's in 3.00s OpenSSL 1.1.0j 20 Nov 2018 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-128-cbc 87917.45k 281194.01k 589398.70k 839143.42k 964741.80k 974727.85k root@nanopineo2:~# root@nanopineo2:~# cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: 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: 5.44 ms. hardware limits: 120 MHz - 1.30 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 120 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 120 MHz (asserted by call to hardware). cpufreq stats: 120 MHz:85.04%, 240 MHz:1.79%, 480 MHz:0.27%, 648 MHz:0.00%, 816 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.10 GHz:0.00%, 1.15 GHz:0.00%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:12.90% (162205) root@nanopineo2:~# I hope this helps!
  9. It's definitely odd...I'm wondering if the eMMC part version is a red herring, unless there is a subtle configuration difference between the bootloaders for these boards? This would be worth checking. Both of my NEO Plus2s use the newer v5.1 GETF eMMC part and they work fine. Granted it's a completely different board than the OPi, but the major H/W parts are the same. It'll be interesting to try another OPi Plus2 with this part to see if the problem is reproducible.
  10. @martinayotte, for what it's worth, my NEO Plus2 running from the eMMC flash part KLM8G1GETF-B041 works great...: U-Boot SPL 2018.11-armbian (Jan 28 2019 - 12:38:34 +0100) DRAM: 1024 MiB Trying to boot from MMC2 NOTICE: BL31: v2.0(debug):bc15388 NOTICE: BL31: Built : 12:32:31, Jan 28 2019 NOTICE: BL31: Detected Allwinner H5 SoC (1718) NOTICE: BL31: Found U-Boot DTB at 0x40843b8, model: FriendlyARM NanoPi NEO Plus 2 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller NOTICE: BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design. INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot 2018.11-armbian (Jan 28 2019 - 12:38:34 +0100) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO Plus 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... MMC: no card present In: serial Out: serial Err: serial Net: No ethernet found. MMC: no card present MMC: no card present starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3042 bytes read in 5 ms (593.8 KiB/s) ## Executing script at 4fc00000 U-boot loaded from eMMC or secondary SD Boot script loaded from mmc 194 bytes read in 2 ms (94.7 KiB/s) MMC: no card present 28823 bytes read in 13 ms (2.1 MiB/s) 504 bytes read in 15 ms (32.2 KiB/s) Applying kernel provided DT overlay sun50i-h5-usbhost1.dtbo 504 bytes read in 15 ms (32.2 KiB/s) Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo 4155 bytes read in 12 ms (337.9 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 44000000 5329311 bytes read in 262 ms (19.4 MiB/s) 14245896 bytes read in 697 ms (19.5 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 5329247 Bytes = 5.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 EHCI failed to shut down host controller. Loading Ramdisk to 49aea000, end 49fff15f ... OK reserving fdt memory region: addr=4fa00000 size=6d000 Loading Device Tree to 0000000049a7a000, end 0000000049ae9fff ... OK Starting kernel ... Loading, please wait... starting version 232 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.29.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk2p1] fsck.ext4 -a -C0 /dev/mmcblk2p1 /dev/mmcblk2p1: clean, 37821/472352 files, 359379/1888624 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Debian GNU/Linux 9 (stretch)! [ OK ] Created slice User and Session Slice. [ OK ] Listening on fsck to fsckd communication Socket. [ OK ] Listening on Journal Socket. [ OK ] Started Dispatch Password Requests to Console Directory Watch. [ OK ] Listening on Journal Socket (/dev/log). [ OK ] Listening on udev Kernel Socket. [ OK ] Reached target Swap. [ OK ] Created slice System Slice. Starting Remount Root and Kernel File Systems... [ OK ] Listening on udev Control Socket. Mounting Debug File System... ... [ OK ] Reached target Network is Online. Starting LSB: Start NTP daemon... Starting /etc/rc.local Compatibility... Starting LSB: Advanced IEEE 802.11 management daemon... [ OK ] Started /etc/rc.local Compatibility. [ OK ] Started LSB: Advanced IEEE 802.11 management daemon. [ OK ] Started Serial Getty on ttyS0. [ OK ] Started Getty on tty1. [ OK ] Started LSB: Start NTP daemon. Debian GNU/Linux 9 nanopineoplus2 ttyS0 nanopineoplus2 login: root Password: Last login: Wed Jan 30 01:59:48 UTC 2019 on ttyS0 _ _ ____ _ _ _ ____ _ ____ | \ | | _ \(_) | \ | | ___ ___ | _ \| |_ _ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ | |_) | | | | / __| __) | | |\ | __/| | | |\ | __/ (_) | | __/| | |_| \__ \ / __/ |_| \_|_| |_| |_| \_|\___|\___/ |_| |_|\__,_|___/ |_____| Welcome to ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.17-sunxi64 System load: 0.48 0.13 0.04 Up time: 0 min Memory usage: 7 % of 993MB IP: 192.168.1.191 CPU temp: 51�‹C Usage of /: 18% of 7.1G root@nanopineoplus2:~# df -h Filesystem Size Used Avail Use% Mounted on udev 430M 0 430M 0% /dev tmpfs 100M 3.0M 97M 3% /run /dev/mmcblk2p1 7.1G 1.2G 5.5G 18% / tmpfs 497M 0 497M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 497M 0 497M 0% /sys/fs/cgroup tmpfs 497M 4.0K 497M 1% /tmp /dev/zram0 49M 1.4M 44M 3% /var/log tmpfs 100M 0 100M 0% /run/user/0 root@nanopineoplus2:~# root@nanopineoplus2:~# hdparm -tT /dev/mmcblk2 /dev/mmcblk2: Timing cached reads: 1004 MB in 2.00 seconds = 501.26 MB/sec Timing buffered disk reads: 132 MB in 3.01 seconds = 43.85 MB/sec root@nanopineoplus2:~# apt-get update Hit:1 http://security.debian.org stretch/updates InRelease Ign:2 http://cdn-fastly.deb.debian.org/debian stretch InRelease Hit:4 http://cdn-fastly.deb.debian.org/debian stretch-updates InRelease Hit:5 http://cdn-fastly.deb.debian.org/debian stretch-backports InRelease Hit:6 http://cdn-fastly.deb.debian.org/debian stretch Release Hit:3 https://apt.armbian.com stretch InRelease Reading package lists... Done root@nanopineoplus2:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@nanopineoplus2:~# Given this, I don't think it's an issue with the flash part version/type... Maybe there a different/subtle H/W change in the new Orange Pi Zero Plus2 H5?
  11. Yes, mine use WEPD, and my NEO Core2 boards all have WEPD. However, I have an new/not-yet-used NEO Plus2 that has a GETF part (same as @rmoriz). I'll try flashing it and see how it goes.
  12. Interesting...my Plus2 H5 boards all use Samsung KLM8G1WEPD-B031 parts (eMMC 5.0); @rmoriz's board uses a KLM8G1GETF-B041 (eMMC 5.1). I wonder if there might be an issue with eMMC 5.1 compatibility perhaps?
  13. Indeed...it's a very odd problem! There's actually a lot you can try to debug, but you'll have to figure some things out. You can start where I started last year: https://docs.armbian.com/Developer-Guide_Build-Preparation/. If you follow the build process (see the "How to start?" section) you'll end up with everything you need locally - all source, all patches, etc. will be present in the "build" tree. This is truly one of the awesome things about Armbian - give it a try, it's very cool!
  14. Sure, but it is rather difficult to solve a problem if you don't try to debug it Why not put a little more effort into this, it certainly is an interesting and strange problem...!
  15. Likewise - I have always used the eMMC exclusively on all of my Orange Pi Zero Plus2 H5 boards (I have multiple) and have never seen anything like this... (It's also always worked for my NEO Core 2 boards, NEO Plus 2 boards, etc.) In order to try narrowing the problem down, perhaps try @guidol's suggestion above (https://forum.armbian.com/topic/9440-orange-pi-zero-plus2-h5-install-to-emmc-bricked-device/?tab=comments#comment-71034). It could be that Armbian's partition layout is such that it exacerbates a H/W problem with your particular board? E.g., it'd be interesting to see if you still have problems if you layout the image to start at 1GB rather than at zero.
  16. Hi @dispo, nice catch! I just enabled the CPU activity LED trigger in the kernel (https://github.com/armbian/build/commit/fd3b83136b9baa62326feea28d14d44736b6f448). With this change you can set the LED trigger to "activity" and the LED will flash based upon instant CPU load (across all cores).
  17. Hi @dispo, what happens if you try something like this: sudo su - echo mmc0 >/sys/class/leds/nanopi\:green\:status/trigger # watch the green LED when running the next command hdparm -t /dev/mmcblk0 The LED should blink very quickly while the read test is performed. You could also try an "apt update" etc. that does disk activity, and the LED should flash quickly. While I haven't tried many of the other settings, I have used the "mmc0" one fairly often, and it has always worked for me.
  18. @rmoriz, for the sake of completeness: Did you previously run an earlier build of Armbian from the eMMC and was that okay? If not, I'm wondering if you might have an issue with the eMMC hardware...? You could try booting from SD, format the eMMC, mount it, then do a filesystem tests, perhaps? FWIW, I been using the eMMC exclusively on my Plus2 H5s and have never seen anything like what you are experiencing (another reason to suspect a hardware issue with the eMMC)... E.g., root@orangepizeroplus2:~# uptime 23:18:11 up 11 days, 22:47, 1 user, load average: 0.00, 0.00, 0.00 root@orangepizeroplus2:~# df -h Filesystem Size Used Avail Use% Mounted on udev 175M 0 175M 0% /dev tmpfs 49M 5.3M 43M 11% /run /dev/mmcblk2p2 7.2G 954M 6.0G 14% / tmpfs 241M 0 241M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 241M 0 241M 0% /sys/fs/cgroup /dev/mmcblk2p1 58M 29M 26M 54% /media/mmcboot /dev/zram5 234M 292K 217M 1% /tmp /dev/zram0 49M 3.0M 42M 7% /var/log tmpfs 49M 0 49M 0% /run/user/1000 root@orangepizeroplus2:~# cat /proc/version Linux version 4.19.13-sunxi64 (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.70 SMP Sat Jan 12 17:41:57 CET 2019 root@orangepizeroplus2:~# (I'm using btrfs as the main filesystem)
  19. Agreed - congratulations on an amazing effort! The scope of devices that Armbian supports and how well it all works is simply incredible
  20. Unfortunately I don't have a Zero Plus so I can't really speak to specifics regarding it, but if you are running the 4.19.y kernel then you shouldn't have to do anything in this regard - it should work properly by default...?
  21. Hi @sfx2000, the NEO2 v1.1 board provides a maximum core voltage of 1.3v, hence the default warnings about the higher operating points - they aren't supported.
  22. Hi @Igor, I just tested both I2C and SPI on the Plus2 H5 and both appear to work. Both tests were to devices connected to the pin header. The SPI test was using a 4MB SPI flash part, and the I2C test was just to detect an SH1106 OLED display connected to TWI0-SDA/SCK (display is configured at I2C address 0x3c): root@orangepizeroplus2:~/tmp# dd if=/dev/random of=test.dat bs=1024 count=4096 iflag=fullblock 4096+0 records in 4096+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 8.29973 s, 505 kB/s root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -w test.dat flashrom v0.9.9-r1954 on Linux 4.19.4-sunxi64 (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED. root@orangepizeroplus2:~/tmp# flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -r test2.dat flashrom v0.9.9-r1954 on Linux 4.19.4-sunxi64 (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi. Reading flash... done. root@orangepizeroplus2:~/tmp# md5sum test*.dat 979776e45a0b9fd7caf154f4f1bbbbf4 test2.dat 979776e45a0b9fd7caf154f4f1bbbbf4 test.dat root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# cat /boot/armbianEnv.txt verbosity=1 console=both overlay_prefix=sun50i-h5 overlays=usbhost2 usbhost3 spi-spidev i2c0 param_spidev_spi_bus=1 rootdev=UUID=2b29fd0a-3553-4999-be20-f3175d84e624 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@orangepizeroplus2:~/tmp# Very nice how well it all is working!
  23. This all looks good (mine is identical)... I tried a different monitor as well and that also works for me (1080p 24" LG). Does the 4.14 kernel work for you in the same exact H/W configuration?
  24. Interesting...both of mine boot and work fine with HDMI - bootloader logo, kernel boot, and HDMI console all work okay (tested using a wireless keyboard, which works as well): Did you try a different monitor and/or HDMI cable? What does "dmesg | grep -i hdmi" show for you?