Porting the MikroTik SXT Lite5 (SXT 5nD r2) from ar71xx to ath79

For Developers
1

Hi,

I'm porting the MikroTik SXT Lite5 (SXT 5nD r2), which is already in ar71xx, to ath79. Everything works fine, except for the Ethernet.

Originally, in ar71xx, there was this (mach-rbsxtlite.c):

static void __init rbsxtlite_setup(void)
{
	[...] 

	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE);

	ath79_register_mdio(1, 0x0);

	/* GMAC0 is left unused */

	/* GMAC1 is connected to MAC0 on the internal switch */
	/* The ethernet port connects to PHY P0, which connects to MAC1
	   on the internal switch */
	ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 0);
	ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
	ath79_register_eth(1);
}

which I've tried to translate into the DTS as:

&eth1 {
	status = "okay";

	phy-handle = <&phy0>;
};

&mdio1 {
	status = "okay";

	phy0: ethernet-phy@0 {
		reg = <0>;
	};
};

resulting in a kernel panic but a functional eth0 interface:

[    0.962127] libphy: Fixed MDIO Bus: probed
[    0.967061] ag71xx 1a000000.eth: invalid MAC address, using random address
[    1.288271] ------------[ cut here ]------------
[    1.293148] WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:419 __reset_control_get_internal+0x64/0x110
[    1.302771] Modules linked in:
[    1.305935] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.123 #0
[    1.312059] Stack : 80620000 805d57fc 00000000 00000000 805d5014 8382597c 838282f4 80603b67
[    1.320710]         80597ec0 00000001 80dc3670 000001a3 00000000 00000001 83825930 e9938325
[    1.329357]         00000000 00000000 80df0000 0000005e 00000000 00000000 00000007 00000000
[    1.338003]         0000005e e71a2829 00000000 0004ab0f 00000000 00000009 00000000 802eab64
[    1.346656]         805bf804 000001a3 00000000 80620000 00000002 80300494 00000000 80dc0000
[    1.355305]         ...
[    1.357831] Call Trace:
[    1.360401] [<8006b0b4>] show_stack+0x58/0x100
[    1.365037] [<80086240>] __warn+0xe4/0x13c
[    1.369288] [<800862e0>] warn_slowpath_null+0x48/0x68
[    1.374529] [<802eab64>] __reset_control_get_internal+0x64/0x110
[    1.380758] [<802ead48>] __of_reset_control_get+0x138/0x1a0
[    1.386536] [<802eb058>] __devm_reset_control_get+0x6c/0xc8
[    1.392340] [<80375640>] ag71xx_mdio_probe+0x9c/0x1d4
[    1.397597] [<80312b9c>] platform_drv_probe+0x40/0x88
[    1.402832] [<80310f20>] really_probe+0x180/0x300
[    1.407706] [<8030efd0>] bus_for_each_drv+0x50/0xb0
[    1.412760] [<80310d20>] __device_attach+0x84/0xfc
[    1.417724] [<80310004>] bus_probe_device+0x38/0xbc
[    1.422776] [<8030c944>] device_add+0x420/0x634
[    1.427498] [<80382f64>] of_platform_device_create_pdata+0xb4/0x100
[    1.433991] [<8038313c>] of_platform_bus_create+0x180/0x248
[    1.439769] [<80383380>] of_platform_populate+0x74/0xf0
[    1.445195] [<80377e44>] ag71xx_probe+0x824/0x960
[    1.450073] [<80312b9c>] platform_drv_probe+0x40/0x88
[    1.455317] [<80310f20>] really_probe+0x180/0x300
[    1.460194] [<80311464>] __driver_attach+0xb4/0xfc
[    1.465157] [<8030ef14>] bus_for_each_dev+0x54/0xac
[    1.470211] [<803102a4>] bus_add_driver+0xf4/0x214
[    1.475175] [<80311c80>] driver_register+0xcc/0x11c
[    1.480251] [<8063e2a4>] ag71xx_module_init+0x2c/0x50
[    1.485488] [<8006096c>] do_one_initcall+0x7c/0x1a0
[    1.490561] [<80628d54>] kernel_init_freeable+0x150/0x214
[    1.496152] [<804e5658>] kernel_init+0x10/0xf0
[    1.500759] [<800659f8>] ret_from_kernel_thread+0x14/0x1c
[    1.506367] ---[ end trace b18eccab21fe21ee ]---
[    1.511557] libphy: ag71xx_mdio: probed
[    1.517116] libphy: ar8xxx-mdio: probed
[    1.579716] switch0: Atheros AR8229 rev. 1 switch registered on mdio.0
[    1.625681] mdio_bus mdio.0: MDIO device at address 0 is missing.
[    1.657994] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000, driver=Generic PHY]
[    1.668101] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii

Actually, eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii is the correct configuration, present in ar71xx.

I can't get rid of this kernel panic. I've tried many combinations, such as:

&eth1 {
	status = "okay";

	phy-handle = <&swphy0>;

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <1>;
		switch-only-mode = <1>;
	};
};

&eth0 {
	status = "disabled";
	compatible = "syscon", "simple-mfd";
};

but I can't both have the interface working and get rid of the kernel panic.

Does anybody know what is the DTS equivalent for the ar71xx code?

Thanks!

1 Like
2

I can see from the ar71xx config that it is an AR934X series SOC. But which one exactly?

First thing I would try is copy the eth0 and eth1 DTS nodes from another DTS of a board with the exact same SOC, then you can adjust from there (whichever is only 1 port or is not terminated).

3

For example I was porting a board that is an AR9341 and this is the DTS nodes for that

&eth0 {
	status = "okay";

	phy-handle = <&swphy0>;
	mtd-mac-address = <&art 0x0>;
};

&eth1 {
	status = "okay";

	mtd-mac-address = <&art 0x0>;

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <1>;
	};
};
4

Hi Michael,

Thanks for your reply. It's an AR9344, I forgot to mention.

Using the code you wrote above (except for the MAC addresses, which I must set in 02_network), I get eth0 and eth1 to appear. eth0 is not functional, but eth1. Therefore, I need to get rid of eth0. Furthermore, I still get kernel error:

