dziobak Posted May 5, 2020 Posted May 5, 2020 Igor, I checked config (diffs) already but see nothing directly about USB. So, I think there is maybe some indirectly conneted to USB, but this is above my knowledge. Weird thing, but 100% repeatable. Also, when JMicron controllers are not detected, lsusb shows this values (port 1 and 3 with JMicron controllers) on 3.1 Genesys Logic Hub: Hub Port Status: Port 1: 0040.02c0 lowspeed Port 2: 0000.0203 lowspeed enable connect Port 3: 0000.02e0 lowspeed When detected OK, there is: Hub Port Status: Port 1: 0000.0203 lowspeed enable connect Port 2: 0000.0203 lowspeed enable connect Port 3: 0000.0203 lowspeed enable connect Don't know what that status means. Empty port has 0000.02a0 0 Quote
Виктор Васильевич Posted May 20, 2020 Posted May 20, 2020 On 30.03.2019 at 23:45, NicoD said: Может кто-нибудь еще проверить напряжение на USB, пожалуйста? Я вижу очень низкое напряжение от 4,5 В до 4 В максимально. Я использую кабель OPi и блок питания 4A от моего NanoPi M4. Я хотел бы знать, если это моя установка. Спасибо. PS При более высоком входном напряжении 5,3 В (против 5,1 В) у меня 4,75 В на холостом ходу и 4,5 В на максимуме. Orange Pi developers do not recommend using USB-OTG to power the board, too thin conductors. Moreover, there are current limits from the USB host. This is all in the documentation. 0 Quote
maxpyeha Posted May 24, 2020 Posted May 24, 2020 Please explain how can I output video via RCA (audio output and AV on the board)? 0 Quote
Виктор Васильевич Posted May 26, 2020 Posted May 26, 2020 On 24.05.2020 at 15:30, maxpyeha said: Пожалуйста, объясните, как я могу выводить видео через RCA (аудио выход и AV на плате)? Видимо, для Armbian (и Ubuntu) RCA не включен, я пробовал специальный "родной" кабель с 4-х контактным джеком. Это прекрасно работает для Android. Поэтому причина неисправности точно в Armbian. Буду искать... 0 Quote
dolphs Posted May 27, 2020 Posted May 27, 2020 Hi - Was wondering about the throttling issue encountered, also on H3/ H5 boards? Is there a fix meanwhile, also for the H6 boards or do we need to wait till kernel 5.8 has been completed ( DVFS aka Dynamic voltage and frequency scaling) ? Suppose @5kft knows more about this one? It is just a question and dont push my OPiOnePlus board to the limit, also because of conservative governor setting - works fine also on this H6 board - for wireguard ( just like my fav boards NEO2 Black ) purposes 0 Quote
5kft Posted May 27, 2020 Posted May 27, 2020 4 hours ago, dolphs said: Is there a fix meanwhile, also for the H6 boards or do we need to wait till kernel 5.8 has been completed ( DVFS aka Dynamic voltage and frequency scaling) ? Suppose @5kft knows more about this one? Unfortunately I don't have any H6 boards, so I've never looked into this for the H6... However I just took a quick look at the DT include "sun50i-h6.dtsi" (in ".../arch/arm64/boot/dts/allwinner/") and it appears to be missing the same thermal-zones definitions as needed for the H3 and H5 to throttle down: thermal-zones { cpu-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 0>; trips { cpu_hot_trip: cpu-hot { temperature = <80000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot_trip: cpu-very-hot { temperature = <100000>; hysteresis = <0>; type = "critical"; }; }; cooling-maps { cpu-hot-limit { trip = <&cpu_hot_trip>; cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; If someone were to want look into this, I would suggest creating a patch containing the appropriate changes like I did for the H5 and see if it works for the H6 (at least if I had an H6 I would try this first...) E.g., see https://github.com/armbian/build/blob/master/patch/kernel/sunxi-current/update-correct-h3-h5-thermal-zones.patch. I hope this helps! 0 Quote
Werner Posted May 27, 2020 Posted May 27, 2020 4 minutes ago, 5kft said: If someone were to want look into this I have an OPi1+ but I am not very good at writing patches. If you provide the changes the way you think they should work I'll test them. 0 Quote
5kft Posted May 28, 2020 Posted May 28, 2020 9 hours ago, Werner said: I have an OPi1+ but I am not very good at writing patches. If you provide the changes the way you think they should work I'll test them. 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. 1 Quote
Werner Posted May 28, 2020 Posted May 28, 2020 6 hours ago, 5kft said: 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. Will do. Also thanks for the testing instructions. Building right now.... Edit: Had some issues with the first sd card. The board behaviour was strange. The 2nd one works though. Above 80*C 1320MHz above 75*C 1488MHz above 70*C 1632MHz. I could barely push it over 80°C so no clue what happens above. Need someone else to test. Mine has a heatsink glued on. 0 Quote
5kft Posted May 28, 2020 Posted May 28, 2020 8 hours ago, Werner said: Above 80*C 1320MHz above 75*C 1488MHz above 70*C 1632MHz. I could barely push it over 80°C so no clue what happens above. Need someone else to test. Mine has a heatsink glued on. @Werner - thanks! Great news - it looks like it is working! For comparison, would it be possible for you to test this without these changes and see how it goes? That could help inform as to whether these changes should be checked in as-is. 0 Quote
Werner Posted May 28, 2020 Posted May 28, 2020 Without your patch the behavior is different. Clocks down to 1488MHz at 80*C However there is also a thermal_zone0 root@orangepioneplus:/sys/class/thermal/thermal_zone0# ls available_policies k_d policy trip_point_0_hyst type cdev0 k_i power trip_point_0_temp uevent cdev0_trip_point k_po slope trip_point_0_type cdev0_weight k_pu subsystem trip_point_1_hyst emul_temp mode sustainable_power trip_point_1_temp integral_cutoff offset temp trip_point_1_type for i in trip*; do echo $i; cat $i; done trip_point_0_hyst 2000 trip_point_0_temp 80000 trip_point_0_type passive trip_point_1_hyst 0 trip_point_1_temp 100000 trip_point_1_type critical 0 Quote
Igor Posted May 28, 2020 Posted May 28, 2020 17 hours ago, 5kft said: I can make a PR for this change All three H6 devices in the rig survived. https://dl.armbian.com/_test-reports/2020-05-28_16.47.30.html Push it. 0 Quote
5kft Posted May 29, 2020 Posted May 29, 2020 6 hours ago, Igor said: All three H6 devices in the rig survived. https://dl.armbian.com/_test-reports/2020-05-28_16.47.30.html Push it. 6 hours ago, Werner said: Do dev branch as well Done and done https://armbian.atlassian.net/browse/AR-285 Thanks for doing the testing! 1 Quote
dolphs Posted May 29, 2020 Posted May 29, 2020 wow this looks very interesting, thanks so much @5kft, @Werner, @Igor for the ultra fast follow up. Now I wonder what the mainling effort planned in addition to this in kernel 5.8 ? Will flash my spare OpiOnePlus today or tomorrow, thanks again! 0 Quote
Werner Posted May 29, 2020 Posted May 29, 2020 We will see. I hope @martinayotte wants to start looking at 5.7 as soon as it is released (or already has ) and megi pushed the branch to stable as well. Will be helpful I hope to sort things out. 0 Quote
martinayotte Posted May 29, 2020 Posted May 29, 2020 4 hours ago, Werner said: I hope @martinayotte wants to start looking at 5.7 I will start working on that soon ... 1 Quote
Francisco Posted June 23, 2020 Posted June 23, 2020 Hi! Not sure if this is the right place to post this, but... I just bought 10 Orange Pi 3 and none has a regular functioning ethernet. The LEDs go on as expected, the graphic network setup tool shows a DHCP address for a second (or even less) then it goes away, along with the LEDs. After a few seconds, the cycle comes on again and again. Do I have a bad lot? I've tried almost all available images, including the android that came in the ESSD memory, they all had the same behaviour. Thanks! Francisco 0 Quote
Werner Posted June 23, 2020 Posted June 23, 2020 4 hours ago, Francisco said: Hi! Not sure if this is the right place to post this, but... I just bought 10 Orange Pi 3 and none has a regular functioning ethernet. The LEDs go on as expected, the graphic network setup tool shows a DHCP address for a second (or even less) then it goes away, along with the LEDs. After a few seconds, the cycle comes on again and again. Do I have a bad lot? I've tried almost all available images, including the android that came in the ESSD memory, they all had the same behaviour. Thanks! Francisco Ethernet on all H6 boards should work as expected. Connect an USB serial adapter to get an idea what is happening inside. 0 Quote
Igor Posted June 23, 2020 Posted June 23, 2020 4 hours ago, Francisco said: I've tried almost all available images For Armbian, you need to test one image and without logs its hard to diagnose. armbianmonitor -u I also made our performance / stress test and there are no anomalies: https://dl.armbian.com/_test-reports/2020-06-23_06.42.28.html 0 Quote
Виктор Васильевич Posted June 23, 2020 Posted June 23, 2020 6 hours ago, Francisco said: Hi! Not sure if this is the right place to post this, but... I just bought 10 Orange Pi 3 and none has a regular functioning ethernet. The LEDs go on as expected, the graphic network setup tool shows a DHCP address for a second (or even less) then it goes away, along with the LEDs. After a few seconds, the cycle comes on again and again. Do I have a bad lot? I've tried almost all available images, including the android that came in the ESSD memory, they all had the same behaviour. Thanks! Francisco Hi, Francisco! The situation is strange .... I have OPi 3 Opi and Win +. There were no problems with the network. WiFi, Ethernet, BT - everything works like a clock. I can assume that the problem is outside, say, a ban on access to the network. Sincerely, Victor. 0 Quote
Flole Posted June 23, 2020 Posted June 23, 2020 I tried to unload i2c_mv64xxx using modprobe -r command and in dmesg I got [41723.377022] vcc-5v: Underflow of regulator enable count[41723.377036] vcc-5v: Underflow of regulator enable count[41723.377209] ------------[ cut here ]------------[41723.377223] WARNING: CPU: 1 PID: 23070 at drivers/regulator/core.c:5262 regulator_unregister+0xd0/0xd8[41723.377225] Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_mac xt_conntrack iptable_filter xt_MASQUERADE xt_nat iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 tun bridge zram sun4i_i2s snd_soc_simple_card sunxi_cedrus(C) snd_soc_simple_card_utils btsdio brcmfmac ch341 snd_seq_midi brcmutil usbserial snd_seq_midi_event hci_uart cfg80211 snd_rawmidi btqca btrtl btbcm v4l2_mem2mem btintel bluetooth snd_soc_hdmi_codec snd_seq snd_soc_core videobuf2_dma_contig ecdh_generic snd_pcm_dmaengine rfkill videobuf2_memops videobuf2_v4l2 snd_pcm ecc videobuf2_common snd_seq_device dw_hdmi_cec dw_hdmi_i2s_audio videodev snd_timer mc snd panfrost soundcore sun8i_ce gpu_sched cpufreq_dt crypto_engine uas realtek dwmac_sun8i mdio_mux i2c_mv64xxx(-)[41723.377299] CPU: 1 PID: 23070 Comm: modprobe Tainted: G C 5.6.15-sunxi64 #20.05.2[41723.377301] Hardware name: OrangePi 3 (DT)[41723.377304] pstate: 20000005 (nzCv daif -PAN -UAO)[41723.377307] pc : regulator_unregister+0xd0/0xd8[41723.377309] lr : regulator_unregister+0x70/0xd8[41723.377310] sp : ffff8000121fb840[41723.377311] x29: ffff8000121fb840 x28: ffff00007755dcc0 [41723.377314] x27: 0000000000000000 x26: ffff000072673ce0 [41723.377317] x25: 0000000000000000 x24: 000000000000000f [41723.377320] x23: ffff8000121fb8b8 x22: ffff000074c9e500 [41723.377322] x21: ffff800011088908 x20: ffff8000110ecd80 [41723.377325] x19: ffff0000724fa800 x18: ffff8000110a0000 [41723.377327] x17: 0000000000000000 x16: 0000000000000000 [41723.377330] x15: 00000000fffffff0 x14: ffff80001116700a [41723.377333] x13: 0000000000005b38 x12: 0000000000000018 [41723.377336] x11: 0101010101010101 x10: 0000000000000000 [41723.377338] x9 : 0000000000210d00 x8 : 7f7f7f7f7f7f7f7f [41723.377341] x7 : fefefefeff584b4f x6 : 000000000000000f [41723.377343] x5 : 0000000000000000 x4 : 0000000000000000 [41723.377346] x3 : 0000000000000040 x2 : 0000000000000008 [41723.377348] x1 : e97bbefd87894e00 x0 : 0000000000000003 [41723.377352] Call trace:[41723.377355] regulator_unregister+0xd0/0xd8[41723.377360] devm_rdev_release+0x10/0x18[41723.377368] release_nodes+0x1b0/0x220[41723.377371] devres_release_all+0x58/0x1c0[41723.377375] device_release_driver_internal+0x100/0x1c0[41723.377377] device_release_driver+0x14/0x20[41723.377383] bus_remove_device+0xcc/0x150[41723.377386] device_del+0x154/0x398[41723.377389] platform_device_del.part.17+0x18/0x88[41723.377392] platform_device_unregister+0x20/0x38[41723.377397] mfd_remove_devices_fn+0x44/0x58[41723.377400] device_for_each_child_reverse+0x64/0xa8[41723.377402] mfd_remove_devices+0x18/0x20[41723.377406] axp20x_device_remove+0x38/0x140[41723.377408] axp20x_i2c_remove+0x10/0x18[41723.377413] i2c_device_remove+0x54/0xf8[41723.377415] device_release_driver_internal+0xf0/0x1c0[41723.377418] device_release_driver+0x14/0x20[41723.377421] bus_remove_device+0xcc/0x150[41723.377423] device_del+0x154/0x398[41723.377426] device_unregister+0x1c/0x70[41723.377429] i2c_unregister_device.part.28+0x3c/0x58[41723.377432] __unregister_client+0x4c/0x68[41723.377434] device_for_each_child+0x5c/0xa8[41723.377437] i2c_del_adapter+0x180/0x2a0[41723.377443] mv64xxx_i2c_remove+0x18/0x68 [i2c_mv64xxx][41723.377446] platform_drv_remove+0x28/0x48[41723.377448] device_release_driver_internal+0xf0/0x1c0[41723.377451] driver_detach+0x9c/0x160[41723.377454] bus_remove_driver+0x7c/0xe8[41723.377456] driver_unregister+0x2c/0x58[41723.377458] platform_driver_unregister+0x10/0x18[41723.377461] mv64xxx_i2c_driver_exit+0x18/0xb9c [i2c_mv64xxx][41723.377467] __arm64_sys_delete_module+0x140/0x290[41723.377472] el0_svc_common.constprop.2+0x88/0x150[41723.377474] do_el0_svc+0x20/0x80[41723.377479] el0_sync_handler+0x118/0x188[41723.377481] el0_sync+0x140/0x180[41723.377483] ---[ end trace 4677681e1c52e4eb ]---[41723.377945] vcc-5v: Underflow of regulator enable count[41723.378118] ------------[ cut here ]------------ Is this a known problem? And what is that module doing in the first place? At night I see an increased interrupt rate from it and it causes increased CPU usage so I'm wondering what it's for and why unloading it failed/caused an error. I also tried using blacklist option in /etc/modprobe.d/blacklist.cong to prevent this module from loading but no luck with that either. 0 Quote
jernej Posted June 23, 2020 Posted June 23, 2020 You shouldn't unload I2C driver because power regulator (PMIC) is controlled over it. With I2C driver unloading you effectively disable power regulation. 0 Quote
Flole Posted June 23, 2020 Posted June 23, 2020 But it is not "unsafe" to run it in this configuration, right? The regulators are all set now and there shouldn't be any need to change voltages now. Especially they shouldn't be set to an unsafe voltage, right? On the next reboot it'll become active again anyways but since last time I tried a reboot after unloading I got a complete lockup I would prefer to keep it running for 2 more days until I'm physically there again. 0 Quote
jernej Posted June 24, 2020 Posted June 24, 2020 I wouldn't be so sure. However I never researched it so I won't make any claims here. 0 Quote
Francisco Posted June 24, 2020 Posted June 24, 2020 (edited) On 6/23/2020 at 4:13 AM, Igor said: For Armbian, you need to test one image and without logs its hard to diagnose. armbianmonitor -u I also made our performance / stress test and there are no anomalies: https://dl.armbian.com/_test-reports/2020-06-23_06.42.28.html Thank you all for your answers and tips! The wi-fi works as expected, there is no external network restriction, I plug several devices to the same ethernet port (one at a time, of course). I'll try the serial console messages next. Regarding the "armbianmonitor -U", here's the result: https://pastebin.com/3kBFfhUZ I'll try the serial console next. Thanks again, Francisco Edited June 24, 2020 by Francisco 0 Quote
JORGETECH Posted June 29, 2020 Posted June 29, 2020 On 5/24/2020 at 12:30 PM, maxpyeha said: Please explain how can I output video via RCA (audio output and AV on the board)? RCA video output is currently not supported in mainline kernel (for supported hardware features read the table in this page), there was an experimental implementation for H3 boards but it's very outdated and it no longer works. RCA video works on Android images because they use the "legacy" Allwinner kernel (may have security flaws and other issues). 0 Quote
Flole Posted July 6, 2020 Posted July 6, 2020 Is anybody else experiencing stability issues? I have replaced the power supply now and double-checked with an oscilloscope to make sure the voltage is stable even under load. I have stable 5.25V at the USB Ports. I am using an USB HDD as rootfs, is anybody else using this with the system running stable? There are quite some regulator entries in the dmesg, but I think those are normal? Quote [ 34.054604] panfrost 1800000.gpu: failed to get regulator: -517 [ 34.054610] panfrost 1800000.gpu: regulator init failed -517 [ 34.268405] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator [ 34.268414] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102 [ 34.268421] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517 [ 34.269056] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pf not found, using dummy regulator [ 34.270213] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator [ 34.270223] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 96 [ 34.270230] sun50i-h6-pinctrl 300b000.pinctrl: pin-96 (5020000.ethernet) status -517 [ 34.270237] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 96 (PD0) from group PD0 on device 300b000.pinctrl [ 34.270243] dwmac-sun8i 5020000.ethernet: Error applying setting, reverse things back [ 34.270915] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator [ 34.270922] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 65 [ 34.270930] sun50i-h6-pinctrl 300b000.pinctrl: pin-65 (4022000.mmc) status -517 [ 34.270937] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1 on device 300b000.pinctrl [ 34.270942] sunxi-mmc 4022000.mmc: Error applying setting, reverse things back [ 34.271194] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator [ 34.271201] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 79 [ 34.271207] sun50i-h6-pinctrl 300b000.pinctrl: pin-79 (300b000.pinctrl:79) status -517 I tried to enable the watchdog but that doesn't fix the lockups. My HDDs LED goes off when that lockup happens, the Ethernet LEDs stay on but it doesn't respond anymore at all, just as if the CPU would hang. In that case the watchdog should kick in though, so I am not sure what is going on there. If anybody has an idea what's going on here I would appreciate any help. 0 Quote
Werner Posted July 6, 2020 Posted July 6, 2020 Quote panfrost 1800000.gpu: regulator init failed -517 For that one you can try to fix the gpu to a specific clock. Somewhere in the forums I wrote how to do that. 0 Quote
Flole Posted July 6, 2020 Posted July 6, 2020 I assume there is no way to just disable the GPU completely? I don't need it at all, so if there is a way to disable it I would give that a try. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.