No ethernet on OrangePi Win (Plus)

[fhaust]

From what I gathered there is a power distribution chips on the OrangePi Win (Plus) that needs to be configured correctly to enable the external ethernet chip (MAC?).

I guess this is a known issue and I am not even sure this is the right place to put this, but the whole process and all interlocking components are a bit opaque to me and it seems to be that here is the place that has should be fixed?

From looking around the internet there is little to no information available on the topic. Or at least none that is readily applicable (by me). But as there is an old u-boot version that apparently initializes the board correctly it seems to me that it is only a matter of adapting what's in there into the new u-boot version? I'd gladly help out, but I have no idea where to start.

Kind regards,
Florian

[apritzel]

Where do you have no Ethernet? In Linux or in U-Boot? I recently pushed DT updates (originally from @smaeul) to the Linux tree, you can actually compile the .dtb from this tree already. If you give this .dtb to any halfway recent kernel (>=4.15 should be good, Ubuntu 18.04 for instance), Ethernet should work. Please let me know if this isn't sufficient, as I couldn't test this personally.

[fhaust]

I am not sure if I have ethernet in u-boot, there are some lines along "no ethernet" in the output during boot (monitored over UART). I definitely have no ethernet once the kernel boots up.

This is on a recent Arch Linux ARM image with a self compiled 4.18.7-rt kernel.
I'll try dropping the .dts files in my kernel source once I get back home.

Do I read this as the dtb files of the kernel are completely independent of u-boot and the arm trusted build? I was thinking that u-boot needs to set up the board before the kernel even starts and that's where the problem lies.

[apritzel]

A .dtb describes the hardware, so it's independent from any OS or firmware. At least that's the theory. In real life this is more complicated, for historical and sometimes political reasons. But we are working towards this "Let one .dtb rule them all and let it live in firmware". For that matter mainline U-Boot now includes the Linux 4.18-rc3 .dts files, and I plan to update them regularly. To use U-Boot's .dtb, you give the kernel $fdtcontroladdr as the FDT address (on the booti command line). EFI boot uses this automatically if not explicitly told otherwise.
For the "u-boot sets up the board" part: For ages ARM embedded Linux kernels had a deep mistrust against "firmware", so Linux tends to initialise everything itself. The only real exception is DRAM, but the rest can work if only the kernel knows about it, which means it has a driver and sees the correct .dtb stanza to describe the board's setup. For Ethernet starting with Linux v4.15 the kernel's driver side is fine, but the "official" .dtb might be lacking. You can fix this by just providing a newer .dtb. Ideally you would copy the new .dts file into the respective U-Boot directory and build it, to get this automatically, as described above.
Hope that helps and is not too confusing.

[fhaust]

Back home ... compiled the dtb from the tree you linked to. Copied the resulting dtb to the SD card and booted the kernel.

This gets me further than before and the kernel seems to recognize the existence of an ethernet interface. But the driver does not load successfully and ip addr (nor ifconfig) show a network interface (except for lo).

Any ideas?

[fhaust]

Just testing around:

• The alternative sun4i-emac doesn't do anything either.
• USB does not seem to be working (judging by a usb stick that is not working). There are some lines that refer to USB something something not working?

[fhaust]

Wait ... does this also mean that this fork is basically superfluous and I should be using upstream instead?

[apritzel]

Thanks for testing and the logs. Can you please check whether you have CONFIG_REGMAP_MMIO enabled in your kernel? There might be a missing dependency here, but it seems to be indirectly selected by multiple symbols used in defconfig. If in doubt, please post your .config somewhere. Is that the -rt kernel packaged by ArchLinux? I could only find the x86 .config.

• sun4i-emac is for an 100MBit MAC in mostly older Allwinner SoCs, the A64 does not have this hardware.
• This "fork" is the queue for the next kernel's DT files. The patches came too late for the 4.19 merge window, so Maxime queued them here for the next one (November). But it's only .dts files, so you can use them anytime, even on most older kernels.

[fhaust]

CONFIG_REGMAP_MMIO is enabled in my .config. It should be the arm64/defconfig plus some rt configurations.

It's not the ArchLinux Kernel. It's the vanilla kernel plus rt patches:

• https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.18.7.tar.xz
• https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/4.18/patch-4.18.7-rt5.patch.xz

[apritzel]

OK, I just found that same problem on a Pine64 by accident. I think it's probably about the new DTS with an older kernel. Can you try to add "syscon" to the compatible list for the system controller in sun50i-a64.dtsi? So that it reads:

syscon: syscon@1c00000 {
    compatible = "allwinner,sun50i-a64-system-control", "syscon";

Might be a hack, I have to check whether this works in both ways.

[fhaust]

That seems to fix part of it: https://gist.github.com/fhaust/e01514496ef5eceb1d28e6b6dd379b08#file-gistfile1-txt-L349-L355

There's still some error messages about not being able to connect to PHY, but the interface comes up.

There still seems to be a problem when I try to start up the interface:

[root@alarm netctl]# netctl start ethernet-dhcp                                                                       
[   92.748057] dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY
[   92.754598] dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19)
Job for netctl@ethernet\x2ddhcp.service failed because the control process exited with error code.
See "systemctl status "netctl@ethernet\\x2ddhcp.service"" and "journalctl -xe" for details.

[fhaust]

Without wanting to annoy, any update on this?