[    0.964868] libphy: Fixed MDIO Bus: probed
[    0.969856] ag71xx 19000000.eth: invalid MAC address, using random address
[    1.291983] ag71xx 19000000.eth: Could not connect to PHY device. Deferring probe.
[    1.300168] ag71xx 1a000000.eth: invalid MAC address, using random address
[    1.624485] ------------[ cut here ]------------
[    1.629363] WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:419 __reset_control_get_internal+0x64/0x110
[    1.638988] Modules linked in:
[    1.642150] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.123 #0
[    1.648274] Stack : 80620000 805d57fc 00000000 00000000 805d5014 8382597c 838282f4 80603b67
[    1.656925]         80597ec0 00000001 80dc3670 000001a3 00000000 00000001 83825930 e9938325
[    1.665571]         00000000 00000000 80df0000 00000060 00000000 00000000 00000007 00000000
[    1.674218]         00000060 aac3cceb 00000000 0009cc66 00000000 00000009 00000000 802eab64
[    1.682865]         805bf804 000001a3 00000000 80620000 00000002 80300494 00000000 80dc0000
[    1.691529]         ...
[    1.694055] Call Trace:
[    1.696623] [<8006b0b4>] show_stack+0x58/0x100
[    1.701253] [<80086240>] __warn+0xe4/0x13c
[    1.705501] [<800862e0>] warn_slowpath_null+0x48/0x68
[    1.710735] [<802eab64>] __reset_control_get_internal+0x64/0x110
[    1.716954] [<802ead48>] __of_reset_control_get+0x138/0x1a0
[    1.722732] [<802eb058>] __devm_reset_control_get+0x6c/0xc8
[    1.728528] [<80375640>] ag71xx_mdio_probe+0x9c/0x1d4
[    1.733786] [<80312b9c>] platform_drv_probe+0x40/0x88
[    1.739021] [<80310f20>] really_probe+0x180/0x300
[    1.743894] [<8030efd0>] bus_for_each_drv+0x50/0xb0
[    1.748948] [<80310d20>] __device_attach+0x84/0xfc
[    1.753912] [<80310004>] bus_probe_device+0x38/0xbc
[    1.758965] [<8030c944>] device_add+0x420/0x634
[    1.763686] [<80382f64>] of_platform_device_create_pdata+0xb4/0x100
[    1.770179] [<8038313c>] of_platform_bus_create+0x180/0x248
[    1.775958] [<80383380>] of_platform_populate+0x74/0xf0
[    1.781383] [<80377e44>] ag71xx_probe+0x824/0x960
[    1.786261] [<80312b9c>] platform_drv_probe+0x40/0x88
[    1.791498] [<80310f20>] really_probe+0x180/0x300
[    1.796373] [<80311464>] __driver_attach+0xb4/0xfc
[    1.801336] [<8030ef14>] bus_for_each_dev+0x54/0xac
[    1.806389] [<803102a4>] bus_add_driver+0xf4/0x214
[    1.811355] [<80311c80>] driver_register+0xcc/0x11c
[    1.816431] [<8063e2a4>] ag71xx_module_init+0x2c/0x50
[    1.821668] [<8006096c>] do_one_initcall+0x7c/0x1a0
[    1.826741] [<80628d54>] kernel_init_freeable+0x150/0x214
[    1.832341] [<804e5658>] kernel_init+0x10/0xf0
[    1.836957] [<800659f8>] ret_from_kernel_thread+0x14/0x1c
[    1.842562] ---[ end trace dff4f13dfd2b8702 ]---
[    1.847753] libphy: ag71xx_mdio: probed
[    1.853317] libphy: ar8xxx-mdio: probed
[    1.915998] switch0: Atheros AR8229 rev. 1 switch registered on mdio.0
[    1.987708] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000, driver=Generic PHY]
[    1.997768] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[    2.004543] ath79-wdt 18060008.wdt: timeout value must be 0 < timeout < 10, using 10
[    2.019844] MikroTik RouterBOARD hardware configuration sysfs driver v0.04
[    2.028717] MikroTik RouterBOARD software configuration sysfs driver v0.02
[    2.037183] NET: Registered protocol family 10
[    2.045249] Segment Routing with IPv6
[    2.049250] NET: Registered protocol family 17
[    2.053978] 8021q: 802.1Q VLAN Support v1.8
[    2.062197] ag71xx 19000000.eth: invalid MAC address, using random address
[    2.385001] ag71xx 19000000.eth: connected to PHY at mdio.0:1f:00 [uid=004dd042, driver=Generic PHY]
[    2.395607] eth1: Atheros AG71xx at 0xb9000000, irq 4, mode: mii

but, at least I've got the interface there.

I've checked all the AR934x-based DTSs only to find that, apparently, none of the devices currently in ath79 has the same settings. There's another one in ar71xx, the ubnt_airgateway_pro, which uses has the same network configuration; unfortunately, it's not yet in ath79.

What device where you working on?

5

I was working on ENS202EXT

An unsuccessful probe would only be considered an error if it doesn't find the interface you need, but for you the ethernet is working now right?

The other error you see:
WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:419 __reset_control_get_internal+0x64/0x110
Is something wrong with the master branch right now, I'm assuming nothing wrong with your porting. I get the same thing if I build from master right now.

Heres my most recent bootlog, has the same thing but all interfaces are fine:

The device only has 1 ethernet port right? If it functions then you're good to go with something like this:

