orangepizero2w board, ethernet PHY likely not powered

[alexl83]

What happened?

dear @chraac, I'm testing orangepizero2w builds and it seems that ethernet PHY is not getting powered, output dmesg:

[    2.119267] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
[    2.119296] dwmac-sun8i 5020000.ethernet: IRQ eth_lpi not found
[    2.119502] dwmac-sun8i 5020000.ethernet: supply phy-io not found, using dummy regulator
[    2.119726] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[    2.119757] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 0)
[    2.139330] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
[    2.139363] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
[    2.139371] dwmac-sun8i 5020000.ethernet: COE Type 2
[    2.139379] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
[    2.139387] dwmac-sun8i 5020000.ethernet: Normal descriptors
[    2.139395] dwmac-sun8i 5020000.ethernet: Chain mode enabled
[    2.139415] dwmac-sun8i 5020000.ethernet: device MAC address da:90:21:c8:74:0c
[    2.300160] dwmac-sun8i 5020000.ethernet: EMAC reset timeout
[    2.300192] dwmac-sun8i 5020000.ethernet eth0: stmmac_dvr_remove: removing driver
[    2.316507] dwmac-sun8i: probe of 5020000.ethernet failed with error -110

reference info link: https://linux-sunxi.org/Sun8i_emac

I came accross a possible kernel patch I cannot evaluate relevancy for: https://github.com/jernejsk/linux-1/commit/25b44143ea8162209beb02759ca3ea3bd3be7a74

Ultimately, device tree shipped in this PR seems not to specify any phy-supply = <&reg_dldo1>; (if needed)

Hope it helps, will file a bug too Thanks 🙏🏻

How to reproduce?

boot an orangepizero2w build

Branch

main (main development branch)

On which host OS are you running the build script and observing this problem?

Ubuntu 22.04 Jammy

Are you building on Windows WSL2?

• [ ] Yes, my Ubuntu/Debian/OtherOS is running on WSL2

Relevant log URL

https://paste.armbian.com/ayuwafutul

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[github-actions[bot]]

Jira ticket: AR-2127

[igorpecovnik]

Please do not open HW related issues to build framework tracker. https://github.com/armbian/build/issues/new/choose guides you to right place.

[alexl83]

@chraac perhaps even if closed we can use this issue to track progess - shouldn't be bothering anyone hopefulkly :)

[alexl83]

@chraac tested your fix it boots but never drops me to a shell it continuously tries to start and stop sshd Also ethernet leds doesn't come to life

I don't have an rs-232 to usb serial handy, will try to connect console through another SBC uart in the meantime I think (gut feeling) that the recipe is likely right, but missing one ingredient perhaps: in the device tre dtb, I assume that ethernet@5030000 is the one supposed to work with SUNXI-GMAC, so phy should be declared there

HEre's a snippet from xunlong's dtb

&emac1 {
    pinctrl-names = "default";
    pinctrl-0 = <&rmii_pins>;
    phy-mode = "rmii";
    phy-handle = <&rmii_phy>;
    phy-supply = <&reg_dldo1>;
    allwinner,rx-delay-ps = <3100>;
    allwinner,tx-delay-ps = <700>;
    status = "okay";
};

&mdio1 {
    rmii_phy: ethernet-phy@1 {
        compatible = "ethernet-phy-ieee802.3-c22";
        reg = <1>;
    };
};

[chraac]

@chraac tested your fix it boots but never drops me to a shell it continuously tries to start and stop sshd Also ethernet leds doesn't come to life

I don't have an rs-232 to usb serial handy, will try to connect console through another SBC uart in the meantime I think (gut feeling) that the recipe is likely right, but missing one ingredient perhaps: in the device tre dtb, I assume that ethernet@5030000 is the one supposed to work with SUNXI-GMAC, so phy should be declared there

HEre's a snippet from xunlong's dtb

