2018.3 OSL update

[dm78]

Hi,

i'm updating my zynqmp from 2018.2 to 2018.3. I'm using the OSL Flow and Kernel, FSBL, PMUFW, U-Boot are updated. But i have problems with the ATF (V1.5). During U-Boot, the network is working but later with linux, no network interface is available.

Only rolling back ATF to 2018.2 (V1.4) everything is fine.

Has someone a hint for me? The kernel log does not show anything useful.

PS @Xilinx, i'm using the multiple PHYs patch but without modifying it is not applyable for 2018.3. Please update the AR.

[dm78]

According to the wiki:

Missing Features, Known Issues and Limitations

• Linux does not support loopback
• Flow control support is not present in the driver. RX pause frames can be received by the IP but TX pause frame support is not provided.
• External FIFO interface is not supported by the driver - this implementation is DMA based.
• No interrupt support for PHY events in driver. The current implementation relies on polling method for phy event
• No IEEE 1588 support for Zynq as the timestamp implementation in IP is not accurate enough.
• Support for single MAC managing multiple PHYs is not yet merged.
• PS SGMII GT initialization is not supported via zynqmp_phy.c - it needs to be explicitly initialized.
• WOL does not work on warm restart designs because GEM WOL requires an RX BD scratch area that is accessible even during suspend (OCM is used for this) and OCM is secure in this design which is a limitation for this feature.

but the Master AR tells, that this should be solved.

One must be wrong and since the unpatched 2018.3 kernel does not work for me, the Master AR must be wrong (for this entry).

Does anyone have the needed patch for the 2018.3 kernel?

For the ATF, where is still no progress on my side. With V1.4 i got

[    0.625889] macb ff0b0000.ethernet: Not enabling partial store and forward
[    0.626315] libphy: MACB_mii_bus: probed
[    0.690411] PLL: shutdown
[    0.702892] macb ff0b0000.ethernet eth0: Cadence GEM rev 0x50070106 at 0xff0b0000 irq 30 (00:0a:35:01:02:03)
[    0.702898] Micrel KSZ9031 Gigabit PHY ff0b0000.ethernet-ffffffff:03: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=ff0b0000.ethernet-ffffffff:03, irq=POLL)
[    0.703196] macb ff0e0000.ethernet: Not enabling partial store and forward
[    0.703217] macb ff0e0000.ethernet: invalid hw address, using random
[    0.703602] libphy: MACB_mii_bus: probed

for V1.5

[    0.617321] macb ff0b0000.ethernet: Not enabling partial store and forward
[    0.617713] libphy: MACB_mii_bus: probed
[    0.651776] macb ff0e0000.ethernet: Not enabling partial store and forward
[    0.651797] macb ff0e0000.ethernet: invalid hw address, using random
[    0.652140] libphy: MACB_mii_bus: probed
[    0.679434] PLL: shutdown

Both devicetree versions are working with v1.4, but none with v1.5.

&gem0 {
    phy-handle = <&phy3>;
	mdio {
        compatible = "cdns,macb-mdio";
        reg = <0x0 0xff0b0000 0x0 0x1000>;
        clocks = <&clk 31>, <&clk 104>, <&clk 45>;
        clock-names = "pclk", "tx_clk", "hclk";
        #address-cells = <1>;
        #size-cells = <0>;
        phy3: ethernet-phy@3 {
            device_type = "ethernet-phy";
            reg = <3>;
        } ;
        phy7: ethernet-phy@7 {
            device_type = "ethernet-phy";
            reg = <7>;
        };
    };
};

&gem0 {
    phy-handle = <&phy3>;
    phy3: ethernet-phy@3 {
        device_type = "ethernet-phy";
        reg = <3>;
    } ;
};

What else can i try?

thanks

[dm78]

Hi,

i spend some time for the ATF issue and i found differences related to the MDIO, but still no solution. GEM0+34 is the "phy_management (GEM) Register".

With v1.4 reading the PHY ID results in a valid transaction:

[    0.631070] [GEM0 + 34]=618a0000 write
[    0.635067] [GEM0 + 34]=618a0022 read
[    0.635098] macb ff0b0000.ethernet eth0: MACB_BFEXT(DATA, macb_readl(bp, MAN)) = 34
[    0.647067] [GEM0 + 34]=618e0000 write
[    0.651066] [GEM0 + 34]=618e1622 read
[    0.651093] macb ff0b0000.ethernet eth0: MACB_BFEXT(DATA, macb_readl(bp, MAN)) = 5666

whereas with v1.5:

[    0.621790] [GEM0 + 34]=618a0000 write
[    0.625789] [GEM0 + 34]=618bffff read
[    0.625818] macb ff0b0000.ethernet eth0: MACB_BFEXT(DATA, macb_readl(bp, MAN)) = 65535
[    0.637793] [GEM0 + 34]=618e0000 write
[    0.641788] [GEM0 + 34]=618fffff read
[    0.641815] macb ff0b0000.ethernet eth0: MACB_BFEXT(DATA, macb_readl(bp, MAN)) = 65535

the result is not valid.

What has ATF and GEM/MDC/MDIO in common?

Does any one have a hint, what to check next?

thanks

[ottob]

This does not sound like a ATF problem.. You are saying that upgrading everything (Kernel, Device tree, u-boot, FSBL, PMU) to 2018.3 works fine, as long as you keep the ATF at the 2018.2 version ? 

[dm78]

Yes, exactly.

I had to use the PMU created by the SDK instead of the embeddedsw-git repo, but all components except ATF is from 2018.3. I tried with the ATF build by a petalinux 2018.3 project but still no success.
I think too, that ATF is not the root-cause, but i do not know how to proceed (except sticking with ATF at 2018.2).

