Jump to content

Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit


5kft

Recommended Posts

22 minutes ago, guidol said:

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?

I did freeze my kernel BUT after the next "reboot" its did hang after "Reached target Shutdown." and some more messages - which I didnt get at the successful restart:

[  OK  ] Reached target Shutdown.
[ 1646.268369] systemd-shutdow: 62 output lines suppressed due to ratelimiting
[ 1646.354170] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
[ 1646.370471] systemd-journald[433]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 1646.406951] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[ 1646.421787] systemd-shutdown[1]: Hardware watchdog 'sunxi-wdt', version 0
[ 1646.429342] systemd-shutdown[1]: Unmounting file systems.
[ 1646.435814] systemd-shutdown[1]: Remounting '/' read-only with options 'errors=remount-ro,commit=600'.
[ 1646.472403] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro,commit=600
[ 1646.491825] systemd-shutdown[1]: Remounting '/' read-only with options 'errors=remount-ro,commit=600'.
[ 1646.501350] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro,commit=600
[ 1646.508684] systemd-shutdown[1]: All filesystems unmounted.
[ 1646.514274] systemd-shutdown[1]: Deactivating swaps.
[ 1646.519451] systemd-shutdown[1]: All swaps deactivated.
[ 1646.524697] systemd-shutdown[1]: Detaching loop devices.

 

Link to comment
Share on other sites

It's been a long time since I've looked at the boot/reboot messages on my OPi Zero +2, but when I first was trying it I noticed that all of the HDMI-related drivers were segfaulting at reboot, causing it to hang.  Given that I'm using these boards headless, I didn't need HDMI enabled, so I disabled these drivers via the DT.  This solved all of my reboot crashes/hangs.  If you want to try this, you can edit "sun50i-h5-orangepi-zero-plus2.dts" as before, and comment out the "&hdmi" block.

 

(Yes, I know it would be better to determine root cause for the crashes and fix that, etc. etc. but this is an easy workaround :))

 

Link to comment
Share on other sites

8 minutes ago, 5kft said:

It's been a long time since I've looked at the boot/reboot messages on my OPi Zero +2, but when I first was trying it I noticed that all of the HDMI-related drivers were segfaulting at reboot, causing it to hang. 

You mean the HDMI problems at shutdown as seen below in the hidden contents?

Spoiler

