Pat Posted July 20, 2018 Posted July 20, 2018 @5kft, yes let me know when you have an image to download and tell me all the instructions to check that all is ok. 1
5kft Posted July 21, 2018 Posted July 21, 2018 @Pat, @guidol - I have made a full NEO2 device image including my changes that you can flash to a spare micro-SD card. You can download it from here: https://drive.google.com/file/d/1bnTWFEm198E8VgA_4htuDmjnI1BqknLS/view?usp=sharing (this is a 7z archive of "Armbian_5.53.180722_Nanopineo2_Debian_stretch_next_4.17.8.img"). After you download the archive, extract the image file and write it to a (spare) SD card. I've been using Etcher to do this. To test it, simply insert the card and power up the board. On a v1.0 board, if you have a serial console attached, you should see "NanoPi NEO2 v1.0 detected" during the u-boot startup sequence. Here's the startup sequence on my v1.1 board (notice the "NanoPi NEO2 v1.1 detected" string): ... U-Boot 2018.05-armbian (Jul 21 2018 - 07:20:45 -0700) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.1 detected Net: No ethernet found. 230454 bytes read in 29 ms (7.6 MiB/s) starting USB... ... (Again, if this is all working, for your v1.0 board it should display "v1.0" instead of "v1.1".) Now, if you don't have the serial console, or don't want to bother with it, that's okay - you can check if it worked by checking the LED system class after you log in. Log in using the normal Armbian "initial boot" username/password of "root" and "1234". Once you get to the command prompt, change to "/sys/class/leds", and you should see the NEO2 v1.0 entries for "nanopi:blue:status" and "nanopi:green:pwr". For my v1.1 board, the v1.1 DT is loaded, and the proper red/green LEDs are available: root@nanopineo2:~# root@nanopineo2:~# ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jul 21 14:48 . drwxr-xr-x 54 root root 0 Jul 21 14:48 .. lrwxrwxrwx 1 root root 0 Jul 21 14:48 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jul 21 14:48 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr root@nanopineo2:~# When developing the u-boot changes, I tested this using a physical GPIO pin on the header. Now I just want to make sure that I'm reading the correct internal GPIO (PL3) for the NEO2 boards. If you would like to see my source changes for this, they are available here: https://github.com/5kft/build/commit/a94ef373354ca0d50ba2054a00af8ec6c8b30b1d. (It's pretty straightforward, and would be happy to hear thoughts/comments if you have any regarding this.) Thanks again for all of your help with this!
guidol Posted July 21, 2018 Posted July 21, 2018 maybe @Pat is this time faster, because my 2 Neo2 v1.0 are installed inside the silver NAS case.... I have to open the case and install MicroSD and serial converter...and every time I unscrew the case it wouldn't get better 1
Pat Posted July 22, 2018 Posted July 22, 2018 @guidol Yes I should be able to test the image either today or tomorrow. @5kftThank you for your work and the clear test procedure (I've no serial console). My feedback as soon as possible.
5kft Posted July 22, 2018 Posted July 22, 2018 1 hour ago, Pat said: @guidol Yes I should be able to test the image either today or tomorrow. @5kftThank you for your work and the clear test procedure (I've no serial console). My feedback as soon as possible. Thank you! There's no rush of course, only when absolutely convenient for you. Many thanks again
Pat Posted July 23, 2018 Posted July 23, 2018 @5kft Hello, So here are the results on my NanoPI Neo2 v1.0 (thus not LTS): root@nanopineo2:~# cd /sys/class/leds root@nanopineo2:/sys/class/leds# ls -l total 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr root@nanopineo2:/sys/class/leds# uname -a Linux nanopineo2 4.17.8-sunxi64 #13 SMP Sat Jul 21 07:21:19 PDT 2018 aarch64 GNU/Linux root@nanopineo2:/sys/class/leds# If I'm not wrong all seems ok, so congrats to you NanoPI Neo 2 v1.0 is on the good way to have a fix as the v1.1 for the CPU Frequency issue
5kft Posted July 23, 2018 Posted July 23, 2018 58 minutes ago, Pat said: @5kft Hello, If I'm not wrong all seems ok, so congrats to you NanoPI Neo 2 v1.0 is on the good way to have a fix as the v1.1 for the CPU Frequency issue Ah, unfortunately it looks like it did not work ... v1.0 should show blue and green LED entries. Could you do me a huge favor and try the command-line steps here: https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?do=findComment&comment=58363 and let me know your results? This GPIO (PL3) should return a "1" for a v1.0 board, but it looks like it's returning a "0" for your board. If these command-line steps work on your board, then I've got a problem in the GPIO check. (I manually tested this code using GPIO PG6.) Thank you!!
Pat Posted July 23, 2018 Posted July 23, 2018 I did it and the result is 1 whet I do the last cat command.
Pat Posted July 23, 2018 Posted July 23, 2018 Is there anyway to pick up the U-boot startup sequence when we have no console ?
5kft Posted July 23, 2018 Posted July 23, 2018 26 minutes ago, Pat said: I did it and the result is 1 whet I do the last cat command. OK, this is good news then. My guess is that this is an issue with the GPIO read for that line. I'll need to dig into this more - will need a day or so. Again I really appreciate your help in testing this!
5kft Posted July 23, 2018 Posted July 23, 2018 22 minutes ago, Pat said: Is there anyway to pick up the U-boot startup sequence when we have no console ? Unfortunately not - it's purely console output at boot time (from u-boot). It'd be super handy for debug messages, but this logic is simple enough that it shouldn't be necessary. I'll do some more digging regarding this and will keep you posted!
Pat Posted July 23, 2018 Posted July 23, 2018 Just a though. I bought this board in March just before the LTS release. I checked again my order sent by friendlyarm and it is not mentioned at all any reference to v1.1 or LTS. But wouldn't be a risk to have a 1.1 version with your software running perfectly while I believe it is a 1.0 ? Is there something more I could do to confirm it is a really a 1.0?
guidol Posted July 23, 2018 Posted July 23, 2018 29 minutes ago, Pat said: But wouldn't be a risk to have a 1.1 version with your software running perfectly while I believe it is a 1.0 ? Is there something more I could do to confirm it is a really a 1.0? You could check for v1.0/v1.1 via the follwing URL with differnt Photos and connectors at http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2#Hardware_Change_List and the version is printed near the CPU
Pat Posted July 23, 2018 Posted July 23, 2018 4 minutes ago, guidol said: You could check for v1.0/v1.1 via the follwing URL with differnt Photos and connectors at http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2#Hardware_Change_List and the version is printed near the CPU Ok thanks. My board is definitively a v1.0. Sorry for the confusion.
5kft Posted July 23, 2018 Posted July 23, 2018 1 hour ago, Pat said: Ok thanks. My board is definitively a v1.0. Sorry for the confusion. Thanks for verifying! I have come up with an idea to develop/debug this...I'll keep you posted!
guidol Posted July 24, 2018 Posted July 24, 2018 On 7/21/2018 at 6:30 PM, 5kft said: To test it, simply insert the card and power up the board. On a v1.0 board, if you have a serial console attached, you should see "NanoPi NEO2 v1.0 detected" during the u-boot startup sequence. Here's the startup sequence on my v1.1 board (notice the "NanoPi NEO2 v1.1 detected" string): (Again, if this is all working, for your v1.0 board it should display "v1.0" instead of "v1.1".) @5kft: like @Pat my 2 Neo2 v1.0 are identified at u-boot as Neo2 v1.1 So I also see the wrong led-color-names I did test it with my 2 Neo2 v1.0 and also get them out of the case to see they are real v1.0 (non-popup-sdslot, the v1.0 Ethernet-port, unsoldered audio): IP22 Neo2: ========================================================================== U-Boot 2018.05-armbian (Jul 21 2018 - 07:20:45 -0700) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.1 detected Net: No ethernet found. 230454 bytes read in 24 ms (9.2 MiB/s) starting USB... root@nanopineo2:~# ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jul 21 14:26 . drwxr-xr-x 53 root root 0 Jan 1 1970 .. lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr IP23 Neo2: ========================================================================== U-Boot 2018.05-armbian (Jul 21 2018 - 07:20:45 -0700) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.1 detected Net: No ethernet found. 230454 bytes read in 25 ms (8.8 MiB/s) starting USB... root@nanopineo2:~# ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jul 21 14:28 . drwxr-xr-x 53 root root 0 Jan 1 1970 .. lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr 1
5kft Posted July 24, 2018 Posted July 24, 2018 5 hours ago, guidol said: @5kft: like @Pat my 2 Neo2 v1.0 are identified at u-boot as Neo2 v1.1 So I also see the wrong led-color-names I did test it with my 2 Neo2 v1.0 and also get them out of the case to see they are real v1.0 (non-popup-sdslot, the v1.0 Ethernet-port, unsoldered audio): Hi @guidol, @Pat - thanks again for the testing! I dug into this and as-is in the current u-boot the driver code for the second GPIO bank doesn't appear to be working, so I can't properly read the "board ID" GPIO line. Unfortunately as I am completely unfamiliar with this implementation in u-boot I need to debug this and figure out what is going on. The good news is that I found another exposed GPIO line in that same bank that I can use to debug and test, so I won't bother you with trying this until I have the new implementation (It may be a few days for me to find enough time to work on this, however...but I will keep you posted!) 1
5kft Posted July 25, 2018 Posted July 25, 2018 (edited) I did some debugging, and the problem is that for some reason it appears that it is not possible as-is to properly configure the GPIOs in the second PIO interface in the H5 within u-boot - i.e., all PL_CFG0_REG (0x1f02c00) changes are being "ignored" by the H5. The first PIO interface, PA_CFG0_REG (0x1c20800), can be configured just fine both from within u-boot console and in code, however - but PL_CFG0_REG doesn't work. What follows is an example of this using just the u-boot console. I boot an H5 board (in this case I'm using a NEO Core2), and stop in the bootloader by hitting spacebar during the boot, then I try manipulating PL_CFG0_REG directly. First, by dumping this register block, you can see that the GPIOs are disabled (GPIO configuration values are all "7"). If I try enabling them as input lines (by writing zeros into the register), the write is ignored. This effect is happening within my test code in the bootloader as well: ... 230454 bytes read in 25 ms (8.8 MiB/s) starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop => => => md.l 1f02c00 2 01f02c00: 77777777 00007777 wwwwww.. => mm.l 1f02c00 01f02c00: 77777777 ? 00000000 01f02c04: 00007777 ? 00000000 01f02c08: 00000000 ? . => md.l 1f02c00 2 01f02c00: 77777777 00007777 wwwwww.. => As you can see the zero writes are ignored. Again it's the same thing in my code as well - writing to PL_CFG0_REG (at 0x1f02c00) has no effect, and the GPIO configurations stay at "disabled". This is why the NEO2 board check isn't working - the u-boot "GPIO direction set" functions are being ignored by the H5 for this second GPIO interface. As such I can't configure GPIO PL3 as an input. Unfortunately I am not an expert regarding u-boot nor the H5 at all... Is there perhaps some memory map configuration that needs to be changed? No exception is thrown when I write to that address, it's just that the writes appear to have no effect. From what I can tell the power supply for this GPIO bank is always enabled in H/W. I looked in the ATF code, but I don't see anything obvious there that might cause this register to not "accept" configuration requests (?). I also did some comparisons to the FriendlyELEC bootloader but didn't see anything obvious there either. Any help or thoughts/ideas would be really appreciated... @tkaiser might you know of someone who might be able to provide some advice or insight regarding this? EDIT: I tested manipulation of PL_CFG0 in FriendlyELEC's u-boot (https://github.com/friendlyarm/u-boot.git, branch "sunxi-v2017.x"), and it works fine. However this does not work in the current v2018.05 Armbian u-boot, nor the prior v2017.11 Armbian u-boot. So something is definitely broken (and more debugging is needed)... EDIT2: In order to enable access to the R_PIO GPIOs (e.g., PL_xxx) in u-boot, it is necessary to enable PIO in the APB0 PRCM register, and enable the PIO_GATING bit in BUS_CLK_GATING_REG2. Edited July 29, 2018 by 5kft
5kft Posted July 29, 2018 Posted July 29, 2018 @Pat, @guidol - I spent some time in u-boot and figured out how to enable access to the GPIO bank that contains GPIO PL3 (the "board version" GPIO for the NEO2). After enabling this, I can properly read the board version GPIO in my code. I tested these changes extensively on my NEO2 against both GPIOs PL3 and PL4 (PL4 is conveniently hard-wired high on the board). What this means is that my v1.0/v1.1 version check for the NEO2 should now work correctly on your 1.0 boards. @Pat, would you be able to test this new version on your v1.0 board? I have posted a new full image build here: Armbian_5.54.180730_Nanopineo2_Debian_stretch_next_4.17.11.7z. As before, after you download the archive, extract the image file and write it to a (spare) SD card, then insert the card and power up the board. (The instructions for testing this are the same as before - https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?do=findComment&comment=58502.) If a serial console attached, you should see "NanoPi NEO2 v1.0 detected" as u-boot boots on a v1.0 board. @Pat, as you don't have a serial console, after the device finishes booting you should check the contents of the "/sys/class/leds/" directory. If "green" and "blue" entries are there, then it worked! I really appreciate your giving this a try - thank you very much!!
guidol Posted July 29, 2018 Posted July 29, 2018 10 hours ago, 5kft said: would you be able to test this new version on your v1.0 board? I really appreciate your giving this a try - thank you very much!! @5kft it did work! - U-Boot 2018.05-armbian (Jul 29 2018 - 01:32:58 +0000) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.0 detected Net: No ethernet found. 230454 bytes read in 25 ms (8.8 MiB/s) starting USB... No controllers found Autoboot in 1 seconds, press <Space> to stop Welcome to ARMBIAN 5.54.180730 nightly Debian GNU/Linux 9 (stretch) 4.17.11-sunxi64 root@nanopineo2:~# ls -l /sys/class/leds total 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:blue:status -> ../../devices/platform/leds/leds/nanopi:blue:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:pwr -> ../../devices/platform/leds/leds/nanopi:green:pwr 1
5kft Posted July 29, 2018 Posted July 29, 2018 27 minutes ago, guidol said: @5kft it did work! - Excellent!!! @guidol, thank you so very much for your time and effort in testing this, I truly appreciate it!!! 1
reverend_t Posted July 29, 2018 Posted July 29, 2018 Thanks so much 5kft! Can I find your source/patches anywhere online?
5kft Posted July 29, 2018 Posted July 29, 2018 36 minutes ago, reverend_t said: Thanks so much 5kft! Can I find your source/patches anywhere online? Hi @reverend_t, it's not quite done yet; but it's almost there At this point I am still cleaning a few things up and am starting to submit PRs for this (e.g., PR #1064 and PR #1065 to start). I'll keep you posted! 1
Pat Posted July 29, 2018 Posted July 29, 2018 @5kft Hi, seems the genius in you found the right way ? root@192.168.0.39's password: _ _ ____ _ _ _ ____ | \ | | __ _ _ __ ___ | _ \(_) | \ | | ___ ___ |___ \ | \| |/ _` | '_ \ / _ \| |_) | | | \| |/ _ \/ _ \ __) | | |\ | (_| | | | | (_) | __/| | | |\ | __/ (_) | / __/ |_| \_|\__,_|_| |_|\___/|_| |_| |_| \_|\___|\___/ |_____| Welcome to ARMBIAN 5.54.180730 nightly Debian GNU/Linux 9 (stretch) 4.17.11-sunxi64 System load: 0.00 0.04 0.02 Up time: 4 min Memory usage: 11 % of 481MB IP: 192.168.x.xx CPU temp: 33°C Usage of /: 7% of 15G [ General system configuration (beta): armbian-config ] Last login: Sun Jul 29 16:57:57 2018 from 192.168.x.xx root@nanopineo2:~# ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jul 29 16:59 . drwxr-xr-x 53 root root 0 Jan 1 1970 .. lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:blue:status -> ../../devices/platform/leds/leds/nanopi:blue:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:pwr -> ../../devices/platform/leds/leds/nanopi:green:pwr 2
5kft Posted July 29, 2018 Posted July 29, 2018 5 minutes ago, Pat said: @5kft Hi, seems the genius in you found the right way ? Perfect!! Thanks so much for testing this, it is really appreciated!
5kft Posted July 29, 2018 Posted July 29, 2018 2 hours ago, 5kft said: ... it's not quite done yet; but it's almost there At this point I am still cleaning a few things up and am starting to submit PRs for this (e.g., PR #1064 and PR #1065 to start). I'll keep you posted! @reverend_t - I've submitted three PRs that comprise the changes necessary for this support - PR #1064, PR #1065, and PR #1066. Until they are accepted, you can cherry-pick these changes into your own build to give it a try, or if it is helpful, I've also made a temporary branch in my github that consolidates these changes: https://github.com/5kft/build/commits/consolidated-dt-test. With these changes running on NEO2 v1.1 board, you can load the optional "sun50i-h5-cpu-clock-1.3GHz.dtbo" overlay and run your NEO2 v1.1 at 1.3GHz - see my previous instructions:
5kft Posted February 9, 2019 Posted February 9, 2019 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). 1
dolphs Posted February 9, 2019 Posted February 9, 2019 thanks a lot, it is highly appreciated: new values ( overclocked ) show: <snip snip> current policy: frequency should be within 408 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.30 GHz (asserted by call to hardware). cpufreq stats: 120 MHz:0.38%, 240 MHz:0.19%, 480 MHz:59.06%, 648 MHz:0.41%, 816 MHz:0.06%, 960 MHz:0.05%, 1.01 GHz:0.07%, 1.06 GHz:0.05%, 1.10 GHz:0.07%, 1.15 GHz:0.24%, 1.20 GHz:0.04%, 1.22 GHz:0.03%, 1.25 GHz:0.01%, 1.30 GHz:39.35% (128) first board results :~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 15572277 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 12847235 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6787237 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 1024 size blocks: 2456283 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 353175 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 178446 aes-128-cbc's in 3.00s OpenSSL 1.1.1-pre9 (beta) 21 Aug 2018 built on: Tue Aug 21 19:00:17 2018 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-Z0GDqL/openssl-1.1.1~~pre9=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 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 83052.14k 274074.35k 581114.61k 838411.26k 964403.20k 974553.09k 2nd board ( of course similar results ): :~# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 16151752 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 13172479 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6906353 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2458131 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 353291 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 86430.78k 281012.89k 589342.12k 839042.05k 964719.96k 974727.85k
sfx2000 Posted February 11, 2019 Posted February 11, 2019 On 7/29/2018 at 12:06 PM, 5kft said: I've submitted three PRs that comprise the changes necessary for this support - PR #1064, PR #1065, and PR #1066. Until they are accepted, you can cherry-pick these changes into your own build to give it a try, or if it is helpful, I've also made a temporary branch in my github that consolidates these changes: https://github.com/5kft/build/commits/consolidated-dt-test. With these changes running on NEO2 v1.1 board, you can load the optional "sun50i-h5-cpu-clock-1.3GHz.dtbo" overlay and run your NEO2 v1.1 at 1.3GHz - see my previous instructions: Current Armbian - it does look like there's a fair amount of cleanup needed on device tree in general... whether it's a 1.0 or a 1.1 board... Just a quick look... haven't had to dive deeper in the h*ll that can be device tree... dtc -I dtb -O dts -f sun50i-h5-nanopi-neo2-v1.1.dtb -o sun50i-h5-nanopi-neo2-v1.1.dts sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@120000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@240000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@480000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@648000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@816000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@960000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1008000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1056000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1104000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1152000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1200000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1224000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1248000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1296000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1344000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1368000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (simple_bus_reg): Node /soc/eeprom@01c14000 simple-bus unit address format error, expected "1c14000" sun50i-h5-nanopi-neo2-v1.1.dts: Warning (simple_bus_reg): Node /soc/sound missing or empty reg/ranges property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (simple_bus_reg): Node /soc/gpu@1280000 simple-bus unit address format error, expected "1e80000" sun50i-h5-nanopi-neo2-v1.1.dts: Warning (thermal_sensors_property): thermal-sensors property size (4) too small for cell size 1 in /thermal-zones/cpu-thermal Similar errors show up with a v1.0 dtb... Which is reflected here... collected on a 1.1 board... [ 5.116035] cpu cpu0: Linked as a consumer to regulator.5 [ 5.116089] cpu cpu0: Dropping the link to regulator.5 [ 5.116246] cpu cpu0: Linked as a consumer to regulator.5 [ 5.116865] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.116874] cpu cpu0: _opp_add: OPP not supported by regulators (1056000000) [ 5.116980] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.116986] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 5.117056] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.117062] cpu cpu0: _opp_add: OPP not supported by regulators (1152000000) [ 5.117159] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.117166] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 5.117234] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.117240] cpu cpu0: _opp_add: OPP not supported by regulators (1224000000) [ 5.117346] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.117352] cpu cpu0: _opp_add: OPP not supported by regulators (1248000000) [ 5.117420] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.117426] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 5.117525] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.117531] cpu cpu0: _opp_add: OPP not supported by regulators (1344000000) [ 5.117602] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.117608] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000) [ 5.139444] thermal thermal_zone1: binding zone cpu-thermal with cdev thermal-cpufreq-0 failed:-22 [ 5.192579] thermal thermal_zone0: failed to read out thermal zone (-110) [ 5.192639] OF: /thermal-zones/cpu-thermal: arguments longer than property [ 5.192654] thermal thermal_zone2: failed to read out thermal zone (-110) @5kft - might be an opportunity to do some basic cleanup there. Diffs between 1.0 and 1.1 follow... it doesn't seem to be much. diff sun50i-h5-nanopi-neo2.dts sun50i-h5-nanopi-neo2-v1.1.dts 1252c1252 < label = "nanopi:green:pwr"; --- > label = "nanopi:red:pwr"; 1258c1258 < label = "nanopi:blue:status"; --- > label = "nanopi:green:status"; 1291c1291 < regulator-max-microvolt = <0x10c8e0>; --- > regulator-max-microvolt = <0x13d620>; 1295c1295 < states = <0x10c8e0 0x0 0x10c8e0 0x1>; --- > states = <0x10c8e0 0x0 0x13d620 0x1>; Anyways - looks like Device Tree in general with Armbian needs some work on the NanoPi Neo2 period...
Recommended Posts