Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit

[5kft]

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!

 

[km1kze]

Thank you for this valuable information! I have the same board and had the same difficulty on getting over 1Ghz... I observed that also on mine the mosfet is missing, but in the pictures from the shop is there ?! I sent a message to the seller to find out the reason...

[5kft]

Glad to help!  Yes, the photos on Xunlong's site show the part being present, but on both my Zero Plus2 and my Zero Plus (also an H5-based device) this single part is missing.  I've been running my fixed version of my Plus2 (where I soldered a BSN20 onto the missing spot) since my last post, and it's been working wonderfully!

 

As I noted previously, I updated the appropriate sun50i-h5* DTS files and added the regulator setting, updated the cpu_opp_table to include the increased clock frequencies, and updated the thermal cooling-maps and it clocks to 1.296GHz perfectly (and downclocks when the temps get too high).   I've been hammering the board over this past week to test stability, and it works great - zero crashes.

test@orangepizeroplus2:~$ cpufreq-info -c 1
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 1:
  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: 6.24 ms.
  hardware limits: 240 MHz - 1.30 GHz
  available frequency steps: 240 MHz, 408 MHz, 648 MHz, 816 MHz, 912 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.25 GHz, 1.30 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 240 MHz and 1.30 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.30 GHz.
  cpufreq stats: 240 MHz:88.52%, 408 MHz:3.58%, 648 MHz:0.00%, 816 MHz:0.00%, 912 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.25 GHz:0.00%, 1.30 GHz:7.89%  (28476)
test@orangepizeroplus2:~$
test@orangepizeroplus2:~$ sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --validate run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4
Additional request validation enabled.


Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          6.9850s
    total number of events:              10000
    total time taken by event execution: 27.9254
    per-request statistics:
         min:                                  2.79ms
         avg:                                  2.79ms
         max:                                  6.15ms
         approx.  95 percentile:               2.79ms

Threads fairness:
    events (avg/stddev):           2500.0000/1.22
    execution time (avg/stddev):   6.9813/0.00

test@orangepizeroplus2:~$
test@orangepizeroplus2:~$ cat /sys/class/thermal/thermal_zone0/temp
31339
test@orangepizeroplus2:~$

 

This simple fix really makes the Plus2 an incredibly useful board - just $20, super fast, built in eMMC, etc.!  It is unfortunate, however, as without this modification these boards are basically maxed at 816MHz (seemingly the safe peak for 1.1v CPU voltage).

 

Interestingly, all my Orange Pi H3-based devices do include this part.  It's just the H5-based ones that do not (but all the other power circuit parts are present).  Perhaps this is a quick workaround that Xunlong did to address potential thermal issues or something (?).

 

I ordered a number of BSN20 SOT23-3s as well as some more Plus2s, and will be doing a bit of soldering when they all arrive...!

 

[km1kze]

Thank you for the update!

Do you think these BSN20 will work?

https://www.aliexpress.com/item/Free-Shipping-10pcs-lot-BSN20-M8W-SOT-23-new-original/32705392701.html

 

Can you please provide more information/tutorial on how to achieve the proper clock (sorry I'm a bit of a newb in this) - just want to get this board to work properly on their advertised speed of 1.2 Ghz

 

 

[5kft]

I very much hope that those BSN20s will work - I bought mine from that very same seller 

 

Regarding increasing the clocks, I've attached a subset of my test patchset for the current mainline sunxi-next kernel (4.14.y) that you could start from.  Hopefully you should be able to just copy this to your "armbian/build/userpatches/kernel/sunxi-next/" directory, then build your kernel as normal (e.g., "./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=no KERNEL_KEEP_CONFIG=no BRANCH=next BETA=yes BUILD_KSRC=no BOARD=orangepizeroplus2-h5").  Note that you'll need to update your "/etc/default/cpufrequtils" configuration to set the new min/max speeds (don't forget to reboot or restart the cpufreq daemon after doing this).

 

When you do the build, make sure the patch step succeeds - the "z" at the beginning of the filename helps ensure that it is the last patch applied.

 

(Note also that on reboot the HDMI driver crashes on my Plus2 - as a temporary workaround I disabled HDMI in the DTS as well.  Also I noticed that the default Armbian OPi plus2 patchset adds the regulator entry - I was confusing this change with my Neo Plus2 patch for this.)

 

z-test-fix-h5-clock-reg-kernel-sunxi64-next.patch

[km1kze]

Thank you again, but I can't download the attached file, it seems it may not be properly uploaded. Can you please reupload it?

[5kft]

2 minutes ago, km1kze said:

Thank you again, but I can't download the attached file, it seems it may not be properly uploaded. Can you please reupload it?

 

I've attached it here as a zip file, hopefully that will work

z-test-fix-h5-clock-reg-kernel-sunxi64-next.patch

z-test-fix-h5-clock-reg-kernel-sunxi64-next.zip

[Igor]

Just now, 5kft said:

I've attached it here as a zip file, hopefully that will work

Both are ok but before the file was missing ... I don't know if it is related, but we had a short blackout on the main internet connection right around the time of the initial post.

[5kft]

Just now, Igor said:

Both are ok but before the file was missing ... I don't know if it is related, but we had a short blackout on the main internet connection right around the time of the initial post.

 

OK, thanks Igor!

[teenytinycactus]

This is really quite interesting. I have the same board and issues. I had been running at 900MHz to avoid the crashes, until someone skilled came along and worked out why it wasn't operating properly. Pretty curious as to why Xunlong broke their boards this way, I guess a replacement is out of the question? ?

[zador.blood.stained]

2 hours ago, teenytinycactus said:

Pretty curious as to why Xunlong broke their boards this way, I guess a replacement is out of the question? ?

DVFS is still broken in H5 BSP as far as I know so from Xunlong perspective the voltage switching circuit is pretty much useless.

[tkaiser]

4 hours ago, zador.blood.stained said:

DVFS is still broken in H5 BSP as far as I know so from Xunlong perspective the voltage switching circuit is pretty much useless.

 

Well, since Allwinner broke DVFS also on H3 SoCs with their latest BSP drop how do we have to deal with this? If Xunlong now starts to destroy voltage regulation on their H3 boards too how should we prevent user installations on new boards from crashing?

 

BTW: if I understood @Da Xue correctly this (new BSP without DVFS support) is the primary reason for Libre Computer's Allwinner boards having no voltage regulation by design.

 

To be honest: using and supporting Allwinner H series gets more and more irrelevant...

[zador.blood.stained]

Well, if Xunlong didn't change any markings on the board (especially the revision number) then it gets pretty nasty

 

5 minutes ago, tkaiser said:

If Xunlong now starts to destroy voltage regulation on their H3 boards too how should we prevent user installations on new boards from crashing?

Compile the list of affected devices first (i.e. by contacting Steven), then put the notice regarding possible instability for newer boards on board download pages. After that there are different ways to limit the top CPU frequency, but there are multiple things to check and change - default in-kernel governor, OPPs in FEX and DT, /etc/default/cpufrequtils

[tkaiser]

18 minutes ago, zador.blood.stained said:

by contacting Steven

 

Yes, this is the first thing that should happen. We have now 3 reports of Orange Pi where this specific Mosfet is missing so it's either a batch of broken boards (no idea whether that's possible? Missing reel in the pick-and-place machine?) or an intentional change. If it's the latter then why using Orange Pi any more?

 

@Igor are you still constantly in touch with Steven and can ask him?

[Igor]

Just now, tkaiser said:

 are you still constantly in touch with Steven and can ask him?

Yes. I sent him this thread.

[@lex]

1 hour ago, tkaiser said:

We have now 3 reports of Orange Pi where this specific Mosfet is missing so it's either a batch of broken boards

Mine is missing too and i have possibly the second batch (very old) so it comes from the beginning... 

[zador.blood.stained]

I've found my boards, and on mine Zero Plus and Zero Plus 2 (H5) Q5 is missing.

[StephenW]

The Q5 BSN20 was also missing on my OPi Plus 2 H5 - yet if I boot from the *official* OrangePi ubuntu image the DVFS seemed to work fine. It's a software thing?

If I boot with armbian - the board sticks with 1.2Ghz and it would go with random crashes. If I run it under 960Mhz it's stable

 

[zador.blood.stained]

2 minutes ago, StephenW said:

if I boot from the *official* OrangePi ubuntu image the DVFS seemed to work fine. It's a software thing?

Then it should be called "DFS" instead 

And yes, frequency switching should work on those images, as I remember the main problem was with the regulators (the "V" part in DVFS), and since AW refuse to provide the ARISC firmware sources it was never fixed.

[tkaiser]

Ok, then let's assume voltage regulation simply never worked on the Orange Pi H5 boards with SY8113B, right? Which would mean we should rather sooner than later limit them to 912 MHz max cpufreq... (or even 816 MHz to have some safety headroom?)

[5kft]

9 minutes ago, tkaiser said:

Ok, then let's assume voltage regulation simply never worked on the Orange Pi H5 boards with SY8113B, right? Which would mean we should rather sooner than later limit them to 912 MHz max cpufreq... (or even 816 MHz to have some safety headroom?)

 

I was going to suggest this.  With this part missing the board is basically locked at running at 1.1v.

[zador.blood.stained]

Well, if we assume for now that Q5 was never soldered on "small" H5 boards, then we could simply add a fixed 1.1V regulator in DT (or just remove the one that is currently present there) to fix this. This will automatically limit the frequency to 816MHz with our current DVFS table.

[tkaiser]

Hmm... not sure what to do. I've no idea how many users are able or willing to solder this 'Q5 BSN20' thing so they can make use of DVFS instead of DFS and clock the H5 above 912 MHz. Would also be interesting whether Xunlong plans a new board revision with Q5 already soldered...

 

I would prefer settings that allow to easily switch from 'no DVFS' to 'working DVFS'. Is /etc/defaults/cpufrequtils part of our BSP package?

[Piv Klit]

I power my board with GPIO, and it´s running stable at 1152 MHz with the stock psu, stress testet it over a few days running a cpu miner on it. The part is missing and I bought the board when it came out. (I think it was summer last year)

ARMBIAN 5.38.180128 nightly Ubuntu 16.04.4 LTS 4.14.18-sunxi64  

[Da Xue]

@tkaiser Allwinner only certifies the H3 to operate at 1008MHz @1.2V and H5 to operate at 1008MHz @ 1.1V with DDR clocks up to 672MHz. Designs and software support for adjustable voltage and higher clock rates must be validated by the third party that chooses to implementing such features.  DVFS will not be supported in the Allwinner H3/H5 BSPs since the transition to AXP8036. I have seen some small boards with 16-bit DDR3 (1 DDR chip) clocked at 744MHz but they are almost guaranteed to have memory errors and video playback issues.

[zador.blood.stained]

1 hour ago, tkaiser said:

I would prefer settings that allow to easily switch from 'no DVFS' to 'working DVFS'.

For me a DT overlay is a reasonably easy solution to this

 

1 hour ago, tkaiser said:

Is /etc/defaults/cpufrequtils part of our BSP package?

Yes, but it is a much less reliable solution for limiting the frequency, given how many people want to overclock their boards (even to 1.3+ GHz) without understanding the hardware limitations

[tkaiser]

21 minutes ago, zador.blood.stained said:

For me a DT overlay is a reasonably easy solution to this

Agreed!

[5kft]

15 minutes ago, tkaiser said:

Agreed!

 

I like this as well - very clean/simple.  By default the device will work reliably, and if someone wants to increase the clocks they can easily do so and it will "just work" (assuming that their board H/W actually supports the higher clock rate).

[Igor]

Steven:

Quote

as your suggestion, should we change the Q5 into BSN20 MOSFET?Or should we just leave the possition of Q5 empty?

 

[zador.blood.stained]

In any case if they decide to change anything they should also change the board(s) revision number. And at least adding a missing MOSFET is not as bad as removing a previously present one.