• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map




Everything posted by 5kft

  1. 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!
  2. Hi @JamesX, excellent - glad to hear this!
  3. Agreed - congratulations on an amazing effort! The scope of devices that Armbian supports and how well it all works is simply incredible
  4. 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...?
  5. 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.
  6. 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!
  7. 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?
  8. 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?
  9. Hi, this should now be fixed with https://github.com/armbian/build/commit/e0f27fff66220e56b6419879957af28fa46ff84f. I tested this on an unmodified Plus2 H5 (i.e., missing MOSFET in the regulator switching circuit). Without this change the boot would fail as @guidol noted (heartbeat, then stops, and the board hangs); with this change it boots and runs just fine, and the maximum CPU clock rate is properly limited.
  10. Quick note - I just built dev for R1 and it works well - did a cursory test of 4.19.2-sunxi and wireless, USB, DVFS/cpufreq, etc. and everything works. It does have the following warnings (as you noted previously), but the core speeds seem to work fine up to 1.3v/1.01GHz: [ 8.116042] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 8.116069] cpu cpu0: _opp_add: OPP not supported by regulators (1056000000) [ 8.116263] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 8.116280] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 8.116512] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 8.116527] cpu cpu0: _opp_add: OPP not supported by regulators (1152000000) [ 8.116725] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 8.116737] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 8.116903] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 8.116922] cpu cpu0: _opp_add: OPP not supported by regulators (1224000000) [ 8.117152] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 8.117170] cpu cpu0: _opp_add: OPP not supported by regulators (1248000000) [ 8.117376] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 8.117392] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 8.117557] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 8.117572] cpu cpu0: _opp_add: OPP not supported by regulators (1344000000) [ 8.117755] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 8.117769] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000)
  11. When the latest tree is built and released and you switch to it, then you should change "cpu-clock-1.3GHz" to "cpu-clock-1.3GHz-1.3v". You can check for this in "/boot/dtb/allwinner/overlay/".
  12. 5kft

    Quick review of NanoPi Fire3

    Hi @shaun27, I just implemented support for this for the Fire3 and have pushed the changes into Armbian (see https://github.com/armbian/build/commit/1301f9f8c254d8408b9136948c786dffa5007acd). The power button/PWRKEY now works for both powering up the board as well as powering it down
  13. I found an old laser IR thermometer I have and when aiming measuring the heatsink on the Core2 it doesn't seem too far off (e.g. 32C measured vs 34 reported via "temp"). Perhaps the previous implementation was incorrect? I'm curious what your results will be!
  14. Quick note - the Nano Pi Neo Core2 works as well with the new kernel. Very nice that it clocks up to 1.37GHz by default now! root@nanopineocore2:~# cat /proc/version Linux version 4.19.2-sunxi64 (root@gandalf) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #11 SMP Sun Nov 18 13:40:50 UTC 2018 root@nanopineocore2:~# 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: 2.04 ms. hardware limits: 120 MHz - 1.37 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, 1.34 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 408 MHz and 1.37 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 120 MHz:0.01%, 240 MHz:0.04%, 480 MHz:73.59%, 648 MHz:0.10%, 816 MHz:0.01%, 960 MHz:0.02%, 1.01 GHz:0.00%, 1.06 GHz:0.01%, 1.10 GHz:0.00%, 1.15 GHz:0.01%, 1.20 GHz:0.01%, 1.22 GHz:0.00%, 1.25 GHz:0.02%, 1.30 GHz:0.04%, 1.34 GHz:0.00%, 1.37 GHz:26.15% (55) root@nanopineocore2:~#
  15. Hi @Igor, just a quick note - I had to make a small fix for Orange Pi Zero Plus (https://github.com/armbian/build/commit/b0f92ee58c6cbefbbcd52dcb93e1128c7528cb54); with this change this board seems to work fine now as well with the new 4.19.y kernel.
  16. Thanks @Icenowy! I will try to dig further into this when I get time...!
  17. @Igor - in 4.19.y it looks like the CPU temperature now reported by "/sys/class/thermal/thermal_zone0/temp" is ~10C greater than it was in previous kernels for the H5. The "sun4i-gpadc-iio.c" driver in 4.19.y has numerous changes compared to the previous kernels, and I'm not sure if the previous value reported was incorrect and the new value is correct, or vice-versa. This is consistent across all my different H5 boards. Previously my H5 boards would idle around 30C (reported), now they idle at around 40C (reported): root@orangepizeroplus2:/sys/class/thermal/thermal_zone0# cat temp 40341 root@orangepizeroplus2:/sys/class/thermal/thermal_zone0# Unfortunately I don't have a thermometer handy to check the case temperature of the CPU, but by finger test on the boards the CPU appears to physically be at the same temperature as with the previous kernel... All boards are running idle with no activity (e.g., 240MHz/480MHz clock speed). @Icenowy might you have any ideas regarding this?
  18. Hi @Igor, I've tried a top-of-tree H5 build so far on: Neo2 v1.1 512MB Neo2 v1.1 1GB Orange Pi Zero Plus2 H5 Nano Pi Neo Plus2 ...and all works well. Very nice!! (These are all dumb regulator boards BTW) Tests include USB (Wi-Fi and Ethernet dongles), H/W SPI interface (via spidev), multiple GPIOs (via libgpiod). I've switched to 4.19.y for all of these now. (I still have a few more boards that I'll dig up and try it on...)
  19. Hi @rusatch, if you are using the 1.3GHz CPU overclock overlay in your "overlays=" line for your H5 then this could be the cause of your problem (overlay "cpu-clock-1.3GHz"). (If this isn't the case for you, then it's odd because USB works fine for me on four different boards I tried with the new 4.19 kernel...) This overlay needed to be updated for 4.19.y, and if you load it by default in the current build then the load will fail and the DT will reset to the board default. I just pushed an update for this for the new kernel (see https://github.com/armbian/build/commit/06451d37a64a4fd2599207722c73c9c160b63100). The new 4.19.y mainline includes a much more complete cpu opp frequency table (nice!), with frequency and voltage definitions all the way to 1.368GHz. For boards that have real DVFS-capable regulators then the higher frequencies will work by default. So I updated the 1.3GHz overclock overlay hack for boards that only provide a fixed 1.3v maximum, and the new name for the overlay is "cpu-clock-1.3GHz-1.3v". (Side note: I removed the previous "cpu-clock-1.4GHz" overlay as given that the maximum clock speed default at 1.4v is now 1.368GHz it's not really worth maintaining one that goes to 1.396GHz.)
  20. Have you tried hooking up a USB-serial connection to the board so that you can log in and see what is going on, check/configure networking, etc.?
  21. 5kft

    Boot and dmesg errors

    @Evgeny, +1 to everything that @chwe and @Igor have said above. Some of these messages have been cleaned up since the 4.14.y kernel (e.g., regulator errors), but none of them are significant.
  22. I'm curious why that would need to be the case...? I'm thinking that it could be as simple as using something like Bugzilla (https://www.bugzilla.org/download/) or any number of other ticket systems used by FOSS projects and initiatives. Just for issue/question organization and tracking. It's not much different than using a forum system - no pay needed, etc.?
  23. Just "thinking out loud" as it were, but I am wondering if introducing some sort of "ticketing system" for Armbian could be useful for tracking things and helping add some structure around helping with the project (and for people to get help). At present now the forums can be great for discussion, but they are very ad-hoc as an engagement system. I find that for myself if I'd like to raise something I'm not sure what the best method is - e.g., post in a forum somewhere, submit an Issue for the project on github, or just push a fix into the project and explain the change in a commit comment, add a PR with a comment discussion, etc... Ticket systems can also be "black holes", but forum posts can be as well... This could help people structure engagement, communicate on a particular thread, using a more structured and trackable process...? I love to help the project, and I try to help when I can, but I'm not sure how I best could contribute, given my (unfortunate) sporadic availability. If I have some spare time on some weekend, it'd be great to look through tickets and see if I could fix something for someone, or help someone with something... Another example - my NEO4 comes today, and I'd like to play with it this weekend, and start fixing things, pushing changes, etc. but I also don't want to "step on anyone's toes" (I'm a Rockchip newbie, which is one reason I got the board ) - assigning tickets for areas could help focus discussion, coordinate work between people, etc...? Anyway just some quick thoughts...!
  24. 5kft

    NanoPi NEO4

    FYI - the NEO4 is now available - see https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=241 I just placed my order
  25. Then Maxime Ripard perhaps shouldn't complain and should help make it easier for us? Could @Icenowy shed some light on the process? @Igor and @chwe are right in that we can't have any single points of failure.