12-15-2018 12:29 PM
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.
02-13-2019 11:56 PM
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, }; /** --
12-23-2018 07:33 AM
According to the wiki:
Missing Features, Known Issues and Limitations
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
12-26-2018 02:45 AM - edited 12-26-2018 03:00 AM
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
12-26-2018 12:09 PM
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 ?
12-27-2018 12:44 AM
01-23-2019 07:49 AM
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...
02-07-2019 07:19 AM
I also seem to have the same problem. Any suggestions are welcome.
02-07-2019 08:00 AM
02-07-2019 09:55 AM
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)
02-12-2019 11:33 AM
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.
02-12-2019 11:36 AM
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.
02-12-2019 10:53 PM
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.
02-12-2019 11:28 PM
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
02-13-2019 11:56 PM
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, }; /** --
02-14-2019 10:00 AM
Power management bugs strike again ! Thanks for sharing !