5kft

Members
  • Content Count

    120
  • Joined

  • Last visited

About 5kft

  • Rank
    Elite member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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. 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.
  3. 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!
  4. 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)
  5. 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:
  6. 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).
  7. 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!
  8. 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.
  9. @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?
  10. 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.
  11. 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?
  12. 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!
  13. 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...!
  14. 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.
  15. 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).