Posts by Menion

You probably have another problem

Can you confirm that without the patch, you were not able to even get a gigabit connection?

Do you have choppy playbacks adjusting audio offset to ahead of more than 150ms?

Quote from papla83

Hi and thanks .

Does it works on 3gb/32GB version ? with ATVXperience ?

Thanks.

You have problem with gigabit speed? If so it is possible the solution solves it, but the dtb attached is for 2gb RAM

Quote from Whitesak

Thank you very much.

I have tried your new dtb file, but unfortunately I don´t see any improvement.

My gigabit ethernet on my Sunvell T95Z Max is still slow.

I still must use USB Gbit adapter for high bitrate files.

You are probably doing something wrong with the dtb

Means that you can use the dtb in the attached zip file, meaning that you copy it to dtb.img in the SD card root directory

Please consider that it will be reset to the old one if you upgrade, until we manage to put it in the supported dtb, still you can recopy it unless there is some modification made.

Solved, see: ZTE ZX2AA500 GB Ethernet Transceiver Problems (SOLVED big news for inside)

Quote from chewitt

In the last couple of weeks i've been sporadically poking 4.18/4.19 kernels with a VIM2 board which uses the RTL8211F chip and experienced awful ethernet performance (major packet loss etc.) until the CONFIG_REALTEK_PHY was switched from =m to =y .. before the change the PHY was showing up as the CONFIG_GENERIC_PHY device, and since it's been fine.

It's probably unrelated, but it jogged my memory of your problem so I figured I'd post something.

This is another issue. Because the way the PHY lib works, I don't think that PHY driver compiled as modules work at all, due to the way the probing is done. If you check the gen_phy you see that the clock screw has been moved under specific dts bindings, but the 8211F also require a special init function

I have just solved the issue with the help of Sam Nazarko

We need to remove the "cali_val" property in dts bindings

He said that the cali_val 0x20000 that comes from AMLogic EVB introduce a lot of performances issue in the TV box hardware and he does know why it is widely used

It is possible that it is still needed for some TV box layouts, so maybe it is time to bring a new dts variant in the LE/CE family

Note: the value is still present in the android dts, so I REALLY have no clue of what is going on in android to make everything work ok there....

I am using Armbian images on mainline 4.18.x from the repository you linked few posts above

chewitt do you have some hints for the mainline kernel? I have compared the mainline q201 (and q200) dts with the one we run in LE/CE. Of course they are different, but I don't see anything critical that could explain why it is not booting in mainline on t95z

Not booting = boot logo and no IP taken on the interface, but I cannot say if the linux subsystem is running behind the boot logo and there is "only" a problem with the DRM and the ethernet controller, since I don't have UART access and honestly I would like to avoid to solder it

chewitt I didn't receive any feedbacks from ZTE, have you checked with rockchip if they can put hands on the register specs of the PHY?

Meanwhile I tried to boot the Armbian image with kernel 4.18.0 using the q201 dtb, but I am stuck at the boot logo unfortunately

But if it is so, how we can explain the different behaviour between android stock and linux, even if they run the same amlogic bsp (kernel 3.14)?

Also, the dma is on top of the stmmac compatible controller, so it is completely "internal" to the S912

And from the MDIO register dumps, it is clear that the first vendor specific register, MDIO reg 16, is writable and it is different between android and linux, so something has written it, that is not present in linux

So, got the dumps of the android and CE phy registers, I see some difference in the vendor custom registers, even in some RW register that in my opinion explain the different behaviour between Linux/Android. The device returns all 0 to the MMD standard registers

I have tried to align the registers between Android and Linux, some of them are RO, but it does not help (I tried also to reset PHY after having done it). So I think the only option left is to get hands on the datasheet and even better, an application note

