[meta-xilinx] ZynqMP - Multiple ETH - Not detected PHY?

[Giordon Stark]

Hi Sandeep,

Thanks for the reply. I suspected this might be the case, but I really
couldn't find anything on Xilinx forums / googling. It's good to hear that
this is planned for 2018.1/3 - do you have a ticket I can subscribe to for
updates or how will this be announced? I assume this requires modifications
to u-boot-xlnx.

Giordon

On Thu, Jan 11, 2018 at 7:39 PM Sandeep Gundlupet Raju <SANDEEPG at xilinx.com>
wrote:

> Hi Giordon,
>
>
>
> Yes you need local mac and phy device-tree property for each GEM.
>
>
>
> We haven’t supported multiple GEM in U-boot. Right now this is planned for
> 2018.1/3.
>
>
>
> If you want to use multiple GEM in linux refer XAPP1305
> http://www.wiki.xilinx.com/PS+and+PL+based+Ethernet+in+Zynq+MPSoC
>
>
>
> *Thanks,*
>
> *Sandeep*
>
>
>
> *From:* meta-xilinx-bounces at yoctoproject.org [mailto:
> meta-xilinx-bounces at yoctoproject.org] *On Behalf Of *Giordon Stark
> *Sent:* Wednesday, January 10, 2018 1:35 AM
> *To:* Oleg K Dzhimiev <oleg at elphel.com>
> *Cc:* meta-xilinx at yoctoproject.org
> *Subject:* Re: [meta-xilinx] ZynqMP - Multiple ETH - Not detected PHY?
>
>
>
> Hi all,
>
>
>
> So I definitely got somewhere, but I think there might be issues with
> u-boot. A patch like this
>
>
>
> +&gem3 {^M
>
> +    local-mac-address = [00 0a 35 00 00 01];
>
> +    phy-handle = <&phy1>;
>
> +    phy1: phy at 7 {
>
> +        reg = <0x7>;
>
> +        ti,rx-internal-delay = <0x8>;
>
> +        ti,tx-internal-delay = <0xa>;
>
> +        ti,fifo-depth = <0x1>;
>
>      };
>
>  };
>
>
>
> works perfectly to get GEM3 working. This also works if I do it for gem2
> (similar, but with the phy address at 0x4). If I use one or the other,
> u-boot doesn't seem to have a problem picking things up and running with
> it... but if I *enable both* GEM2 and GEM3 in my project (since we will
> require two ETH later), I get errors like
>
>
>
> Xilinx Zynq MP First Stage Boot Loader
>
> Release 2017.2   Dec  5 2017  -  15:52:54
>
> NOTICE:  ATF running on XCZU19EG/silicon v3/RTL5.1 at 0xfffea000, with PMU
> firmware
>
> NOTICE:  BL31: Secure code at 0x0
>
> NOTICE:  BL31: Non secure code at 0x8000000
>
> NOTICE:  BL31: v1.3(release):7d1a673
>
> NOTICE:  BL31: Built : 14:42:17, Jan  3 2018
>
> PMUFW:  v0.3
>
>
>
>
>
> U-Boot 2017.01 (Jan 09 2018 - 13:37:43 -0600) gFEX Prototype v3 (ZynqMP
> SoC)
>
>
>
> I2C:   ready
>
> DRAM:  16 GiB
>
> EL Level:       EL2
>
> Chip ID:        xczu19eg
>
> Using default environment
>
>
>
> In:    serial at ff000000
>
> Out:   serial at ff000000
>
> Err:   serial at ff000000
>
> Bootmode: QSPI_MODE
>
> Net:   ZYNQ GEM: ff0d0000, phyaddr 4, interface rgmii-id
>
> i2c_mux_set: could not set mux: id: 5 chip: 74 channel: 0
>
> I2C EEPROM MAC address read failed
>
>
>
> *Warning: ethernet at ff0d0000 (eth0) using random MAC address -
> 12:92:73:12:c0:41*
>
> *eth0: ethernet at ff0d0000ZYNQ GEM: ff0e0000, phyaddr 7, interface rgmii-id*
>
> *PHY is not detected*
>
> *GEM PHY init failed*
>
>
>
> Hit any key to stop autoboot:  0
>
> Invalid bus 0 (err=-19)
>
> Failed to initialize SPI flash at 0:0 (error -19)
>
> *ZynqMP> mdio list*
>
> *eth0:*
>
> *4 - Marvell 88E1118R <--> ethernet at ff0d0000*
>
> *eth1:*
>
> ZynqMP>
>
>
>
> What's strange about this error is that if I enable GEM2 or I enable GEM3
> separately in my project, and change my device tree according, bitbake, and
> then program the flash -- I'm seeing zero problems with the PHY detection.
> It is only when I have *both* PHY enabled that I see a problem. Is this
> an issue with u-boot? The `dhcp` command does work fine in the sense that I
> have a working PHY to send TFTP communications over -- and I haven't booted
> linux yet [and this may not be a problem inside linux, but only inside
> u-boot].
>
>
>
> Thanks,
>
>
>
> Giordon
>
>
>
> eth1:
>
> ZynqMP> dhcp
>
> BOOTP broadcast 1
>
> BOOTP broadcast 2
>
> DHCP client bound to address 192.168.1.123 (279 ms)
>
> *** Warning: no boot file name; using 'C0A8017B.img'
>
> Using ethernet at ff0d0000 device
>
> TFTP from server 0.0.0.0; our IP address is 192.168.1.123; sending through
> gateway 192.168.1.1
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20180111/63124e2f/attachment-0001.html>