[barco2]

Did you finally get an idea of the root cause of this issue? I seem to having the same here except that I am not using ATF at all...

[cone83]

I also seem to have the same problem. Any suggestions are welcome.

[barco2]

Hi, I am still using 2018.2 when I need networking. With 2018.3 the Linux macb driver never detected my phy correctly, it always probed a Generic Phy at address 0xc, which of course did not respond. But it never detected the Micrel KSZ9031 I have connected at address 0x3, even when it was correctly defined in the device-tree. However, u-boot worked always correctly, so something got broken with the macb driver in between 2018.2 and 2018.3 I guess...

[ottob]

Side note - When is Xilinx going to put in some time and make the macb driver a properly maintained mac driver ? No VLAN support, SGMI->RMII FPGA block is not supported, as soon as you add a GPIO to the reset control it stops working (due to the fact that the GPIO driver loads much later) 

[cone83]

I think that this is actually related to the Micrel KSZ9031 PHY, as @dm78, @barco2 and me are all using this chip. I have another board with differnet PHY and an almost identical PetaLinux project and that has no problem with ethernet.

So I think the real solution would be to patch the Micrel driver, which must be doing something that doesn't work with the new ATF.

[cone83]

Also one more note: I don't think that it's related to using multiply PHYs. I also have two PHYs at the same MDIO line (its an Enclustra Mercury+ XU1 SOM), but the problem also occurs when deactivating one Ethernet interface.

[dm78]

Hi and sorry for the delay.

I did not work on this problem, since i've a workaround by using ATF v1.4. Nevertheless Xilinx managed to provide a patch for the multiple phy issue. See AR above.

[cone83]

For me this work-around doesn't function as my system refuses to boot with an older ATF. I get the following boot logs:

...
[    2.218641] Key type id_resolver registered
[    2.222778] Key type id_legacy registered
[    2.226761] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    2.233429] jffs2: version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.
[    2.265706] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247)
[    2.267464] io scheduler noop registered
[    2.271343] io scheduler deadline registered
[    2.275600] io scheduler cfq registered (default)
[    2.280258] io scheduler mq-deadline registered
[    2.284755] io scheduler kyber registered
[   23.303374] INFO: rcu_sched detected stalls on CPUs/tasks:
[   23.303414]  2-...: (1 GPs behind) idle=d16/140000000000000/0 softirq=811/811 fqs=2626 
[   23.311169]  (detected by 3, t=5253 jiffies, g=-235, c=-236, q=215)
[   23.317398] Task dump for CPU 2:
[   23.320599] swapper/0       R  running task        0     1      0 0x00000002
[   23.327605] Call trace:
[   23.330035] [<ffffff8008085878>] __switch_to+0x98/0xb0
[   23.335132] [<ffffffc06db0dc10>] 0xffffffc06db0dc10

[cone83 · Accepted solution]

A colleague of mine has found the cause: in ATF 1.5 they did some changes related to clock gating for GEM. He created a patch that seems to work:

---
 plat/xilinx/zynqmp/pm_service/pm_api_clock.c | 40 ++++++++++----------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/plat/xilinx/zynqmp/pm_service/pm_api_clock.c b/plat/xilinx/zynqmp/pm_service/pm_api_clock.c
index bef7bd73..835d3d79 100644
--- a/plat/xilinx/zynqmp/pm_service/pm_api_clock.c
+++ b/plat/xilinx/zynqmp/pm_service/pm_api_clock.c
@@ -2343,26 +2343,26 @@ static struct pm_ext_clock ext_clocks[] = {
 
 /* Array of clock which are invalid for this variant */
 static uint32_t pm_clk_invalid_list[] = {CLK_USB0, CLK_USB1, CLK_CSU_SPB,
-	CLK_ACPU_FULL,
-	CLK_ACPU_HALF,
-	CLK_APLL_TO_LPD,
-	CLK_DBG_FPD,
-	CLK_DBG_LPD,
-	CLK_DBG_TRACE,
-	CLK_DBG_TSTMP,
-	CLK_DDR_REF,
-	CLK_TOPSW_MAIN,
-	CLK_GTGREF0_REF,
-	CLK_LPD_SWITCH,
-	CLK_LPD_LSBUS,
-	CLK_CPU_R5,
-	CLK_CPU_R5_CORE,
-	CLK_CSU_SPB,
-	CLK_CSU_PLL,
-	CLK_PCAP,
-	CLK_IOU_SWITCH,
-	CLK_DLL_REF,
-	CLK_TIMESTAMP_REF,
+	//CLK_ACPU_FULL,
+	//CLK_ACPU_HALF,
+	//CLK_APLL_TO_LPD,
+	//CLK_DBG_FPD,
+	//CLK_DBG_LPD,
+	//CLK_DBG_TRACE,
+	//CLK_DBG_TSTMP,
+	//CLK_DDR_REF,
+	//CLK_TOPSW_MAIN,
+	//CLK_GTGREF0_REF,
+	//CLK_LPD_SWITCH,
+	//CLK_LPD_LSBUS,
+	//CLK_CPU_R5,
+	//CLK_CPU_R5_CORE,
+	//CLK_CSU_SPB,
+	//CLK_CSU_PLL,
+	//CLK_PCAP,
+	//CLK_IOU_SWITCH,
+	//CLK_DLL_REF,
+	//CLK_TIMESTAMP_REF,
 };
 
 /**
-- 

[ottob]

Power management bugs strike again ! Thanks for sharing !