ANDROID                                  LINUX CE
PHY: 1|REG: 0 ---> 0x1140                PHY: 1|REG: 0 ---> 0x1140
PHY: 1|REG: 1 ---> 0x796d                PHY: 1|REG: 1 ---> 0x796d
PHY: 1|REG: 2 ---> 0x0381                PHY: 1|REG: 2 ---> 0x0381
PHY: 1|REG: 3 ---> 0x5c11                PHY: 1|REG: 3 ---> 0x5c11
PHY: 1|REG: 4 ---> 0x11e1                PHY: 1|REG: 4 ---> 0x11e1
PHY: 1|REG: 5 ---> 0xc1e1                PHY: 1|REG: 5 ---> 0xc1e1
PHY: 1|REG: 6 ---> 0x006d                PHY: 1|REG: 6 ---> 0x006d
PHY: 1|REG: 7 ---> 0x2001                PHY: 1|REG: 7 ---> 0x2001
PHY: 1|REG: 8 ---> 0x488e                PHY: 1|REG: 8 ---> 0x6801   <--Link Partner Next Page Ability 
PHY: 1|REG: 9 ---> 0x0300                PHY: 1|REG: 9 ---> 0x0300
PHY: 1|REG: 10 ---> 0x3800               PHY: 1|REG: 10 ---> 0x3800
PHY: 1|REG: 11 ---> 0x0000               PHY: 1|REG: 11 ---> 0x0000
PHY: 1|REG: 12 ---> 0x0000               PHY: 1|REG: 12 ---> 0x0000
PHY: 1|REG: 13 ---> 0x0000               PHY: 1|REG: 13 ---> 0x0000
PHY: 1|REG: 14 ---> 0x0000               PHY: 1|REG: 14 ---> 0x0000
PHY: 1|REG: 15 ---> 0x3000               PHY: 1|REG: 15 ---> 0x3000
PHY: 1|REG: 16 ---> 0x8001               PHY: 1|REG: 16 ---> 0x0000 <-- Writable vendor custom register difference
PHY: 1|REG: 17 ---> 0x0000               PHY: 1|REG: 17 ---> 0x0000
PHY: 1|REG: 18 ---> 0x8402               PHY: 1|REG: 18 ---> 0x8402
PHY: 1|REG: 19 ---> 0x1041               PHY: 1|REG: 19 ---> 0x1041
PHY: 1|REG: 20 ---> 0x0000               PHY: 1|REG: 20 ---> 0x0000
PHY: 1|REG: 21 ---> 0x0004               PHY: 1|REG: 21 ---> 0x0004
PHY: 1|REG: 22 ---> 0x0f08               PHY: 1|REG: 22 ---> 0x0f08
PHY: 1|REG: 23 ---> 0x2448               PHY: 1|REG: 23 ---> 0x3048
PHY: 1|REG: 24 ---> 0x0000               PHY: 1|REG: 24 ---> 0x0000
PHY: 1|REG: 25 ---> 0x0000               PHY: 1|REG: 25 ---> 0x0000
PHY: 1|REG: 26 ---> 0x1ac4               PHY: 1|REG: 26 ---> 0x1ac4
PHY: 1|REG: 27 ---> 0x0003               PHY: 1|REG: 27 ---> 0x0003
PHY: 1|REG: 28 ---> 0x210a               PHY: 1|REG: 28 ---> 0x210a
PHY: 1|REG: 29 ---> 0x1855               PHY: 1|REG: 29 ---> 0x1855
PHY: 1|REG: 30 ---> 0x0000               PHY: 1|REG: 30 ---> 0x0000
PHY: 1|REG: 31 ---> 0x4014               PHY: 1|REG: 31 ---> 0xc014
PHY: 1|REG: 32 ---> 0x1140               PHY: 1|REG: 32 ---> 0x1140
PHY: 1|REG: 33 ---> 0x796d               PHY: 1|REG: 33 ---> 0x796d
PHY: 1|REG: 34 ---> 0x0381               PHY: 1|REG: 34 ---> 0x0381
PHY: 1|REG: 35 ---> 0x5c11               PHY: 1|REG: 35 ---> 0x5c11
PHY: 1|REG: 36 ---> 0x11e1               PHY: 1|REG: 36 ---> 0x11e1
PHY: 1|REG: 37 ---> 0xc1e1               PHY: 1|REG: 37 ---> 0xc1e1
PHY: 1|REG: 38 ---> 0x006d               PHY: 1|REG: 38 ---> 0x006d
PHY: 1|REG: 39 ---> 0x2001               PHY: 1|REG: 39 ---> 0x2001
PHY: 1|REG: 40 ---> 0x488e               PHY: 1|REG: 40 ---> 0x6801
PHY: 1|REG: 41 ---> 0x0300               PHY: 1|REG: 41 ---> 0x0300
PHY: 1|REG: 42 ---> 0x3800               PHY: 1|REG: 42 ---> 0x3800
PHY: 1|REG: 43 ---> 0x0000               PHY: 1|REG: 43 ---> 0x0000
PHY: 1|REG: 44 ---> 0x0000               PHY: 1|REG: 44 ---> 0x0000
PHY: 1|REG: 45 ---> 0x0000               PHY: 1|REG: 45 ---> 0x0000
PHY: 1|REG: 46 ---> 0x0000               PHY: 1|REG: 46 ---> 0x0000
PHY: 1|REG: 47 ---> 0x3000               PHY: 1|REG: 47 ---> 0x3000
PHY: 1|REG: 48 ---> 0x8001               PHY: 1|REG: 48 ---> 0x0000
PHY: 1|REG: 49 ---> 0x0000               PHY: 1|REG: 49 ---> 0x0000
PHY: 1|REG: 50 ---> 0x8402               PHY: 1|REG: 50 ---> 0x8402
PHY: 1|REG: 51 ---> 0x1041               PHY: 1|REG: 51 ---> 0x1041
PHY: 1|REG: 52 ---> 0x0000               PHY: 1|REG: 52 ---> 0x0000
PHY: 1|REG: 53 ---> 0x0004               PHY: 1|REG: 53 ---> 0x0004
PHY: 1|REG: 54 ---> 0x0f08               PHY: 1|REG: 54 ---> 0x0f08
PHY: 1|REG: 55 ---> 0x2448               PHY: 1|REG: 55 ---> 0x3048
PHY: 1|REG: 56 ---> 0x0000               PHY: 1|REG: 56 ---> 0x0000
PHY: 1|REG: 57 ---> 0x0000               PHY: 1|REG: 57 ---> 0x0000
PHY: 1|REG: 58 ---> 0x1ac4               PHY: 1|REG: 58 ---> 0x1ac4
PHY: 1|REG: 59 ---> 0x0003               PHY: 1|REG: 59 ---> 0x0003
PHY: 1|REG: 60 ---> 0x210a               PHY: 1|REG: 60 ---> 0x210a
PHY: 1|REG: 61 ---> 0x1855               PHY: 1|REG: 61 ---> 0x1855
PHY: 1|REG: 62 ---> 0x0000               PHY: 1|REG: 62 ---> 0x0000
PHY: 1|REG: 63 ---> 0xc014               PHY: 1|REG: 63 ---> 0x4014

