12 hours ago, Igor said:

Quote

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

 

 

I'm not sure why they wouldn't stuff the BSN20 MOSFET into Q5, given that it does enable the use of higher frequencies.  So in my opinion they should definitely include it.  However zador is completely correct:  if they change this then they need to increase the version number of the boards (both the H5 Plus2 and Plus).  The default for Armbian should be the lower (safe) clock speed for 1.1v to work with all board revisions, and the higher speed could be enabled per an overlay as previously noted (if the user has a modified or new board).

 

Please... Could someone to take a photo of BSN20 MOSFET in te PCB? I would like to check my Orange Pi Zero Plus 2.

Thanks in advance

5 minutes ago, Jota79 said:

Please... Could someone to take a photo of BSN20 MOSFET in te PCB? I would like to check my Orange Pi Zero Plus 2.

Thanks in advance

 

Sure, here's a pic showing the context - the location of Q5 is right next to the uSD slot on the underside of the board:

 

 

Thanks for photo!

 

Mine is missing too.... I do not understand this Xunlong decission...

The mosfets arrived and finaly managed to make a test, and it works! Thank you again 5kft !

 

For me it worked with this Armbian version: Armbian_5.34.171121_Orangepizeroplus2-h5_Ubuntu_xenial_next_4.13.14.img, then compiled  with the build compilation tips shown by 5kft  in a previous post. It seems it runs at 1296 Mhz from the start, I didn't need to update cpufrequtils.

Surprisingly, it stays in idle at a lower temperature than before. Idle now is 38 celsius -although with a temperature meter is around 45. Before it was 55 - real it was with 2-3 degrees more (ambient temperature around 25).

 

20:33:36: 1296MHz  0.02   0%   0%   0%   0%   0%   0% 38.2°C  0/11

 

pi@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 1.30 GHz 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:0.04%, 408 MHz:1.33%, 648 MHz:0.14%, 816 MHz:0.12%, 912 MHz:0.08%, 960 MHz:0.08%, 1.01 GHz:0.07%, 1.06 GHz:0.04%, 1.10 GHz:0.05%, 1.15 GHz:0.04%, 1.25 GHz:0.04%, 1.30 GHz:97.98%  (254)
pi@orangepizeroplus2:~$ sudo sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run && cat /sys/devices/virtual/thermal/thermal_zone0/temp
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.0661s
    total number of events:              10000
    total time taken by event execution: 28.2527
    per-request statistics:
         min:                                  2.82ms
         avg:                                  2.83ms
         max:                                  5.55ms
         approx.  95 percentile:               2.83ms

Threads fairness:
    events (avg/stddev):           2500.0000/1.87
    execution time (avg/stddev):   7.0632/0.00

56450

 

3 hours ago, km1kze said:

The mosfets arrived and finaly managed to make a test, and it works! Thank you again 5kft !

 

km1kze, this is great news - I am very glad to hear this!! 

 

Does anyone have a more recent purchase of this board? Have Xunlong started inluding the mosfet?

On 6/1/2018 at 3:00 PM, reverend_t said:

Does anyone have a more recent purchase of this board? Have Xunlong started inluding the mosfet?

Mine was bought in March, I contacted the seller in April and said is a new "update" to ensure board functionality - no more explanations.

In the meantime I just observed that this mosfet addition has a bigger drawback than the HDMI deactivation .. I have on all 5v pins something like 4.2v ... Basically the only way to communicate with the board will be through UART - to setup WIFI for headless .. A keyboard or any other USB device will not be functional. Saying that, and seeing how Shenzhen Xunlong Software is raising the prices to these boards (+25% in the last couple of months) it will be more practical to buy something from the NanoPi series...

2 hours ago, km1kze said:

.. I have on all 5v pins something like 4.2v ...

 

Might this possibly be due to the power adapter you are using...?  I just checked several of my modified boards and they all measure 5v on the 5v rails, and USB devices have been working fine for me with the Orange Pi expansion adapter.  As a test, I just plugged in an external USB SSD drive (powered via the USB port) and it was detected and works fine (and the 5v rail still measured 5v).

 