[ 2904.211005] Internal error: Oops: 96000004 [#1] SMP
[ 2904.218014] Modules linked in: sun8i_dw_hdmi(-) dw_hdmi cec snd_soc_simple_card rc_core snd_soc_simple_card                _utils snd_soc_core snd_pcm_dmaengine snd_pcm sun8i_mixer sun4i_tcon snd_timer sun4i_drm iio_hwmon industriali                o usb_f_acm u_serial g_serial libcomposite brcmfmac brcmutil cfg80211 rfkill sunxi musb_hdrc [last unloaded: s                un4i_gpadc_iio]
[ 2904.248206] CPU: 3 PID: 4498 Comm: modprobe Not tainted 4.14.48-sunxi64 #7
[ 2904.255075] Hardware name: Xunlong Orange Pi Zero Plus2 (DT)
[ 2904.260731] task: ffff8000036d2700 task.stack: ffff00000a8e0000
[ 2904.266659] PC is at drm_dev_unregister+0x14/0xe0
[ 2904.271370] LR is at sun4i_drv_unbind+0x1c/0x50 [sun4i_drm]
[ 2904.276940] pc : [<ffff00000865494c>] lr : [<ffff000000ad507c>] pstate: 60000145
[ 2904.284327] sp : ffff00000a8e3ca0
[ 2904.287639] x29: ffff00000a8e3ca0 x28: ffff8000036d2700
[ 2904.292950] x27: ffff000008991000 x26: 000000000000006a
[ 2904.298261] x25: 0000000000000124 x24: 0000000000000015
[ 2904.303572] x23: ffff800016ac8870 x22: ffff000008cba000
[ 2904.308882] x21: ffff000000be4218 x20: 0000000000000000
[ 2904.314193] x19: 0000000000000000 x18: 0000000000000002
[ 2904.319504] x17: 0000ffff8efd2240 x16: ffff000008127f00
[ 2904.324814] x15: 0000000000000000 x14: ffff8000159cb940
[ 2904.330127] x13: ffff800016838790 x12: 0000000000000030
[ 2904.335439] x11: 0000000000000030 x10: 0101010101010101
[ 2904.340751] x9 : 241f394f42533300 x8 : ffff800014957458
[ 2904.346061] x7 : 0000000000000000 x6 : ffff800016ad0810
[ 2904.351373] x5 : ffff800016199458 x4 : 0000000000000000
[ 2904.356684] x3 : dead000000000100 x2 : dead000000000200
[ 2904.361995] x1 : ffff000000ad5060 x0 : 0000000000000000
[ 2904.367308] Process modprobe (pid: 4498, stack limit = 0xffff00000a8e0000)
[ 2904.374178] Call trace:
[ 2904.376627] Exception stack(0xffff00000a8e3b60 to 0xffff00000a8e3ca0)
[ 2904.383067] 3b60: 0000000000000000 ffff000000ad5060 dead000000000200 dead000000000100
[ 2904.390895] 3b80: 0000000000000000 ffff800016199458 ffff800016ad0810 0000000000000000
[ 2904.398722] 3ba0: ffff800014957458 241f394f42533300 0101010101010101 0000000000000030
[ 2904.406550] 3bc0: 0000000000000030 ffff800016838790 ffff8000159cb940 0000000000000000
[ 2904.414377] 3be0: ffff000008127f00 0000ffff8efd2240 0000000000000002 0000000000000000
[ 2904.422205] 3c00: 0000000000000000 ffff000000be4218 ffff000008cba000 ffff800016ac8870
[ 2904.430033] 3c20: 0000000000000015 0000000000000124 000000000000006a ffff000008991000
[ 2904.437860] 3c40: ffff8000036d2700 ffff00000a8e3ca0 ffff000000ad507c ffff00000a8e3ca0
[ 2904.445687] 3c60: ffff00000865494c 0000000060000145 ffff00000a8e3c90 ffff0000082794ac
[ 2904.453516] 3c80: 0000ffffffffffff ffff800015d2ce58 ffff00000a8e3ca0 ffff00000865494c
[ 2904.461346] [<ffff00000865494c>] drm_dev_unregister+0x14/0xe0
[ 2904.467094] [<ffff000000ad507c>] sun4i_drv_unbind+0x1c/0x50 [sun4i_drm]
[ 2904.473712] [<ffff000008675aa4>] take_down_master+0x24/0x48
[ 2904.479285] [<ffff000008675be8>] component_del+0x90/0x130
[ 2904.484689] [<ffff000000be305c>] sun8i_dw_hdmi_remove+0x14/0x28 [sun8i_dw_hdmi]
[ 2904.492001] [<ffff00000867e674>] platform_drv_remove+0x24/0x50
[ 2904.497834] [<ffff00000867ce10>] device_release_driver_internal+0x170/0x200
[ 2904.504794] [<ffff00000867cf08>] driver_detach+0x48/0x90
[ 2904.510106] [<ffff00000867bebc>] bus_remove_driver+0x54/0xb0
[ 2904.515764] [<ffff00000867d634>] driver_unregister+0x2c/0x50
[ 2904.521423] [<ffff00000867e768>] platform_driver_unregister+0x10/0x18
[ 2904.527865] [<ffff000000be3e80>] sun8i_dw_hdmi_pltfm_driver_exit+0x10/0x190 [sun8i_dw_hdmi]
[ 2904.536217] [<ffff0000081280dc>] SyS_delete_module+0x1dc/0x260
[ 2904.542047] Exception stack(0xffff00000a8e3ec0 to 0xffff00000a8e4000)
[ 2904.548486] 3ec0: 0000aaaaedd40488 0000000000000800 0000ffffce838790 0000000000000000
[ 2904.556313] 3ee0: 0000ffffce837799 000000000000000a 1999999999999999 0000000000000000
[ 2904.564141] 3f00: 000000000000006a 0000ffff8f00f500 000000000000000a 0000000000000005
[ 2904.571967] 3f20: 0000000000000000 0000000000000000 0000000000000004 0000000000000000
[ 2904.579796] 3f40: 0000aaaae849ef68 0000ffff8efd2240 0000000000000000 0000aaaaedd40420
[ 2904.587624] 3f60: 0000aaaaedd40488 0000000000000000 0000000000000000 0000aaaaedd40488
[ 2904.595452] 3f80: 0000000000000006 0000aaaae849e000 0000aaaae849e000 0000ffffce83add9
[ 2904.603280] 3fa0: 0000000000000000 0000ffffce8387c0 0000aaaae84838b4 0000ffffce8387c0
[ 2904.611107] 3fc0: 0000ffff8efd2248 0000000060000000 0000aaaaedd40488 000000000000006a
[ 2904.618933] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 2904.626764] [<ffff000008083080>] el0_svc_naked+0x34/0x38
[ 2904.632078] Code: 910003fd a90153f3 aa0003f4 f90013f5 (f9401001)
[ 2904.638171] ---[ end trace 1ece2861d7bc5889 ]---
 

 

 

