Posts by Menion

    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....

    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

    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


    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


    Code
    [ 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


    Code
    [ 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...