&eth0 {
	status = "disabled";
};

&eth1 {
	status = "okay";

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <1>;
	};
};

If that's not working for some reason you can try without the "switch-phy-swap" bit set:

&eth0 {
	status = "disabled";
};

&eth1 {
	status = "okay";

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <0>;
	};
};

However if you swap PHY using the GMAC0 configuration, the physical port might end up being on the internal switch on eth0 instead of alone on eth1.

6

Also, in the ar71xx code they used the GMAC config for Switch only mode:

ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE);

In my pull request I went deeper into the options, what they mean and do.

In the DTS these two options are represented as the variables:
switch-phy-swap
switch-only-mode

However you already have the ethernet functioning so you don't need to mess with it. For only a single port it is preferred that it is not on the internal switch, for link status (also mentioned in the pull request).

7

Hi Michael,

Thanks for your tips! :slight_smile:

Yes, I did have the working configuration, with the switch and the interface detected, and the (one) physical port working.

I was deeply convinced it was my fault. The error only appeared for some configurations (actually, for the working one), so I assumed I was causing it by using the wrong settings. I didn't think of it being a tree-wide problem, as I hadn't seen it on any other device. I'll try to trace down the commit introducing it.

This one above is not working.

This second one is working, but I don't get the link up/down changes.

I'll investigate more into the issue. Thank you very much for the info. :slight_smile:

8

Even simpler than before:

&eth1 {
	status = "okay";
};

and it just works. However, I can't find the way to make the system aware of link changes in the port.

swconfig correctly reports link, speed and activity on port #1, but I can't make the system attribute that port's behaviour to eth0.

9

But is the port on eth0 or eth1?

Lets go deeper so we are on the same page.

http://microchip.ho.ua/data/AR9344.pdf

Page 61 has the diagram and description for how GMAC0 and GMAC1 function and are configurable

ar934x.dtsi is where the GMAC configuration is handled, so its the same for both ar9341 and ar9344

Depending on the board design, the physical port can be soldered/connected to either P0, P1, P2, P3, P4 (or PHY0 through PHY4).

The ar934x.dtsi has the kernel see GMAC0 as eth1 and GMAC1 as eth0
(dont ask me why they are swapped, makes this more confusing lol)

If the physical port is connected to the chip as P0 or P4, then you can connect that port to GMAC0 with either switch-phy-swap = <0>; or switch-phy-swap = <1>;

In that case, the kernel would see the connection as eth1 and would see link status.

If the physical port is connected as anything else (P1, P2, P3)
Then it is stuck on the internal switch and there is no way for the kernel to get link status (AKA it will always see the CPU port as "link up" as long as eth0 is enabled).

If it shows up as eth0, its on the switch
If it shows up as eth1, its not on the switch.

At this point, I'm starting to think the physical port is permanently tied to the switch (AKA on P1 or P2 or P3). However, you said earlier you got the port working on eth1.

Make sure you have both eth0 and eth1 set to LAN for testing. This is what I had when testing the ENS202EXT:
(target/linux/ath79/generic/base-files/etc/board.d/02_network)

	engenius,ens202ext)
		ucidef_set_interface_lan "eth1"
		ucidef_add_switch "switch0" \
			"0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:lan"
		;;

Setting the switch in configuration also allows you to see where the port is in LuCI in case its not on eth1.

for the DTS you can try both eth0 and eth1 enabled

&eth0 {
	status = "okay";

	phy-handle = <&swphy0>;
};

&eth1 {
	status = "okay";

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <0>;
	};
};

(you can also try phy-handle = <&swphy4>; but I don't think it matters here)

This way, you can determine whether the physical port is within the GMAC0 possible group (P0 or P4) or not. By switching between switch-phy-swap = <0>; and switch-phy-swap = <1>;. The port would go from being on the eth0 switch, to becoming eth1. Otherwise, it will always be on the switch, and link status will not be possible.

10

Hi Michael,

Thank you very much for your detailed answer. I'll go step by step.

I think it's on eth1, because it only works when dmesg reports:

[...]
[    1.997768] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[...]

and interrupts = <5>; corresponds to eth1 in ath79.dtsi.

Furthermore, the ar71xx code was:

	# GMAC0 is left unused
	# GMAC1 is connected to MAC0 on the internal switch
	# The ethernet port connects to PHY P0, which connects to MAC1
	# on the internal switch

	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE);
	ath79_register_mdio(1, 0x0);
	ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 0);
	ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
	ath79_register_eth(1);

and there, link detection used to work.

According to swconfig, the physical port is connected to PHY1. See it here intentionally working at 10 Mbps:

root@OpenWrt:/# swconfig dev switch0 show
Global attributes:
	enable_vlan: 0
	ar8xxx_mib_poll_interval: 500
	ar8xxx_mib_type: 0
	enable_mirror_rx: 0
	enable_mirror_tx: 0
	mirror_monitor_port: 0
	mirror_source_port: 0
	arl_table: address resolution table
Port 0: MAC 4c:5e:0c:bd:ee:72
Port 0: MAC 32:ac:81:1b:a3:8c
Port 1: MAC 00:0e:aa:00:42:6b

Port 0:
	mib: MIB counters
RxGoodByte  : 8997 (8.7 KiB)
TxByte      : 21774 (21.2 KiB)

	pvid: 0
	link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
Port 1:
	mib: MIB counters
RxGoodByte  : 21774 (21.2 KiB)
TxByte      : 8819 (8.6 KiB)

	pvid: 0
	link: port:1 link:up speed:10baseT half-duplex auto
Port 2:
	mib: No MIB data
	pvid: 0
	link: port:2 link:down
Port 3:
	mib: No MIB data
	pvid: 0
	link: port:3 link:down
Port 4:
	mib: No MIB data
	pvid: 0
	link: port:4 link:down

But this is not coherent with the info in the ar71xx comment (!?):

The ethernet port connects to PHY P0, which connects to MAC1
on the internal switch

Anyway... I tested your "detection" settings for 02_network and the DTS. With your configuration, I got the link status on eth1, but no traffic going in. Then I set switch-phy-swap = <1> and I got both eth1 with rx/tx traffic and link detection (good! :slight_smile: ). But still I got eth0 around (indeed, eth0.1). In this situation, again, swconfig reports the link activity/speed on Port 1.

Now, how to only end up with one network interface in the system? Continuing on next post...

11

This is the "baseline" configuration, with eth1 working (traffic + link detection), but also eth0 there, and activity appearing on PHY1 on the switch according to swconfig:

&eth0 {
	status = "okay";

	phy-handle = <&swphy0>;
};

&eth1 {
	status = "okay";

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <1>;
	};
};

Then I tried this one, with eth1 working (traffic + link), also eth0 there, and nothing being reported by swconfig (!?!?):

&eth0 {
	status = "okay";

	phy-handle = <&swphy0>;

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <1>;
	};
};

&eth1 {
	status = "okay";
};

So the obvious step was to "deactivate" &eth1:

&eth0 {
	status = "okay";

	phy-handle = <&swphy0>;

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <1>;
	};
};

&eth1 {
	status = "okay";

	compatible = "syscon", "simple-mfd";
};

which got eth0 working properly (traffic+link detection). :partying_face: Oh, and no kernel error when probing mdio/network!

Might this have changed from ar71xx to ath79? Anyway, that was the key to have it working. Still, ifconfig reports even different interrupts (ar71xx/ath79 respectively):

eth0      Link encap:Ethernet  HWaddr 4C:5E:0C:BD:EE:72
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::4e5e:cff:febd:ee72/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:44 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6027 (5.8 KiB)  TX bytes:5546 (5.4 KiB)
          Interrupt:5

eth0      Link encap:Ethernet  HWaddr 4C:5E:0C:BD:EE:72  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:212 errors:0 dropped:0 overruns:0 frame:0
          TX packets:112 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:39789 (38.8 KiB)  TX bytes:14238 (13.9 KiB)
          Interrupt:4

So, besides that, is it the physical port really connected to PHY1? Because, as I understand it now, it is on PHY0. :thinking:

@mpratt14, thank you very very much for your help on getting the device finally working. Is it OK for you if I acknowledge you in the commit message?

1 Like
12

It looks to me what you did is simply swapping eth0 and eth1.

if you disabled eth0, would everything still work?

like this:

&eth0 {
	status = "disabled";
};

&eth1 {
	status = "okay";

	gmac-config {
		device = <&gmac>;
		switch-phy-swap = <1>;
	};
};

I think you tried this before... but my expectation is that the switch is disabled and the other port on the other GMAC remains usable...

I could be wrong, but I think the gmac-config node only functions when placed inside the &eth1 node.

Also just wondering, how do you judge link status on the port when its not on the switch? I just use LuCI and dmesg.

14

Also, when we say PHY0 through PHY4 or P0 through P4, that refers to the physical board trace and where that ends up being soldered to the SOC. It may or may not reflect the same way on the software side (aka in swconfig status)

PHY port 0 is the physical trace on the board to the SOC chip

MAC port 1 is what you see in swconfig

They used the "switch-only-mode" configuration in ar71xx to force every PHY port to be on the internal switch. True link status is not possible this way (unless some weird hack) and therefore not preferred anymore.

I bet on ar71xx you actually didn't have link status. If you connected to the board over wireless and then disconnected ethernet, the lost of link status would not appear in dmesg. This is the way it was explained to me in my pull request:

The implication is there's a difference between you seeing link status in swconfig and the "host system" being able to see link status (the kernel I guess), which only sees the switch as a whole.

Looks like both eth0 and eth1 are named eth0 lol

here is my ifconfig:

eth0      Link encap:Ethernet  HWaddr 88:DC:96:5B:91:7B
          inet6 addr: fe80::8adc:96ff:fe5b:917b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1027 errors:0 dropped:0 overruns:0 frame:0
          TX packets:172 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:297964 (290.9 KiB)  TX bytes:21828 (21.3 KiB)
          Interrupt:5

eth0.1    Link encap:Ethernet  HWaddr 88:DC:96:5B:91:7B
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1027 errors:0 dropped:0 overruns:0 frame:0
          TX packets:150 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:279478 (272.9 KiB)  TX bytes:17162 (16.7 KiB)

eth1      Link encap:Ethernet  HWaddr 88:DC:96:5B:91:7B
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:4

And the interrupts to the corresponding hardware:

root@OpenWrt:~# cat /proc/interrupts
           CPU0
  2:          0      MIPS   2  ath9k
  4:          0      MIPS   4  19000000.eth
  5:       1315      MIPS   5  1a000000.eth
  7:      61600      MIPS   7  timer
 11:          0  gpio-ath79   1  keys
ERR:          0

From the datasheet:

0x19000000 is GMAC0 (the single port)
0x1a000000 is GMAC1 (the internal switch)

15

No, like this it doesn't. I first get the kernel error, and then the interface has no incoming traffic, nor it detects link/speed changes. Also, swconfig does not report anything.

I don't know, but there are plenty of AR934x-based devices which use it inside &eth0, so I guess it's OK. Furthermore, it's definitely had an effect.

It just appears on the serial console, or with dmesg:

[...]
[   20.672899] br-lan: port 1(eth0) entered blocking state
[   20.678379] br-lan: port 1(eth0) entered disabled state
[   20.684180] device eth0 entered promiscuous mode
[   20.708774] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[   24.775088] eth0: link up (100Mbps/Full duplex)
[   24.780119] br-lan: port 1(eth0) entered blocking state
[   24.785571] br-lan: port 1(eth0) entered forwarding state
[   24.793971] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[   61.637692] eth0: link down
[   61.641765] br-lan: port 1(eth0) entered disabled state
[   62.663394] eth0: link up (10Mbps/Half duplex)
[   62.676402] br-lan: port 1(eth0) entered blocking state
[   62.681854] br-lan: port 1(eth0) entered forwarding state
[   67.782788] eth0: link up (100Mbps/Full duplex)
[   71.877694] eth0: link down
[   71.881757] br-lan: port 1(eth0) entered disabled state
[   86.215077] eth0: link up (100Mbps/Full duplex)
[   86.220052] br-lan: port 1(eth0) entered blocking state
[   86.225505] br-lan: port 1(eth0) entered forwarding state

and also at /sys/class/net/eth0/speed. Probably not shown in LuCI. :wink:

I couldn't track the RJ45 connector to the actual SoC pins this time. I've done it before but I didn't have a tester. It would have saved lots of time to both of us.

I guess they had a reason for that. Anyway, in ath79 it don't see it's adding anything, so I'll just not use it.

I actually had it on ar71xx; link loss was reported. However, the interface was always connected at 1000 Mbps, regardless of the real interface speed (i.e., on the computer). However, now, on ath79, I get both link status and speed correctly reported. So we even improved device support! :slight_smile:

Yes, but first is ar71xx, second is ath79. I should have made it clear. :roll_eyes:

Cool, so I'm now using GMAC0 in ath79:

[    1.329901] switch0: Atheros AR8229 rev. 1 switch registered on mdio.0
[    1.375781] ag71xx 19000000.eth: invalid MAC address, using random address
[    1.698277] ag71xx 19000000.eth: connected to PHY at mdio.0:1f:00 [uid=004dd042, driver=Generic PHY]
[    1.708601] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: mii

while in ar71xx GMAC1 was being used. This is aligned with Chuanhong's explanation. :+1:

I wonder what sort of hack were they using in ar71xx to get the link up/down status... But it's good that I don't need it anymore.

Thank you very much for sharing your knowledge here. :smiley:

16

Because configuring 1 GMAC is easier than configuring 2 lol

So you did manage to get eth0 to be GMAC0, nice. I guess placing the gmac-config node inside eth0 does that.

At this point I'm confused on what counts as link status for the host system.

That tells me that something on ar71xx kernel was not seeing the link correctly (since its on the switch). It was reading the speed from MAC port 0 (the CPU port) of the switch. But you still got a link down in the kernel log?

Either way it looks like you're done. At this point you can set eth1 to disabled. Or does that break eth0?

No need to define a switch anymore :+1:

Happy to help, thanks for your knowledge too. You can Acked-by me on the commit if you want to

17

On ar71xx I only got link up/down, but at a fixed 1000 Mbps speed, not the actual one on the switch's physical port.

Yes, it breaks eth0 and no interface is available.

I'll be submitting a PR soon. Thanks! :slight_smile:

18

@rogerpueyo I started a bug report for the kernel trace we have been experiencing

https://bugs.openwrt.org/index.php?do=details&task_id=3205

19

Not sure if I should dig this out after two years, but I think I figured out a solution by accident, when working on Ruckus ZoneFlex 7372:

TL;DR if you want to also get link status on eth1, then /delete-node/ fixed-link; from &eth1 in device tree, and then bind the required swphy node, phy-node = <&swphy0> in my case.

20

But definitely! :slight_smile:

Thanks for the message, and for the summary. I have the device on a temporary lease, for some weeks. I'll test it when I have it returned.

Roger

21

I think we should spread the word even more - there are plenty of two-port devices like that in ath79, that can be fixed. Maybe this way it'll be easier to identify them.
OTOH, I'm not sure if that is so high priority, as DSA will eventually come to builtin switch devices as well.