&emac1 {
  pinctrl-names = "default";
  pinctrl-0 = <&rmii_pins>;
  phy-mode = "rmii";
  phy-handle = <&rmii_phy>;
  phy-supply = <&reg_dldo1>;
  allwinner,rx-delay-ps = <3100>;
  allwinner,tx-delay-ps = <700>;
  status = "okay";
};

&mdio1 {
  rmii_phy: ethernet-phy@1 {
      compatible = "ethernet-phy-ieee802.3-c22";
      reg = <1>;
  };
};

Yeah, those confg were already applied in my patch, maybe we should connet to debug uart to see what happened here

[alexl83]

Ok, will try but I'm not really good at soldering Seems opi02w need some for the pinheader

No promises, I'll try and report back

[chraac]

Ok, will try but I'm not really good at soldering Seems opi02w need some for the pinheader

No promises, I'll try and report back

Thanks, looks only those 3 pin are necessary: UART0_TX, UART0_RX and GND You can leave other pin open if afraid of short-circuiting though.

[chraac]

@alexl83 , ran the new image on my sbc, got those stacktrack:

[   18.667236] Unable to handle kernel paging request at virtual address fffffffffffffff0
[   18.675266] Mem abort info:
[   18.678122]   ESR = 0x0000000096000004
[   18.681890]   EC = 0x25: DABT (current EL), IL = 32 bits
[   18.687227]   SET = 0, FnV = 0
[   18.690296]   EA = 0, S1PTW = 0
[   18.693480]   FSC = 0x04: level 0 translation fault
[   18.698427] Data abort info:
[   18.701355]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[   18.706863]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   18.711949]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   18.717279] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000413e5000
[   18.724012] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000000000000
[   18.730831] Internal error: Oops: 0000000096000004 [#1] SMP
[   18.736407] Modules linked in: hci_uart btqca btrtl btintel btbcm bluetooth ecdh_generic ecc sprdwl_ng sunxi_addr cfg80211 lz4hc lz4 zram snd_usb_audio snd_hwdep polyval_ce snd_usbmidi_lib uvcvideo snd_soc_hdmi_codec binfmt_misc snd_rawmidi polyval_generic snd_seq_device sunxi_cedrus(C) sunxi_cir rc_core videobuf2_vmalloc uvc v4l2_mem2mem videobuf2_dma_contig dw_hdmi_i2s_audio dw_hdmi_cec videobuf2_memops videobuf2_v4l2 videodev videobuf2_common dump_reg mc display_connector cpufreq_dt sprdbt_tty uwe5622_bsp_sdio rfkill fuse dm_mod ac200
[   18.784077] CPU: 3 PID: 1407 Comm: NetworkManager Tainted: G         C         6.6.30-current-sunxi64 #40
[   18.793636] Hardware name: OrangePi Zero 2W (DT)
[   18.798249] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   18.805207] pc : geth_open+0xc8/0x490
[   18.808877] lr : geth_open+0xb4/0x490
[   18.812538] sp : ffff800082f4b500
[   18.815849] x29: ffff800082f4b500 x28: ffff800080f49658 x27: 0000000000000000
[   18.822983] x26: 0000000000000001 x25: 0000000000000000 x24: ffff00000272c268
[   18.830116] x23: 0000000000001002 x22: 00000000ffffffea x21: ffff8000815ee8d8
[   18.837250] x20: ffff00000272c000 x19: ffff00000272c9c0 x18: 0000000000000000
[   18.844384] x17: 0000000000000000 x16: 0000000000000000 x15: ffff000009906090
[   18.851517] x14: 0000000000001000 x13: ffff800082fb7000 x12: ffff8000812c1d58
[   18.858651] x11: ffff8000812c1d58 x10: 0000000000000000 x9 : 0000000000000000
[   18.865784] x8 : ffff800082fb6000 x7 : 0000000000000000 x6 : 000000000000003f
[   18.872918] x5 : 0000000000000040 x4 : 0000000000000000 x3 : 0000000000000000
[   18.880051] x2 : 0000000000000000 x1 : ffff0000061f2a00 x0 : fffffffffffffff0
[   18.887185] Call trace:
[   18.889630]  geth_open+0xc8/0x490
[   18.892945]  __dev_open+0xfc/0x1e0
[   18.896354]  __dev_change_flags+0x1e8/0x2b8
[   18.900536]  dev_change_flags+0x24/0x6c
[   18.904370]  do_setlink+0x220/0xe20
[   18.907862]  __rtnl_newlink+0x494/0x8c0
[   18.911697]  rtnl_newlink+0x50/0x7c
[   18.915184]  rtnetlink_rcv_msg+0x2b0/0x384
[   18.919280]  netlink_rcv_skb+0x5c/0x128
[   18.923116]  rtnetlink_rcv+0x18/0x24
[   18.926692]  netlink_unicast+0x2c0/0x328
[   18.930613]  netlink_sendmsg+0x1d4/0x440
[   18.934534]  __sock_sendmsg+0x54/0x60
[   18.938196]  ____sys_sendmsg+0x27c/0x2e0
[   18.942116]  ___sys_sendmsg+0x80/0xdc
[   18.945779]  __sys_sendmsg+0x68/0xc4
[   18.949353]  __arm64_sys_sendmsg+0x24/0x30
[   18.953447]  invoke_syscall+0x48/0x118
[   18.957200]  el0_svc_common.constprop.0+0x40/0xe8
[   18.961904]  do_el0_svc+0x20/0x2c
[   18.965219]  el0_svc+0x40/0xf4
[   18.968276]  el0t_64_sync_handler+0x13c/0x158
[   18.972633]  el0t_64_sync+0x190/0x194
[   18.976299] Code: b4001d00 d280ffe0 f9001660 f941b260 (b9400000)
[   18.982388] ---[ end trace 0000000000000000 ]---

