5kft

Members
  • Content Count

    201
  • Joined

  • Last visited


Reputation Activity

  1. Like
    5kft got a reaction from Werner in OPi Zero - why are frequencies above 1.008GHz unavailable?   
    @Adrian Cable - I made the changes for sunxi-current and pushed to the repo:  https://github.com/armbian/build/commit/b2adb2935b4dcee57c982a1447de8cf75760dd2a.  This change adds a new boot overlay for the sun8i-h3 that enables a maximum of 1.3GHz at a CPU core voltage of 1.3v.  If you use this overlay, I strongly recommend you try driving the board hard to ensure stability (e.g., "stress --cpu 4", etc.)  Historically on most of my boards the maximum I could push to was 1.2GHz at 1.3v, which is why I added a 1.2GHz overlay for the H5 (and I could only get to 1.368GHz w/a 1.4v core voltage).  I can do the same for the H3, but am short on time atm.  I'll also add this overlay to sunxi-legacy as well, but I won't be able to get to this later.
     
    I tested this on one of my H3 boards w/a max CPU voltage of 1.3v:
     
    /boot/armbianEnv.txt (note the addition of "cpu-clock-1.3GHz-1.3v" to the "overlays=" line):
    verbosity=7 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost1 usbhost2 uart1 cpu-clock-1.3GHz-1.3v rootdev=UUID=3ad712a7-75cb-4ac1-8cfa-dbb67df8f239 rootfstype=f2fs extraargs=net.ifnames=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
    After booting with this overlay, from "cpufreq-info", w/everything else at the defaults, maximum clock rate is now 1.30GHz:
    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: 480 MHz - 1.30 GHz available frequency steps: 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 480 MHz and 1.30 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: 480 MHz:96.94%, 648 MHz:0.35%, 816 MHz:0.04%, 960 MHz:0.03%, 1.01 GHz:0.03%, 1.06 GHz:0.02%, 1.10 GHz:0.02%, 1.15 GHz:0.03%, 1.20 GHz:0.02%, 1.22 GHz:0.01%, 1.25 GHz:0.01%, 1.30 GHz:2.50% (253) Please give this a try and let me know how it goes   If 1.3GHz is unstable, I'll try to expedite adding the 1.2GHz overlay as well.
     
  2. Like
    5kft got a reaction from Werner in OPi Zero - why are frequencies above 1.008GHz unavailable?   
    Because the opp table in the DTs are common and used for all H3/H5 boards, not just your specific OPi Zero.  The CPU regulator voltage defines the maximum clock rate available, specific to each board.
     
     
    Actually this behavior is completely correct - it's how the CPU clock system is defined.  You do not want to make a general PR to increase the default clocks for lower voltages here because this will introduce instabilities across all other AW-based boards (!).
     
    There is a very easy way to enable this, however - you can use an overclock overlay.  I created a few of these a couple of years ago; see this thread for more information: 
     
     
    Now I just noticed that this patch apparently didn't make it over to the new sunxi-current branch (5.7); I'll fix this.  I also used the H5 prefix for this - I haven't tried it on an H3, but given the common opp table it should work.  I'll take a look at cleaning this up now for sunxi-current and will post back.
  3. Like
    5kft got a reaction from Werner in Thermal Throtteling not working in 5.3 and 5.4 kernel on Orange Pi Zero Plus   
    To bring this thread up to date - somewhere along the line the DTs dropped the correct trip list and cooling maps...I checked in fixes for this for the H3, H5, and H6 about a month ago (see https://armbian.atlassian.net/browse/AR-244 and https://armbian.atlassian.net/browse/AR-285).  All seems to work well now 
  4. Like
    5kft got a reaction from Werner in Orangepi 3 h6 allwiner chip   
    Done and done   https://armbian.atlassian.net/browse/AR-285
     
    Thanks for doing the testing!
     
  5. Like
    5kft got a reaction from Werner in Orangepi 3 h6 allwiner chip   
    I just pushed a patch with the test changes for this to my local repo:  https://github.com/5kft/build/commit/b75929e99f67a5d628bc031a1c4e73ab287c7df7.  This patch is against the "sunxi-current" target. 
     
    I can make a PR for this change, but again I don't have an H6 board to test any of this on, and I'd rather not do a PR until we know it works.  Also, I'm not sure what the appropriate critical temperature is for the H6, so in this patch I left it at 105C just like for the H3/H5.
     
    It'd be great if you could give this a try on your OPi1+.  You should be able to change directory to "/sys/class/thermal/thermal_zone0", and see the six new trip points.  To test these changes on my H3s and H5s, I used "armbianmonitor -m" in "screen", with both "stress" and the appropriate "cpuburn" for the architecture (see https://github.com/ssvb/cpuburn-arm).  The reported CPU clock rate should change appropriately when the temperature passes the various trip points.
     
    If this works I'd be happy to submit a PR for this change.
     
  6. Like
    5kft got a reaction from Werner in Armbian v20.05 (Kagu) Planning Thread   
    Fixed!  I marked this as Done (both sunxi-current and sunxi-dev, tested on both for H5 and H3) 
  7. Like
    5kft got a reaction from Werner in Armbian v20.05 (Kagu) Planning Thread   
    @Igor - I just checked in a new patch that fixes the thermal throttling issues (see https://github.com/armbian/build/commit/cc55d03a7b306e80f6fae1e16de1942af5fe9701).  I have tested it extensively on the H5 (Nano Pi NEO2 Black) and throttling works great now.
     
    Example run after several minutes of "cpuburn-a53":
     
    The new patch includes the same changes for the H3, and I tested on an Orange Pi Zero H2+ with no heatsink, using both "stress" and "cpuburn-a7", and it works great.  Here's an example run using "cpuburn-a7":
     
     
  8. Like
    5kft got a reaction from guidol in Armbian v20.05 (Kagu) Planning Thread   
    @Igor - I just checked in a new patch that fixes the thermal throttling issues (see https://github.com/armbian/build/commit/cc55d03a7b306e80f6fae1e16de1942af5fe9701).  I have tested it extensively on the H5 (Nano Pi NEO2 Black) and throttling works great now.
     
    Example run after several minutes of "cpuburn-a53":
     
    The new patch includes the same changes for the H3, and I tested on an Orange Pi Zero H2+ with no heatsink, using both "stress" and "cpuburn-a7", and it works great.  Here's an example run using "cpuburn-a7":
     
     
  9. Like
    5kft reacted to sfx2000 in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Recently revisiting things with H5 stability under certain SMP load factors* with @5kft and assistance with @lanefu - and H5 tends to be stable around 1104Mhz CPU/504MHz DDR with a 1.3v regulator overlay, and 1008/504 at 1.1v on NanoPi NEO2 - which doesn't really use the Mali450 at all.
     
    @lanefu was using a different H5 board (Orange Pi something or other - pls comment) - but he was also able to reproduce the stability issue I noted.
     
    Might be more interesting on something that engages all cores on the CPU, and does the GPU stress as well.
     
     
    * openssl speed -multi 4 - which flexs the ARMv8 enhancements there, engaging more of the logical blocks in Cortex-a53 - note that the governor in use is schedutil, which tends to be a different code path than "performance" or "on demand"
     
    @5kft - has been super awesome at helping out - reproducing the issue, concurring with analysis, proposing fixes...
     
    sfx
  10. Like
    5kft reacted to sfx2000 in Placemaker - H5 crashing under SMP load   
    Sounds good - and folks should test around the 504MHz DDR clock, along with the overlay to upclock on boards that support the 1.3V regulator... both at 1.2 and 1.3 GHz.
  11. Like
    5kft got a reaction from sfx2000 in Placemaker - H5 crashing under SMP load   
    OK well that answers that...  I think it's clear that the memory tests used back in 2017 weren't sufficient to determine the stability of this clock.  Why don't I go ahead and set it to 504MHz as that's the FA default, then if desired people could look at overclocking this further.
  12. Like
    5kft reacted to sfx2000 in Placemaker - H5 crashing under SMP load   
    ok - so the stock FA image also crashes on the same test - it behaves differently than the Armbian image, as it kills off the threads when it tries to do a privileged memory access...
     
    since we're working with armv8-a, we have kernel space (EL1) and user space (EL0) - hence the data abort, as the memory is marked as EL1, and an EL0 task cannot access that. I think that overclocking the CPU exposes a bug that is latent, even without the overlay, and this goes not to device tree, but to uboot and DDR ram init vectors there.
     
    The stress test (openssl) can show the bug, but this isn't the real problem, and the overlay just enables it to happen faster - getting board temp to around 60c, which on a small board like this, includes not only the SoC, but the DDR, can accelerate this issue, as some DDR can get a bit unstable at that temp.
     
    I don't have much time right now to debug further, as I'm in the middle of sfx's North America Tour - last week Austin, TX, next week Miami, FL, Atlanta, GA, Denver, CO, and a short trip to Salt Lake City, UT - about a week of downtime in the SAN, then back to Austin for a week.
     
    @5kft  -- Gnarly problem to sort, eh? But spending time might help other AW H5 targets...
     
    @Igor -- something to watch maybe
  13. Like
    5kft reacted to martinayotte in Switching SUNXI-DEV to 5.6.y   
    I've started the work of switching SUNXI-DEV to 5.6.y, as usual, few DT duplicates and fixes ...
    But I've faced also a big change related to 'file_operations' been changed to 'proc_ops' in all places over the kernel, which cause that all our EXTRAWIFI needs to be fixed.
    I hope to get it done by the end of this evening ...
     
  14. Like
    5kft got a reaction from guidol in Kernel 5.5.0-rc2 freezes on Orange PI Plus 2   
    For what it's worth, I've been running 5.5.0-rc2 on a number of NanoPi boards (NEO 2s and NEO 2 Blacks) for several weeks now, including one running mosquitto+Influx+Grafana+nginx+a lot of Python processes, and they've all worked flawlessly.
  15. Like
    5kft got a reaction from guidol in Orange PI Zero Plus CPU frequency problem   
    I'm just catching up on this topic...  I don't have access to my Zero Plus at the moment but from the picture on Xunlong's site (and my previous experience) it looks like this board has the same HW limitation as the Plus2 - the missing Q5 MOSFET (see red oval highlight in this picture):

    This problem/limitation is described in this thread:
     
    @Darkyere, if it in fact is the case that this part is not included on this board, then unfortunately your board will be limited to a maximum of 1008MHz (for reliable operation).  According to the schematic (https://linux-sunxi.org/images/6/67/ORANGE_PI-ZERO-PLUS_V1_0_Schematic.pdf, page 7), the power circuit does include the switching regulator, so it should be capable of providing 1.3v if this part were installed.  (Again, refer to the thread I mentioned previously for all details about this.)
     
    Igor's guidance of specifying the 1.3v regulator overlay alone is a workaround that will enable the higher clockrate to 1.0GHz.  However, without the Q5 MOSFET installed, do not specify the 1.3GHz overclock overlay, as then your board will certainly crash (as you noticed) 
     
     
  16. Like
    5kft got a reaction from guidol in H5 board without voltage-switching only up to 816Mhz?   
    Hi @guidol, I've pushed the change to sunxi-dev:  https://github.com/armbian/build/commit/f1cdca27530ed401ff3f5f301aae46155704c85d
     
    Enjoy!  
  17. Like
    5kft got a reaction from guidol in H5 board without voltage-switching only up to 816Mhz?   
    Makes sense; I'll merge this new overlay patch in with the existing 1.3GHz patch and should be able to push it tonight.  Thanks for testing it!
  18. Like
    5kft got a reaction from guidol in NanoPi NEO2 Voltage Regulator Update   
    Indeed, I took a quick look at the schematic (http://wiki.friendlyarm.com/wiki/images/5/57/NanoPi-NEO2-Black_1907_Schematic.pdf) and noticed a few things (if the schematic is accurate):
    If the VCC regulator is really a SY8106A (first page notes it is a MP2143DJ, which I'm guessing is a mistake), then the power circuit looks like the same as the NEO Core2, which means that the board may be able to drive the core voltage to 1.4v, meaning it can run up to 1.4GHz (like on the Core2).  This is nice! The board "version" GPIO (PL3) is wired the same as the NEO2 v1.1, so for the NEO2 build target this won't allow full speed of the board as this would load the NEO2 v1.1 default DT which actually uses the far more limited MP2143DJ regulator.   In fact, with the Black they wired PC4, PC6, and PC7 the same as well as the NEO2 v1.1, which means that we can't do runtime board identification.  This likely means that we'll have to do a different board target...
  19. Like
    5kft reacted to guidol in NanoPi NEO2 Voltage Regulator Update   
    @Neko May armbian has support  for 1.3V
     
    Use armbian-config ==> system ==> hardware
    and enable
    cpu-clock-1.3GHz-1.3v
    and
    gpio-regulator-1.3v
     
    save/reboot
     
    and now set cpu-governor and speeds in armbian-config ==> system ==> CPU
    (I think with these new setting you will get all speeds)
     
    PS: I ediited  my DTB for the OPi Zero Plus2 H5 to allow up to 1008Mhz with the 1.1v setting
    (like I had it on older armbian-builds):

  20. Like
    5kft reacted to guidol in Start looking at 5.3.y   
    @5kft I edited my table a bit less conservative - setting also 960 and 1008Mhz to 1.1V.
     
    and the OPi Zero Plus2 H5 "does work" - i dont know how good, but for testing reasons it seems to be OK for me
      hardware limits: 480 MHz - 1.01 GHz
      available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz
    idle:
      cpufreq stats: 480 MHz:95.51%, 648 MHz:0.15%, 816 MHz:0.70%, 960 MHz:0.01%, 1.01 GHz:3.63%  (142)
     
  21. Like
    5kft got a reaction from guidol in Start looking at 5.3.y   
    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).
     
  22. Like
    5kft reacted to Igor in armbianmonitor cpu-temperature broken? -ge: unary operator expected   
    https://github.com/armbian/build/commit/76ac54aae381714cee7bf1b03d4bce097b1630de
    root@orangepizeroplus2:~# uname -a Linux orangepizeroplus2 5.1.15-sunxi64 #5.90 SMP Thu Jul 4 21:07:22 CEST 2019 aarch64 GNU/Linux root@orangepizeroplus2:~# cat /sys/class/thermal/thermal_zone0/temp 58191  
  23. Like
    5kft got a reaction from chwe in armbianmonitor cpu-temperature broken? -ge: unary operator expected   
    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.
  24. Like
    5kft got a reaction from guidol in armbianmonitor cpu-temperature broken? -ge: unary operator expected   
    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.
  25. Like
    5kft got a reaction from LJB in Problem with Wifi on NanoPi Neo Plus2   
    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...