As has been noted many times elsewhere in these forums, it's very important to use only high quality 5V USB power adapters with these boards.  I've had good luck with FriendlyElec's 5V 3A Universal USB Port Power Adapter, as well as some 5V 2A adapters I purchased in the past.

I used an original Samsung Galaxy Note 2014 tablet adapter of 2.5A (measured it and it recharge the tablet at more than 12Wh and it surely has 2.5A)- also some other Chinese ones (2A at least), still the same thing

I took the mosfet out from the board and now the 5v are there. This is pretty weird, maybe is a fault in the board? While the mosfet was there, I also had at 1V2C around 1.3v, but maybe there are other pads I could check if is fully working?

Indeed, this is strange...   Perhaps it's just not worth it to do the mod - it's still not clear why Xunlong doesn't stuff this part.  Perhaps this power circuit is too unreliable with their H5-based boards?

 

 

55 minutes ago, 5kft said:

Indeed, this is strange...   Perhaps it's just not worth it to do the mod - it's still not clear why Xunlong doesn't stuff this part.  Perhaps this power circuit is too unreliable with their H5-based boards?

 

 

Yeah, I can confirm that my eMMC is not loading now and HDMI is dead (the mosfet is removed ).. Tried to load an image that I knew it worked and nothing... didn't check with UART yet to see if is alive, but have 1.09v-1.1v on 1v2c and correct voltages on pins.  There is a 1_5V pad somewhere near GPIOs, but it had a lower voltage - 1.36 v, do you have a similar value on that?

On 6/1/2018 at 4:00 PM, reverend_t said:

Does anyone have a more recent purchase of this board? Have Xunlong started inluding the mosfet?

My OPi Zero Plus2 H5 did arrive today (from Sweden), but also without the Q5

Maybe anyone can check againt his serial-number if this one is newer or older.

PCB Version is v1.0

 

At http://linux-sunxi.org/images/7/78/OPi_Zero_Plus_2_Bottom.jpg

you could see the PCB with a mounted Q5.

 

1 hour ago, guidol said:

Maybe anyone can check againt his serial-number if this one is newer or older.

PCB Version is v1.0

I have same board version. Without mosfet. Bought over year ago.

My dev sample board received last year also missing the Q5 ...

 

3 hours ago, guidol said:

My OPi Zero Plus H5 did arrive today (from Sweden), but also without the Q5

The first seconds i thought my OPi Zero Plus H5 is defective - because with uSD-Card inserted I didnt get a LED-light.

After ejecting the uSD-Card I did get a power-light

So I reinserted the uSD-Card, added the expansion PCB and a USB-Ethernet Dongle....

After a short time I could login via SSH to the DHCP-Ethernet-Dongle and reconfigure wlan0

 

Now the expansion is disconnected and I could login via SSH to wlan0.

I did use the 5.44 stretch image and updated to 5.46:
ARMBIAN 5.46.180603 nightly Debian GNU/Linux 9 (stretch) 4.14.47-sunxi64

System diagnosis information will now be uploaded to http://ix.io/1cqC
 

Could we please get some light in the future via /sys/class/leds, because at this time this directory is empty:
root@opi-zero-plus2-h5:/sys/class/leds# ls -l
total 0
 

@Igor is there a chance to add the information about the LEDs at https://www.armbian.com/orange-pi-zero-2-h5/#faq-section
(also for the H3 version)?

 

 

@guidoldid you try to successful reboot board via command 'reboot'? 

@guidol - re: /sys/class/leds:  if it might be helpful to you, I've added DT support for the OPi Zero Plus2 H5 LEDs to my local Armbian builds; see https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/update-H5-board-config-support.patch, and search for "sun50i-h5-orangepi-zero-plus2.dts" in the patch file.

 

4 minutes ago, rusatch said:

@guidoldid you try to successful reboot board via command 'reboot'? 

reboot did work after the apt-get upgrade with 5.44 without problems (if I remind me correct)

here at the OPi Zero Plus H5 (but without any reaction from the LED-lights)

 

but now with 5.46 he didnt came back after a "reboot"  
Now I had to power off/on like on the Odroid C2

4 minutes ago, 5kft said:

@guidol - re: /sys/class/leds:  if it might be helpful to you, I've added DT support for the OPi Zero Plus2 H5 LEDs to my local Armbian builds; see https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/update-H5-board-config-support.patch, and search for "sun50i-h5-orangepi-zero-plus2.dts" in the patch file.

 

sounds nice, but at this time I didnt know how to add this to my build system and use the patch

On 5/2/2018 at 11:39 PM, km1kze said:

Surprisingly, it stays in idle at a lower temperature than before. Idle now is 38 celsius -although with a temperature meter is around 45. Before it was 55 - real it was with 2-3 degrees more (ambient temperature around 25).

20:33:36: 1296MHz  0.02   0%   0%   0%   0%   0%   0% 38.2°C  0/11

 

at 816Mhz idle I got here 30-32 celsius:
 

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
21:11:06:  816MHz  0.00   2%   0%   1%   0%   0%   0% 31.9°C  0/2
21:11:11:  816MHz  0.00   0%   0%   0%   0%   0%   0% 31.8°C  0/2
21:11:16:  816MHz  0.00   0%   0%   0%   0%   0%   0% 30.9°C  0/2

 

8 hours ago, guidol said:

but now with 5.46 he didnt came back after a "reboot"  
Now I had to power off/on like on the Odroid C2

I have same problem. Output from uart doesn't show anything between shutdown and start. I dont know how to google it, and have not any logs for bugreports

9 hours ago, 5kft said:

@guidol - re: /sys/class/leds:  if it might be helpful to you, I've added DT support for the OPi Zero Plus2 H5 LEDs to my local Armbian builds; see https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/update-H5-board-config-support.patch, and search for "sun50i-h5-orangepi-zero-plus2.dts" in the patch file.

 

When i trying to use your patch:

[ warn ] * [c] update-H5-board-config-support.patch [ failed ]
 

 

How can i use it as overlay?

2 hours ago, rusatch said:

When i trying to use your patch:

[ warn ] * [c] update-H5-board-config-support.patch [ failed ]

 

I did get the same message, but I dont know if I did it the right way

 

[ o.k. ] * [l][c] sunxi64-pine64-plus-ethernet-fix.patch
[ warn ] * [c] update-H5-board-config-support.patch [ failed ]
[ .... ] Compressing sources for the linux-source package

 

I did save the .patch at /build/userpatches/kernel/sunxi-next and did start a compile - but it doenst seem that "easy"....

I'd like to make a patch explicitly for this and send a pull request to get it into the mainline, but unfortunately I don't have time to support this (much as I would like to!)...

 

If you just want to add support for the LEDs, you could clone the official Armbian master build tree, then do a custom patch.  For example, change to ".../build" and run "compile.sh":

 

 ./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=no KERNEL_KEEP_CONFIG=no BRANCH=next BETA=yes BUILD_KSRC=no CREATE_PATCHES=yes BOARD=orangepizeroplus2-h5

When the build pauses for the kernel patch, edit ".../build/cache/sources/linux-mainline/linux-4.14.y/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts", and simply add a block for the LEDs (I added mine following the existing "wifi-pwrseq" block).  E.g.,

        leds {
                compatible = "gpio-leds";

                pwr {
                        label = "orangepi:green:pwr";
                        gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
                        default-state = "on";
                };

                status {
                        label = "orangepi:red:status";
                        gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>; /* PA17 */
                };
        };