it in geth_open, gonna enable debug info to get more details

[alexl83]

Thanks @chraac I'm traveling right now so won't be able to check for at least a couple days As soon as I'm back I'm gonna solder a pinheader (wish me luck) and connect it to an rPI0 uart to get debug from serial and share

Thanks a lot for your precious support! Also guys from dietPI are having a look at this topic Hopefully it'll benefit everyone :)

[igorpecovnik]

Hopefully it'll benefit everyone :)

This is something you don't need to worry about. I think you need to rephrase this hope ;)

FOSS world is special. Average Joe, even long time Linux user, have many troubles to see and understand, who is taking value from whom, who is doing the actual work and who is benefiting. Open source world is a perfect ground for abuse to develop. There is a dark side, which many people that makes value, has to deal with.

In past ten years there was very little, close to zero benefits from Dietpi towards open source or Armbian. They have no problems with that as their aim is not everyone benefit. Its their benefits.

Dietpi (also Orangepi, Manjaro, ... to name a few from axis powers) sell our (and others) work under their name and provides nothing in return. They are those who benefit, others don't, as they are not involved in covering any common costs whatsoever - costs are essential, not if benefits of Armbian will be shared with (Dietpi / other) users. This value is shared automatically almost since the day one. Most of their users don't know that we are behind almost all value that is sold to you by Dietpi guy. You don't need to worry if benefits of this PR will get there. It always does, while nothing ever comes back. That is a problem.

I have asked Dietpi years ago to contribute for costs of our infrastructure as I didn't expect they will understand how they abuse and steal our intellectual property. It was ofc ignored as this is the core of their work, while on other hand they complain how we don't work with (its always for) them. Sadly they do nothing of valuable to us or open source and they are also not in position to dictate what our primary and professional support team will do. Actually nobody is, especially not those that adds no value or worse, make damages.

All they they were doing for past years was (semi auto) converting images from Armbian towards Dietpi (=armbian/debian + bash application installer and bloatware bash scripts which are their work) and "supporting" them. If problem was found - "this is Armbian fault", when users cheered "their work", they took compliment as it was for them. This is how open source intellectual property is getting stolen ... not a problem if this happens here and there, problem becomes when its industrialised.

They are openly competing and comparing themselves with Armbian. Which is generally O.K., if it would be done honest way, but its pure propaganda. There is an "article" on their entry page saying how Armbian is trash and Dietpi is cool. Its there for many years even its a complete fabrication and we pointed that out. It was ignored too.

When dietpi users comes to them about problems, they usually demand from their narcissistic perspective from projects they re-sell, to fix problems for their users ... I understand users are happy when someone blackmail open source developers instead of them. Since all open source software is released under "best effort support principle" and since most of this work is done for free, there is zero tolerance allowing Dietpi to mock developers of this community.

Orangepi provides Debian and Ubuntu images. Which are some done with slightly modified Armbian build framework, where they run search for "Armbian" replace with "Orangepi". Initially they also removed and replaced our (c) from source code ... This tells something about their attitude, not if we have something from this or not. Users never read who is author of the code ... software has to work and Orangepi provides them (our) good working system without supporting our work. Again not everyone is benefiting. Only some :(

There are many topics on forums related to "business" problems in open source, not just by me. We have to be careful not to allow bad guys to win. That's it. If they are winning, only them are benefiting.

[alexl83]

@igorpecovnik I see where you're coming from, and I agree on the viewpoint

It's not difficult to see how this project is being a prey of your team's work by plagiarism I'm sorry I didn't phrase my thoughts clearly - When I was referring to benefitting everyone I was thinking about end consumers, like me and perhaps most "fanatics" of SBCs and Linux/FOSS

I've seldom encountered a good and nice community, a valuable learning curve and the will to create something like armbian, surpassing industry standard for result while keeping it simple for the average Linux guy

I recently ended up buying some orangepi boards: while hardware is decent if not overly good, software support is not there, and hardware alone cannot compensate for it

I came to know Armbian because of xunlong's half-assed approach at stealing and rebranding Armbian's former framework, while giving back to the community just the headaches of mainlining Allwinner crappy code.

I might be living under a rock, but it seems to me that stealing instead of collaborating is not useful, nevertheless companies keep going for fast/easy money I see - again, sorry if I gave the wrong impression, before Armbian I knew just raspberry pi's distribution and nothing more

Actually Armbian is far superior and it's a real pity it's being plundered instead of supported in the way it should be. I'm pretty sure every benefit will come from here and spread along while not necessarily being "reciprocated", and that's a real problem, I fully agree

I didn't know about backstage relationships, but I got from the start a gut feeling that Armbian was (is) the "cauldron" of ideas and efforts. Now that we talk about this, I''m sure of it

Good (and bad) about FOSS is that it's done by people, so it's in people's hands to do something good in sustainable ways I'll keep contributing to your work as much as my skillset allows

Thank you for sharing, for your patience, devotion and support! :)

[chraac]

Added the sunxi-ephy driver, now looks like the gmac init successfully, and we can see the eth0 was created successfully:

Didn't test yet, but from the dmesg looks like its worked:

@alexl83 maybe you can try to pull the latest dev-zero2w-fix-eth on my fork and test on sbc again......

[alexl83]

Hi @chraac - back from my travel and from an unexpected dental surgery - I'm fine but my wallet got a punch!

Just pulled your updated branch, compiled and booted, it works! I feel stupid as I can't find my minihdmi adapter, but here's some armbianmonitor -u

and dmesg: [ 15.886790] unisoc_wifi unisoc_wifi wlan0: mixed HW and IP checksum settings. [ 16.344952] Bluetooth: Core ver 2.22 [ 16.345097] NET: Registered PF_BLUETOOTH protocol family [ 16.345102] Bluetooth: HCI device and connection manager initialized [ 16.345122] Bluetooth: HCI socket layer initialized [ 16.345130] Bluetooth: L2CAP socket layer initialized [ 16.345144] Bluetooth: SCO socket layer initialized [ 16.489696] Bluetooth: HCI UART driver ver 2.3 [ 16.489724] Bluetooth: HCI UART protocol H4 registered [ 16.489729] Bluetooth: HCI UART protocol BCSP registered [ 16.489820] Bluetooth: HCI UART protocol LL registered [ 16.489825] Bluetooth: HCI UART protocol ATH3K registered [ 16.489853] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 16.490043] Bluetooth: HCI UART protocol Intel registered [ 16.490119] Bluetooth: HCI UART protocol Broadcom registered [ 16.490146] Bluetooth: HCI UART protocol QCA registered [ 16.490151] Bluetooth: HCI UART protocol AG6XX registered [ 16.490177] Bluetooth: HCI UART protocol Marvell registered [ 17.488132] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 17.488180] Bluetooth: BNEP filters: protocol multicast [ 17.488199] Bluetooth: BNEP socket layer initialized [ 17.493714] Bluetooth: MGMT ver 1.22 [ 17.528987] NET: Registered PF_ALG protocol family [ 18.665548] sunxi-gmac 5030000.ethernet eth0: No PHY found! [ 18.667398] sunxi-gmac 5030000.ethernet eth0: phy init again... [ 20.087252] sunxi-gmac 5030000.ethernet eth0: eth0: Type(7) PHY ID 00441400 at 0 IRQ poll (5030000.ethernet-0:00) [ 23.172390] sunxi-gmac 5030000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off

You're a genius, thanks! I'm going to test more in the next few days :)

[chraac]

Hi @chraac - back from my travel and from an unexpected dental surgery - I'm fine but my wallet got a punch!

Just pulled your updated branch, compiled and booted, it works! I feel stupid as I can't find my minihdmi adapter, but here's some armbianmonitor -u

and dmesg: [ 15.886790] unisoc_wifi unisoc_wifi wlan0: mixed HW and IP checksum settings. [ 16.344952] Bluetooth: Core ver 2.22 [ 16.345097] NET: Registered PF_BLUETOOTH protocol family [ 16.345102] Bluetooth: HCI device and connection manager initialized [ 16.345122] Bluetooth: HCI socket layer initialized [ 16.345130] Bluetooth: L2CAP socket layer initialized [ 16.345144] Bluetooth: SCO socket layer initialized [ 16.489696] Bluetooth: HCI UART driver ver 2.3 [ 16.489724] Bluetooth: HCI UART protocol H4 registered [ 16.489729] Bluetooth: HCI UART protocol BCSP registered [ 16.489820] Bluetooth: HCI UART protocol LL registered [ 16.489825] Bluetooth: HCI UART protocol ATH3K registered [ 16.489853] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 16.490043] Bluetooth: HCI UART protocol Intel registered [ 16.490119] Bluetooth: HCI UART protocol Broadcom registered [ 16.490146] Bluetooth: HCI UART protocol QCA registered [ 16.490151] Bluetooth: HCI UART protocol AG6XX registered [ 16.490177] Bluetooth: HCI UART protocol Marvell registered [ 17.488132] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 17.488180] Bluetooth: BNEP filters: protocol multicast [ 17.488199] Bluetooth: BNEP socket layer initialized [ 17.493714] Bluetooth: MGMT ver 1.22 [ 17.528987] NET: Registered PF_ALG protocol family [ 18.665548] sunxi-gmac 5030000.ethernet eth0: No PHY found! [ 18.667398] sunxi-gmac 5030000.ethernet eth0: phy init again... [ 20.087252] sunxi-gmac 5030000.ethernet eth0: eth0: Type(7) PHY ID 00441400 at 0 IRQ poll (5030000.ethernet-0:00) [ 23.172390] sunxi-gmac 5030000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off

You're a genius, thanks! I'm going to test more in the next few days :)

You're welcome, initially, plan to use the ac200 phy driver in mainline kernel, but the stacktrace related to the phy initialization, so opted to switch to the sunxi-ephy.

[alexl83]

I saw that their ephy pulled a lot of stuff from sunxi AC200.h, which mainline version lacked, perhaps mainline it's cleaner and simplified Nevertheless, it's working solid - what would be the next step, mergin in armbian main for this board?

[chraac]

I saw that their ephy pulled a lot of stuff from sunxi AC200.h, which mainline version lacked, perhaps mainline it's cleaner and simplified Nevertheless, it's working solid - what would be the next step, mergin in armbian main for this board?

Yeah, will prepare a pr to merge this patch to armbian mainline, but i still wanna give another try on the mainline's ac200 driver this week, since the mainline version have a better code quality and should be more stable in new kernel...

Besides, should we mark the ac200-sunxi and sunxi-gmac kernel config as 'y', to load by default or just make it as kernel extension module and then let user decide whether to load it?

[alexl83]

Thanks @chraac for your work, it's incredible! I see that other boards, like orangepizero3 have sun8i-dwmac set as module - perhaps it could be useful for consinstency Back in the days when I was a kid messing with linux, the debate was hot, monolithic vs modular kernel - shouldn't make any difference in this case, maybe having it as module makes it more flexible - I'd go for the customary route, if any

[chraac]

Thanks @chraac for your work, it's incredible! I see that other boards, like orangepizero3 have sun8i-dwmac set as module - perhaps it could be useful for consinstency Back in the days when I was a kid messing with linux, the debate was hot, monolithic vs modular kernel - shouldn't make any difference in this case, maybe having it as module makes it more flexible - I'd go for the customary route, if any

Finally, make the sunxi-gmac as a module, had to change some of thire code for fixing the compiling error though... Mainly some exported function changes, guess that's why sunxi guys build it into kernel by default. Works well on my board: https://paste.armbian.com/tugorupivo

[alexl83]

Going to test later today, thanks @chraac !!!

[alexl83]

Hi @chraac, it seems to be working rock solid!

Thanks!!!!

[EvilOlaf]

Hehe, I remember years ago we had something similar with OPi1+ built around Allwinner H6 which also needed PHY built as module in order to work.

[chraac]

Hehe, I remember years ago we had something similar with OPi1+ built around Allwinner H6 which also needed PHY built as module in order to work.

hmm, here we migrate both the sunxi-gmac and sunxi-ac200-ephy to get the eth work, how about the H6? can we share some driver files?

[chraac]

@alexl83 create a PR for this fix, still in draft state, will add some test screenshot to it

[FilipSwiatek]

Maybe it's worth to mention. I use Orange Pi zero 3 and I faced similar issue: [ 2.835558] dwmac-sun8i 5020000.ethernet: EMAC reset timeout [ 2.835579] dwmac-sun8i 5020000.ethernet eth0: stmmac_dvr_remove: removing driver [ 2.857516] dwmac-sun8i: probe of 5020000.ethernet failed with error -110 I use official debian build. and II updated all packages before. I switched power supply to 3A (I used 2A before) and problem gone. Orange Pi 3 is intended to operate with 3A supply indeed, Zero 2 the same.

Edit:// Heh, problem gone only temporarily. It happens again

[chraac]

Maybe it's worth to mention. I use Orange Pi zero 3 and I faced similar issue: [ 2.835558] dwmac-sun8i 5020000.ethernet: EMAC reset timeout [ 2.835579] dwmac-sun8i 5020000.ethernet eth0: stmmac_dvr_remove: removing driver [ 2.857516] dwmac-sun8i: probe of 5020000.ethernet failed with error -110 I use official debian build. and II updated all packages before. I switched power supply to 3A (I used 2A before) and problem gone. Orange Pi 3 is intended to operate with 3A supply indeed, Zero 2 the same.

Thank you Filip, use a 35W GaN usbc charger to test the zero2w, thought its enough for most of the H618 sbc..