• Content Count

  • 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. Hi @guidol, my guess is that you are seeing the crash at boot on your board because of the default hardware limitation in the Plus2. Using the default opp table you can run an Plus2 at higher clock rates than 816MHz only if you've added the missing MOSFET part (see thread at https://forum.armbian.com/topic/6866-orange-pi-zero-plus2-h5-hardware-oddity-in-vdd_cpux-power-circuit/). The default opp table is requiring 1.2v for operation at 960MHz+, and the regulator output for an unmodified OPi Plus2 is 1.1v. It might be possible to reliably push the H5 to 1008MHz at 1.1v, but the default table is more conservative (not sure why). FWIW I run all my boards at higher speeds, (including my NEO Core2s at 1.4GHz - see https://github.com/5kft/nanopi-misc/blob/master/nanopi-neo-core2-1.4GHz/nanopi-neo-core2-1.4GHz.dts).
  2. For what it's worth, I gave up on OPi.GPIO some time back, and switched to the standard libgpiod instead (e.g., see https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/). Use of libgpiod eliminates almost all pain in terms of permissions to manage GPIOs for non-root users. If you don't want to build your own copy, libgpiod is available in Debian buster; see package libgpiod2 (https://packages.debian.org/buster/libgpiod2). Python bindings are available via the python3-libgpiod package (see https://packages.debian.org/buster/python3-libgpiod). All that is needed for user access to GPIOs is to set the group of /dev/gpiochip* to a group that the user is a member of - e.g., I use a "gpio" group, and then "chgrp gpio /dev/gpiochip*"), and set the permissions of /dev/gpiochip* to group read/write (e.g., "chmod g+rw /dev/gpiochip*") so that the "gpio" group can read/write to it. After doing this the user has full access to the GPIOs (in C, in Python, at the command line, etc.) without having to run as root. Here's a simple Python example that illustrates controlling a LED that wired to H5 GPIO PA12: import gpiod PA12 = 12 # LED is wired to GPIO PA12 # configure GPIOs chip = gpiod.Chip('1', gpiod.Chip.OPEN_BY_NUMBER) led_line = chip.get_line(PA12) led_line.request(consumer="test", type=gpiod.LINE_REQ_DIR_OUT) led_line.set_value(1) # turn on LED led_line.set_value(0) # turn off LED libgpiod also comes with some handy utilities to track GPIO pin usage as well (e.g., "gpioinfo"). I hope this helps...!
  3. For the sake of completeness - I've been running 5.3.0-rc3 on one of my nanopineoplus2s for a few days now and it has been working great! Nice work!!
  4. OK, I'm glad you figured it out! I'd be happy to document this all somewhere consistent (right now the instructions are buried in various posts in these forums, done as it evolved), but I'm not sure where that somewhere should be...
  5. Hi @Igor, @guidol - in case it is helpful, I took a quick look at this and the fix is pretty straightforward. Essentially all that needs to be done is to remove the existing "patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch" for 5.1, and to port over the 4.19 "patch/kernel/sunxi-next/ths-29-add-correct-h5-thermal-zone.patch" to 5.1 (i.e., bring into "patch/kernel/sunxi-dev/"). The problem is the currently the thermal-zone is defined in the wrong DT location, and the zone definition and tips and cooling maps are incorrect/incomplete for the 5.1 version. I did a quick test of fixing it this way and the result works: root@nanopineo2:~# cat /proc/version Linux version 5.1.15-sunxi64 (root@elrond) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.90.190705 SMP Thu Jul 4 14:05:17 UTC 2019 root@nanopineo2:~# cat /sys/class/thermal/thermal_zone0/temp 40936 root@nanopineo2:~# I'd fix this and submit the change myself, but unfortunately I don't have time to be thorough about testing it right now (e.g., verify on some H3 boards and other H5 boards as well), and likely won't be able to until next week...I'm happy to do this then if you don't have time to look into this.
  6. The problem with AP6212 appears to be a regression caused by this commit: https://github.com/armbian/build/commit/52d82c921d02366f5fe7fa5e6a754227ce9e6913. I added a comment to the commit regarding this...
  7. Indeed, I actually committed it to Armbian last year, so it's already in the tree (.../patch/u-boot/u-boot-sunxi/enable-r_pio-gpio-access-h3-h5.patch) - see https://github.com/armbian/build/commit/c3f02be362aa216f2d3ee011916f9a18baf58291
  8. Indeed by default R_PIO-based GPIOs aren't accessible in u-boot. I made an Armbian patch last year to enable R_PIO access in the PRCM so that I could read the board revision GPIO PL3 on the NEO2 v1.1 (H5-based). You can take a look at the change here: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/enable-r_pio-gpio-access-h3-h5.patch. I would imagine that you should be able to add the "prcm_apb0_enable(PRCM_APB0_GATE_PIO)" call to your OpenWRT u-boot; after you do this the GPIO commands/function access for PL4 should work (hopefully!). What's awesome about all of this is how it is basically not documented anywhere
  9. Yes, indeed they are both very nice boards I really like their small size and their high quality!
  10. Hi @Frank F., interesting...I'm not sure why the Plus2 is still WIP, as IMHO it essentially is at the same level of functionality as the other FriendlyElec H5 boards (e.g., NEO2). I actually use both boards for several different purposes and they work really well. I use both GPIOs and SPI on the NEO2 and they work great (multiple LED control as well as interfacing to an nRF24l01-based wireless radio). I have tried a subset of the I/Os on the NEO Plus2 some time back (e.g., testing interfacing with SPI flash), but haven't used the I/Os on that board since. I don't know why it all wouldn't work the same on the Plus2 given that the base platforms are essentially the same. Wi-Fi works nicely on the Plus2 (I use the FE metal case with the included antenna). I haven't tried BT. The USB ports work fine on both. The eMMC on the Plus2 is fairly fast as well (I use btrfs to save space as it is only 8GB in size). They both overclock nicely to 1.3GHz. Here's a quick dump of some stuff from the Plus2: root@nano:~# cat /proc/version Linux version 4.19.20-sunxi64 (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 10:29:25 CET 2019 root@nano:~# uptime 14:20:35 up 49 days, 22:46, 2 users, load average: 0.04, 0.03, 0.00 root@nano:~# dpkg --list | grep plus2 ii linux-stretch-root-next-nanopineoplus2 5.73 arm64 Armbian tweaks for stretch on nanopineoplus2 (next branch) ii linux-u-boot-nanopineoplus2-next 5.75 arm64 Uboot loader 2018.11 root@nano:~# hdparm -tT /dev/mmcblk2 /dev/mmcblk2: Timing cached reads: 1078 MB in 2.00 seconds = 538.66 MB/sec Timing buffered disk reads: 132 MB in 3.04 seconds = 43.41 MB/sec root@nano:~# root@nano:~# sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 7.0618s total number of events: 10000 total time taken by event execution: 28.2335 per-request statistics: min: 2.79ms avg: 2.82ms max: 8.84ms approx. 95 percentile: 2.79ms Threads fairness: events (avg/stddev): 2500.0000/0.71 execution time (avg/stddev): 7.0584/0.00 root@nano:~# As to which one to get, a lot depends on your desired use... The NEO2 is really nice because of its tiny size; however there is no included eMMC, nor Wi-Fi, and it includes just one USB port. The Plus2 is a bit larger, but the two USB ports and gigE port are nice (I use one of the boards as a local router), as is the built-in Wi-Fi and eMMC (so no additional uSD card is needed). The metal case for the Plus2 is really great as well (https://www.friendlyarm.com/index.php?route=product/product&path=93&product_id=203). I hope that this feedback helps a bit!
  11. 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 )
  12. 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.
  13. 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!