guidol Posted June 7, 2018 Posted June 7, 2018 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.
5kft Posted June 7, 2018 Author Posted June 7, 2018 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 ) 1
guidol Posted June 7, 2018 Posted June 7, 2018 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 ]---
5kft Posted June 7, 2018 Author Posted June 7, 2018 (edited) 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 June 7, 2018 by 5kft (edited to provide more detail) 2
guidol Posted June 7, 2018 Posted June 7, 2018 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?
5kft Posted June 7, 2018 Author Posted June 7, 2018 Just now, guidol said: for analog audio via the expansion board I think I should leave the mixer0-block in working order? Probably - it's worth a try!
guidol Posted June 7, 2018 Posted June 7, 2018 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.
5kft Posted June 7, 2018 Author Posted June 7, 2018 4 minutes ago, guidol said: I disabled hdmi & sound_hdmi but not mixer0 and now reboot is working Awesome! Glad to hear this
rusatch Posted June 7, 2018 Posted June 7, 2018 11 hours ago, guidol said: I did freeze my kernel May be you need freeze also package like linux-dtb-next-sunxi64 because dtb-files with hardware table exactly in this package.
guidol Posted June 8, 2018 Posted June 8, 2018 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
km1kze Posted June 11, 2018 Posted June 11, 2018 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?
guidol Posted June 11, 2018 Posted June 11, 2018 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
5kft Posted June 11, 2018 Author Posted June 11, 2018 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.
km1kze Posted June 12, 2018 Posted June 12, 2018 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?
zador.blood.stained Posted June 12, 2018 Posted June 12, 2018 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).
martinayotte Posted June 12, 2018 Posted June 12, 2018 "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 1
rusatch Posted June 13, 2018 Posted June 13, 2018 @5kft, @guidol patch with enabling onboard leds accepted green led working as power, red as mmc0 activities(enabled as default, brightness on maximum).
Igor Posted June 13, 2018 Posted June 13, 2018 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.
rusatch Posted June 13, 2018 Posted June 13, 2018 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.
guidol Posted June 14, 2018 Posted June 14, 2018 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
teenytinycactus Posted June 21, 2018 Posted June 21, 2018 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.
km1kze Posted June 21, 2018 Posted June 21, 2018 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 1
teenytinycactus Posted June 21, 2018 Posted June 21, 2018 1 minute ago, km1kze said: Don't remember what was written on them, but if you bought from my link, they're good I do trust you, I am perhaps a bit concerned I was sent the wrong model.
5kft Posted June 21, 2018 Author Posted June 21, 2018 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 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...? 1
teenytinycactus Posted June 22, 2018 Posted June 22, 2018 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 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...? 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.
szachar Posted July 9, 2018 Posted July 9, 2018 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.
5kft Posted July 9, 2018 Author Posted July 9, 2018 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 1
szachar Posted July 10, 2018 Posted July 10, 2018 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
5kft Posted July 11, 2018 Author Posted July 11, 2018 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!
rusatch Posted July 29, 2018 Posted July 29, 2018 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?
Recommended Posts