Save, and continue the build.  Then simply install the generated packages in ".../build/output/debs".  (It should also be possible to generate an overlay for this, but I haven't bothered to do this.)

8 hours ago, 5kft said:

If you just want to add support for the LEDs, you could...

Thank you very much! I follow your instruction and now the green led lighting at startup without dirty hacks, but the red led is silent. Also there is some links in /sys/class/led:

ls -l /sys/class/leds/
total 0
lrwxrwxrwx 1 root root 0 Jan  1  1970 orangepi:green:pwr -> ../../devices/platform/leds/leds/orangepi:green:pwr
lrwxrwxrwx 1 root root 0 Jan  1  1970 orangepi:red:status -> ../../devices/platform/leds/leds/orangepi:red:status

 

For build kernel with @5kft 's instruction in docker, build string looks like this:

./compile.sh docker KERNEL_ONLY=yes KERNEL_CONFIGURE=no KERNEL_KEEP_CONFIG=no BRANCH=next BETA=yes BUILD_KSRC=no CREATE_PATCHES=yes BOARD=orangepizeroplus2-h5
 

For editing dts files you need to login to running container via

docker ps

docker exec -it container_id bash
 

Update: red led silent because /sys/class/leds/orangepi\:red\:status/brightness is 0 by default.

updating /sys/class/leds/orangepi\:red\:status/brightness to 255 enable red led, but its just lighting like green led.

More statuses for leds:

cat /sys/class/leds/orangepi\:red\:status/trigger          
none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-c
trlrlock usbport usb-gadget usb-host mmc0 mmc1 mmc2 [heartbeat] cpu cpu0 cpu1 cpu2 cpu3 rfkill-any rfkill0 rc-feedback bluetooth-power

 

red led??? funny thing is that I never saw a red led blinking on my board, didn't know it even existed

Anyway I think my board is close to useless, despite the fact it has again the good voltages, I have problems to communicate with it even through UART.

 

On 6/5/2018 at 11:58 PM, rusatch said:

@guidoldid you try to successful reboot board via command 'reboot'? 

today I did create the patched kernel for the LEDs  from @5kft which did create the following .debs:
 

-rw-r--r-- 1 root root    31844 Jun  7 09:19 linux-dtb-next-sunxi64_5.46.180608_arm64.deb
-rw-r--r-- 1 root root 10577428 Jun  7 09:20 linux-headers-next-sunxi64_5.46.180608_arm64.deb
-rw-r--r-- 1 root root 15074744 Jun  7 09:21 linux-image-next-sunxi64_5.46.180608_arm64.deb
-rw-r--r-- 1 root root   221324 Jun  7 09:12 linux-u-boot-next-orangepizeroplus2-h5_5.46.180608_arm64.deb

I did install of of them via dpkg -i 

AND WHAT after a "reboot" at the serial console the OPi Zero Plus2 H5 DID reboot without to hang:
 

[  OK  ] Reached target Shutdown.
[12791.708297] reboot: Restarting system
INFO:    PSCI Affinity Map:
INFO:      AffInst: Level 0, MPID 0x0, State ON
INFO:      AffInst: Level 0, MPID 0x1, State ON
INFO:      AffInst: Level 0, MPID 0x2, State ON
INFO:      AffInst: Level 0, MPID 0x3, State ON

U-Boot SPL 2017.11-armbian (Jun 07 2018 - 12:12:33)
DRAM: 512 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):c9f55c0
NOTICE:  BL3-1: Built : 12:12:20, Jun  7 2018
NOTICE:  DT: sun50i-h5-orangepi-zero-plus2
NOTICE:  SCPI: dummy stub handler, implementation level: 000000
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9


U-Boot 2017.11-armbian (Jun 07 2018 - 12:12:33 +0300) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: OrangePi Zero Plus2
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1

So maybe the reboot problem is already solved?

Now I will test the LEDs....Power Green does light up  

Should I now freeze my kernel in armbian-config?

19 hours ago, 5kft said:

When the build pauses for the kernel patch, edit ".../build/cache/sources/linux-mainline/linux-4.14.y/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts", and simply add a block for the LEDs (I added mine following the existing "wifi-pwrseq" block).  

as information for others: there will be more than one pause - you should edit the file when the following pause appears

(I think its the third and last one) :
[ warn ] Make your changes in this directory: [ .../build/cache/sources/linux-mainline/linux-4.14.y ]
[ warn ] Press <Enter> after you are done [ waiting ]

 

 

11 hours ago, rusatch said:

Update: red led silent because /sys/class/leds/orangepi\:red\:status/brightness is 0 by default.

updating /sys/class/leds/orangepi\:red\:status/brightness to 255 enable red led, but its just lighting like green led.

Setting red led brightness to 255 and apply heartbeat as trigger:

echo "255" > /sys/class/leds/orangepi\:red\:status/brightness
echo "heartbeat" > /sys/class/leds/orangepi\:red\:status/trigger