Link to comment
Share on other sites

7 minutes ago, guidol said:

You mean the HDMI problems at shutdown as seen below in the hidden contents?

 

Yes.  Actually I ended up commenting out the "&hdmi" block, the "&mixer0" block, and the "&sound_hdmi" block (I don't need audio support either):

/*
&hdmi {
        status = "okay";
};

&mixer0 {
        status = "okay";
};
*/

&r_pio {
        wifi_wake: wifi_wake@0 {
                pins = "PL7";
                function = "irq";
                bias-pull-up;
        };
};

/*
&sound_hdmi {
        status = "okay";
};
*/

 

 

Edited by 5kft
(edited to provide more detail)
Link to comment
Share on other sites

20 minutes ago, 5kft said:

Yes.  Actually I ended up commenting out the "&hdmi" block, the "&mixer0" block, and the "&sound_hdmi" block (I don't need audio support either):

for analog audio via the expansion board I think I should leave the mixer0-block in working order?

Link to comment
Share on other sites

29 minutes ago, 5kft said:

Probably - it's worth a try!

I disabled hdmi & sound_hdmi but not mixer0 and now reboot is working :)
At this time I havent installed the expansionboard because I will wait for the case for stable mounting that thing.

Link to comment
Share on other sites

11 hours ago, rusatch said:

May be you need freeze also package like linux-dtb-next-sunxi64 because dtb-files with hardware table exactly in this package.

I did freeze the kernel via armbian-config :) 

So armbian-config also did already freeze for me the dtb package :) 

 

kernel_freeze.jpg

Link to comment
Share on other sites

well it seems that my h5 orange pi was not dead (yet :D)

I connected an usb ethernet and installed the image @guidol suggested and updated with the hdmi off/leds on patch

my board is looking like an Xmas tree now and fully functional! thank you guys!

 

1. the led behavior is not saved after reboot, how can I achieve that? I tried putting in /etc/rc.local this but not working:

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

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

   echo "mmc0" > /sys/class/leds/orangepi\:green\:pwr/trigger

 

2. this armbian version has the cpu capped to 816Mhz? I remember that without the mosfet I could reach 1152Mhz on an armbian build. Is because this version (5.44) or there is other explanation?

Link to comment
Share on other sites

41 minutes ago, km1kze said:

 

@guidol

 

1. the led behavior is not saved after reboot, how can I achieve that? I tried putting in /etc/rc.local this but not working:

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

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

   echo "mmc0" > /sys/class/leds/orangepi\:green\:pwr/trigger

 

try to put a 

sleep 5

before the first command. sometimes it works if the system waits some seconds to complete other services.

If it wont work try 

sleep 10

an then you could shorten the time at every boot until it works.

 

In very bad circumstances add a sleep between the conmmands..... some SBCs need more time than others....but a H5 should be fast enough :)

 

Link to comment
Share on other sites

5 hours ago, km1kze said:

2. this armbian version has the cpu capped to 816Mhz? I remember that without the mosfet I could reach 1152Mhz on an armbian build. Is because this version (5.44) or there is other explanation?

 

My boards (pre-addition of the MOSFET) would crash at anything over ~900MHz at 1.1v, so 816 is probably a safe maximum.  It's easy enough to override this by editing "/etc/default/cpufrequtils" and changing the "MAX_SPEED=" value to your desired maximum clock frequency.  After you make this change you can reboot or restart the "cpufrequtils" service.

Link to comment
Share on other sites

On 6/11/2018 at 11:13 AM, guidol said:

try to put a 

sleep 5 

before the first command. sometimes it works if the system waits some seconds to complete other services.

If it wont work try 

sleep 10

an then you could shorten the time at every boot until it works. 

 

In very bad circumstances add a sleep between the conmmands..... some SBCs need more time than others....but a H5 should be fast enough :)

 

Unfortunately is not working... I think is something else here

If I simply run the command like this

 

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

 in terminal is not working, not even if I enter as root with

sudo su

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

then it says:

bash: /sys/class/leds/orangepi:red:status/brightness: Permission denied

 

it only works with

sudo -s

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

 

* maybe is there a way to directly put these settings in the .dts file? will something like default-brightness-level work?

