T95Z max ethernet problem


#1

Hi all
I got one T95Z “max” and hit a wired ethernet issue. Basically the ethernet port “works” but at a ridiculus speed, almost unusable. I read other reports about this problem, but I am not sure if it is fixed somehow with specific dtb, shall I ask for a replacement or just drop it because the porto won’t work at all
Workaround to lower to 100mbit is not an option for me
Bye


New dts required for gigabit TV box
#2

interesting …I have 1 and also see the network speed seems lower than I would expect. Where are the other reports on this ? I didnt see anything…


#3

Can you spot anything strange if you run “ethtool eth0” over ssh?


#4


and

and (similar)
https://discourse.coreelec.org/t/no-wired-connection-on-beelink-gt1-s912-8-90-2/257/124

Can you take a picture of your device? You know, the chinese rebranding is quite difficult to follow :wink:


#5

Use the q201-1gbit dtb.


#6

Did it already. The results are identical to q200 dtb (I really can’t see, but it is my fault the difference between q200 and q201). @TheCoolest: I have the android dtb dumped here, it comes from a dump directly from the android shell, the partition is a multy dtb with the RMII (100Mbit) dtb first and RGMII(1000Mbit) dtb then. I have already cut to the RGMII partition and checked. The values in the ethernet part are identical, so either there is smoething else different that I cannot point out, or the driver in the adroid image is customized.
Would you mind to give a look? I ask this because there a a number of different t95z plus out there, we may mix dtb dump with the real device
t95zplus.dts (53.6 KB)


#7

@TheCoolest: the dts really look ok. So I have search a litthe bit about “unstable gigabit stmmac”, and endup here:

https://groups.google.com/forum/#!topic/linux-sunxi/mFrbrjlmP2g

patch

http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001674.html

This point to an issue with the tx-delay that shall be set to 1 in some boards. Now I remember that this topic has been discussed in armbian regarding to unstable gigabit connections with stmmac
New kernel manage this byt dts binding:

https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/net/meson-dwmac.txt

But it does not looks implemented in kernel 3.14.x
So it is definitely possible that the stmmac driver in kernel itself has been modified.
Can you point me to the source code? Or maybe check if there is some equivalent binding supported. I am very convinced the problem is there, but I need to know how download the coreelec kernel
Bye


#8

Ok, I have some news
According to the dynamic tx-delay configuration patch set found here:

 #define PRG_ETH0_TXDLY_SHIFT		5
 #define PRG_ETH0_TXDLY_MASK		GENMASK(6, 5)
-#define PRG_ETH0_TXDLY_OFF		(0x0 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_QUARTER		(0x1 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_HALF		(0x2 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_THREE_QUARTERS	(0x3 << PRG_ETH0_TXDLY_SHIFT)
 
 /* divider for the result of m250_sel */
 #define PRG_ETH0_CLK_M250_DIV_SHIFT	7
@@ -69,6 +67,8 @@ struct meson8b_dwmac {
 
 	struct clk_divider	m25_div;
 	struct clk		*m25_div_clk;
+
+	u32			tx_dly;
 };
 
 static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
@@ -198,7 +198,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
 
 		/* TX clock delay - all known boards use a 1/4 cycle delay */
 		meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
-					PRG_ETH0_TXDLY_QUARTER);
+					dwmac->tx_dly << PRG_ETH0_TXDLY_SHIFT);
 		break;

The Tx-delay is set in meson dwmac eth reg0, bit 6:5 with the values you can see in the define
So I gave a look at the amlogic bsp driver and found that the reg0 is set according to the mc_val dts binding:

PREG_ETH_REG0 = addr;
......................
	if (of_property_read_u32(np, "mc_val", &mc_val)) {
		pr_debug("detect cbus[2050]=null, plesae setting mc_val\n");
		pr_debug(" IF RGMII setting 0x7d21 else rmii setting 0x1000");
	} else {
		pr_debug("Ethernet :got mc_val 0x%x .set it\n", mc_val);
		writel(mc_val, addr);
	}

in the coreelec dts we have a value of 0x1621 (it is the same of the android stock dts)

0x1621 means that bit 6:5 are 01 which is TXDLY_QUARTER (2ns)
Later in the evening I will try other combination of this delay and check if it helps


#9

Not sure i understand fully as I’m not a dev (old techie here) but is this saying the CE core build needs tweaked to resolve this?


#10

Unfortunately no success here, the problem is this one
Working H96pro plus:

[ 0.505237@1] eth0: PHY ID 001cc916 at 0 IRQ POLL (stmmac-0:00) active
[ 0.505248@1] eth0: PHY ID 001cc916 at 7 IRQ POLL (stmmac-0:07)

This is a well know Realtek PHY RTL8211F, this PHY insert a RX delay in RGMII side
While the non working t95z:

[ 0.508259@0] eth0: PHY ID 03815c11 at 1 IRQ POLL (stmmac-0:01) active

This is an unknown to me PHY. There is no driver in either mainline nor amlogic linux kernel, so the coreelec one turns in the generic phy driver. Now I am sure that we miss a specific configuration of the RX delay in this phy.
The reason why the android stock image works is 99.99% due to the fact that the PHY specific driver is included or there is some kind of tweaks in its kernel.
I don’t know really if we can make something more here, by box is also sealed but looking at this video:

I see the PHY, it seems thare is a “ZTE” as brand and something xxxxA500, but I could not figure out more
Can I have a discussion with some devs to see if I can make some insight in the android kernel?
Bye


#11

This issue , I am sure , is preventing me from going full time to CE.

If I run wireless it’s just about workable but as soon as I plug in the cable it’s unusable. Noticing a lot of lag generally with the system.

Fingers crossed we get a solution soon otherwise I think I won’t be able to use CE here … :worried::weary:


#12

I have implemented a driver to disable EEE that is source of slowness for RTL chip, but still it is not working correctly. Now I run out of idea, meanwhile I tried to ask the manufacturer for info and ZTE for the datasheet, but the chance to get something are not so big.


#13

You could always buy a USB Ethernet adapter as a short term solution, after the Leia final we will focus our efforts on mainline.


#14

Yes I know, but there is absolutely no chance that mainline works any better. It would pick up gen_phy driver that, if instructed by mdio binding, would disable EEE, as I did in my attempt above. So I don’t think it would make any difference. Anyhow I got reply from ZTE promising a feedback from the silicon department. Not sure if I can really put hand on datasheet, let’s see…


#15

How would you ensure you had a matching DTB.img for such an adaptor?

It may be a daft question but I thought I would ask …


#16

You don’t need a DTB for USB Ethernet. You just plug it in and it works.
I use this one with my S905X box: https://www.ebay.com/itm/112541143662


#17

I must go find my Gigabit usb Ethernet adaptor which is gathering dust somewhere :grinning:. Will give it a go…


#18

I have one and works ok for any reasonable UHD high bitrate movie. But it run USB 2.0 so theoretical 250Mbit. And you must make sure that the chipset is supported (95% are)


#19

You actually get about 300-320Mbits down and 180Mbits up.
More than enough for any 4K content.


#20

@menion … plugged it l…got an IP address so seems to be supported I guess …still didn’t solve my problem… starting to think this box is fubar’d for CE (box works on Android fine)