So, I have modified and extended for MMD operation an old tool and cross compiled it for android and armhf

https://github.com/Menion2k/mdio-tool/releases/tag/2.1

This evening I will try to compare PHY configuration between android and Coreelec, assuming that I can make the android version working

Well, I can write a phylib driver, network driver is way more complicated.

I can give a look to the mainline, still I should investigate the dts since now it is required to have a valid mdio phy bindings, that is why I want to work also on the amlogic kernel.

I have written a small application to access MII register via mdio bus, but I need to cross compile with the linaro gcc armhf used by Libreelec, but I am struggling in invoking it due to include directory.

How can use the libreelec compiler to build (with no Makefile) an external executable? (solved)

Well if you engage good relationship with a chinese manufacturer I think they may know how reach out ZTE and ask for a datasheet (or an application note with registers description). It is the same I have asked to the public ZTE contact, but they mostly support networking devices, anyhow they promised me to forward my question to the correct person.

One we have the information I can implement the driver for the PHY.

Anyhow I have some more info. I have found a datasheet of a GMII PHY ksz9031mnx.pdf

This datasheet explain the MMD access and also has a register description of the standard MMD registers!

I think the interesting ones are:

Addr 2h: Reg 4h GMII Control Signal Pad Skrew

Addr 2h: Reg 8h GMII Clock Pad Skrew

The ZTE PHY is a RGMII phy so it is possible that there is something different, but now I have a point where start.

Also, I have seen that in the Amlogic BSP there is a dedicated phy driver directory, with a modified version of the Linux phy driver and a new one.

None of them are compiled in Libreelec/Coreelec but it won't make any difference because there is no driver for the ZTE.

Still there is the chance that Amlogic knows something.

Otherwise the only other option is that the android firmware is doing something in user space, but I don't see any tools installed that can do this

I run iperf3 between the t95z and my access point:

t95z -------> AP

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   254 MBytes   213 Mbits/sec   44             sender
[  5]   0.00-10.03  sec   252 MBytes   211 Mbits/sec                  receiver

AP --------> t95z

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  46.7 KBytes  38.1 Kbits/sec    9             sender
[  5]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  receiver

So, there is a decent speed in TX direction (not even close to 1Gbit but it is probably due to the AP CPU) and just ridiculous in RX direction.

As far as I know if the problem were with EEE, both direction should be slow (right @chewitt ?).

If it is so, it is either the PHY initialization that requires some special handling (like Marvell and some RTL) or it is the RX delay. This in my opinion is more probable, because the same ZTE phy works better on other boards.

In fact the routing of the t95z is crazy: the phy is on the opposite PCB side than the ethernet line transformer and the S912, so the critical line (both ethernet signal and RGMII) must traverse the PCB.

But in both case we need a reference code, or whatever sorcery, they do in android stock firmware, or the datasheet or application note of the phy.

In this amlogic could help, on my side I am waiting news from manufacturer, ZTE replied to my company email promising that someone shall provide info, let's see...