Link to comment
Share on other sites

1 hour ago, km1kze said:

* maybe is there a way to directly put these settings in the .dts file?

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/devicetree/bindings/leds/common.txt

 

Edit:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/devicetree/bindings/leds/leds-gpio.txt

(please note that these are GPIO leds, not PWM leds, so you can't fine tune the brightness level).

Link to comment
Share on other sites

"sudo" is applied only on the left part of ">", right part still under normal user ...

Another way to do it is, but not really elegant :

 

echo "255" | sudo tee -a /sys/class/leds/orangepi\:red\:status/brightness

 

Another way could be :

 

echo "255" | sudo dd of=/sys/class/leds/orangepi\:red\:status/brightness

Link to comment
Share on other sites

:thumbup:
 

1 hour ago, rusatch said:

green led working as power, red as mmc0 activities

Also on a DEV branch. Now check what I need to fix that next patch will not need editing.  

Link to comment
Share on other sites

59 minutes ago, Igor said:

Now check what I need to fix that next patch will not need editing

Its OK! I download last commits by 'git pull' , then build with standart './compile.sh docker' , install maked debs and reboot . Onboard leds works as it should. :)

Link to comment
Share on other sites

On 6/12/2018 at 11:34 PM, km1kze said:

Unfortunately is not working... I think is something else here

If I simply run the command like this

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

 in terminal is not working, not even if I enter as root with

sudo su

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

then it says:

bash: /sys/class/leds/orangepi:red:status/brightness: Permission denied

 

 

OK - I do use root as user in my shell-console and got no permissions problem in the shell-console or in the /etc/rc.local...
see hidden content:
 

Spoiler

root@opi-zero-plus2-h5(192.168.6.25):~# sudo echo "255" > /sys/class/leds/orangepi\:red\:status/brightness
root@opi-zero-plus2-h5(192.168.6.25):~# sudo echo "0" > /sys/class/leds/orangepi\:red\:status/brightness
root@opi-zero-plus2-h5(192.168.6.25):~# echo "255" > /sys/class/leds/orangepi\:red\:status/brightness
root@opi-zero-plus2-h5(192.168.6.25):~# echo "heartbeat" > /sys/class/leds/orangepi\:red\:status/trigger

 

root@opi-zero-plus2-h5(192.168.6.25):~# more /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sleep 5
# echo "mmc0" > /sys/class/leds/orangepi:green:pwr/trigger
echo "mmc1" > /sys/class/leds/orangepi:green:pwr/trigger
echo "255" > /sys/class/leds/orangepi\:red\:status/brightness
echo "heartbeat" > /sys/class/leds/orangepi\:red\:status/trigger

sleep 5

mosquitto_pub -h 192.168.6.99 -t ESPEAK -m "IP 25 boot complete!"
 

exit 0

 

Link to comment
Share on other sites

8 minutes ago, teenytinycactus said:

Can anyone please confirm the markings on the transistors they received from aliexpress? I bought from a link in this thread and it has "J1 6" on it. Is that.... suitable? I'll probably hold off soldering it.

 

Don't remember what was written on them, but if you bought from my link, they're good 

 

You can also see a J1 marking on the original mosfet from the orange pi zero H2+

https://www.toysforscience.com/wp-content/uploads/2017/08/1482138186-1.jpg

Link to comment
Share on other sites

9 hours ago, teenytinycactus said:

Can anyone please confirm the markings on the transistors they received from aliexpress? I bought from a link in this thread and it has "J1 6" on it. Is that.... suitable? I'll probably hold off soldering it.

 

