Use the q201-1gbit dtb.
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)
@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
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
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?
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
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 … 
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.
You could always buy a USB Ethernet adapter as a short term solution, after the Leia final we will focus our efforts on mainline.
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…
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 …
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
1 Like
I must go find my Gigabit usb Ethernet adaptor which is gathering dust somewhere 
. Will give it a go…
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)
You actually get about 300-320Mbits down and 180Mbits up.
More than enough for any 4K content.
@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)
Please elaborare what kind of problem you are talking about regarding the USB Ethernet adaptor
Hi,
don’t know if it’s related to your problem here and if it’s still existing in CoreELEC but in LibreELEC there is/was a freakin’ problem with the dhcp settings. I have both boxes mentioned here (‘Sunvell T95Z Plus’ and the ‘Alfawise H96 Pro Plus’). Both connected via wired Gbit ethernet. As soon as I change the network settings to tell the system to use a dedicated ip address I really have big issues with the network speed of both mentioned S912 boxes. If I leave the setting on ‘dhcp’ everything is working fine. Weird but true, it took me hours to find that out.
Maybe worth a try if you have also changed your network settings to a dedicated ip address in the CoreELE ui.
greetings
1 Like
@Menion … basically I plugged it …it got an IP address and all looked ok …I disabled wireless on the box to ensure only 1 network connection via the USB device … All using DHCP …
Still looked same with browsing SMB and NFS … told it to go update the library and the thing just hung …
I would give up on this entirely and assume it’s the box except for the fact the Android on it with Krypton Kodi is working 100% …
So 2 OS , same hardware , 1 works and 1 doesn’t …
If I can’t solve it there will be no CE for me
This is strange. This evening I will test with my usb dongle. If it is confirmed then it means that we have a completely different issue here