Orangepi 3 h6 allwiner chip


Recommended Posts

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

Link to post
Share on other sites
Donate and support the project!

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.

Link to post
Share on other sites
On 24.05.2020 at 15:30, maxpyeha said:

Пожалуйста, объясните, как я могу выводить видео через RCA (аудио выход и AV на плате)?

Видимо, для Armbian (и Ubuntu) RCA не включен, я пробовал специальный "родной" кабель с 4-х контактным джеком.  Это прекрасно работает для Android. Поэтому причина неисправности точно в Armbian. Буду искать...

Link to post
Share on other sites

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

 

 

Link to post
Share on other sites
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!

 

 

Link to post
Share on other sites
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.

 

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

 

Link to post
Share on other sites

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

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

 

 

Link to post
Share on other sites

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.

Link to post
Share on other sites
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 by Francisco
Link to post
Share on other sites
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).

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...