Decoding SMD part codes can be an interesting exercise :huh:  Unfortunately my AliExpress order for these parts had an issue and was never delivered.  I ended up ordering a set of BSN20s from Digi-Key in the U.S. (https://www.digikey.com/products/en?keywords=BSN20-7DICT-ND).

 

Of course I can't promise that any of the following is applicable in general, but at least for my parts it seems to work...:

 

My parts have the codes "N20" and "E9" on them.  Doing a quick Google search for the package type (SOT-23) and the label on the part (N20) - i.e., "SOT-23 N20" - turns up this page:  http://www.s-manuals.com/smd/n2.  Looking in the table one can see two BSN20s listed, with the associated data sheets.  From the data sheet the "E9" is a date code, so it looks like my parts were made in September 2017 (which seems reasonable).

 

If you search for "SOT-23 J1" you'll see this page:  http://www.s-manuals.com/smd/j1.  Looking in the table you'll see lots of SOT-23 J1 devices.  Assuming that your part is in fact actually an N-Channel MOSFET, there are two entries for BSS138s...so that might be the part you have.  You may want to download the datasheet (http://www.s-manuals.com/pdf/datasheet/b/s/bss138_taitron.pdf) and compare the part specs with a standard BSN20 datasheet (e.g., mine is https://www.diodes.com/assets/Datasheets/ds31898.pdf) to determine if it might work okay...?

 

BSN20-H5.jpg.c390d28dee82e6fef00c729a0b8eef30.jpg

Link to comment
Share on other sites

18 hours ago, km1kze said:

You can also see a J1 marking on the original mosfet from the orange pi zero H2+

https://www.toysforscience.com/wp-content/uploads/2017/08/1482138186-1.jpg

 

Ah interesting! Thanks for pointing that out. That's a bit reassuring.

 

10 hours ago, 5kft said:

 

Decoding SMD part codes can be an interesting exercise :huh:  Unfortunately my AliExpress order for these parts had an issue and was never delivered.  I ended up ordering a set of BSN20s from Digi-Key in the U.S. (https://www.digikey.com/products/en?keywords=BSN20-7DICT-ND).

 

Of course I can't promise that any of the following is applicable in general, but at least for my parts it seems to work...:

 

My parts have the codes "N20" and "E9" on them.  Doing a quick Google search for the package type (SOT-23) and the label on the part (N20) - i.e., "SOT-23 N20" - turns up this page:  http://www.s-manuals.com/smd/n2.  Looking in the table one can see two BSN20s listed, with the associated data sheets.  From the data sheet the "E9" is a date code, so it looks like my parts were made in September 2017 (which seems reasonable).

 

If you search for "SOT-23 J1" you'll see this page:  http://www.s-manuals.com/smd/j1.  Looking in the table you'll see lots of SOT-23 J1 devices.  Assuming that your part is in fact actually an N-Channel MOSFET, there are two entries for BSS138s...so that might be the part you have.  You may want to download the datasheet (http://www.s-manuals.com/pdf/datasheet/b/s/bss138_taitron.pdf) and compare the part specs with a standard BSN20 datasheet (e.g., mine is https://www.diodes.com/assets/Datasheets/ds31898.pdf) to determine if it might work okay...?

 

BSN20-H5.jpg.c390d28dee82e6fef00c729a0b8eef30.jpg

 

Hi 5kft,

I did stumble across this site and datasheet when trying to find info about the component. Comparing the two datasheets it seems that the BSS138 has somewhat higher source-drain on resistances and a slightly higher threshold min. rating (0.1 V difference). I might try it and see what happens, just hope my solder isn't too thick for SOT23 soldering.

 

Thanks guys.

 

 

Link to comment
Share on other sites

Hello 5kft, 

I have Orange Pi Zero Plus and I have the same problem with CPU. Freq is stilll on 816 MHz. I have used your patch and compile a new image throught Armbian building, but it was adding me only 240 MHz and 648 MHz and not any FQ above 816 MHz. Can I use your patch on Orange Pi Zero Plus or I need other one? I was soldered BSN20 MOSFET on the right place and nothing happend...  
Thank you for your time.

Link to comment
Share on other sites

3 hours ago, szachar said:

Hello 5kft, 

I have Orange Pi Zero Plus and I have the same problem with CPU. Freq is stilll on 816 MHz. I have used your patch and compile a new image throught Armbian building, but it was adding me only 240 MHz and 648 MHz and not any FQ above 816 MHz. Can I use your patch on Orange Pi Zero Plus or I need other one? I was soldered BSN20 MOSFET on the right place and nothing happend...  
Thank you for your time.

 

By default the OPi Zero Plus is missing the necessary 1.3v regulator entry in the DT.  Did you successfully apply this patch to enable it?  https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/sunxi-next-h5-orangepi-zero-plus-add-regulator.patch

 

Link to comment
Share on other sites

8 hours ago, szachar said:

Hello 5kft, 

I have apply your patch for 1.3V regulator and OPI board running absolutely perfect. Very good job!!! thank you very much for your for help :)

 

Wonderful - I'm glad to hear this! :)

Link to comment
Share on other sites

On 7/10/2018 at 12:51 AM, 5kft said:

By default the OPi Zero Plus is missing the necessary 1.3v regulator entry in the DT.  Did you successfully apply this patch to enable it?  https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/sunxi-next-h5-orangepi-zero-plus-add-regulator.patch

Hi. The patch doesnt available. Is this correct?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines