[meta-xilinx] Ethernet Issues on Custom Board using PS GEM?

Fri Dec 4 07:35:10 PST 2015

Hi everyone,

Thanks for the timely response! I'm still somewhat new to embedded
programming so there's still a lot to learn. Replies inline below:

On Fri, Dec 4, 2015 at 3:58 AM Nathan Rossi <nathan at nathanrossi.com> wrote:

> On Fri, Dec 4, 2015 at 8:11 AM, Peter Crosthwaite
> <crosthwaitepeter at gmail.com> wrote:
> > On Thu, Dec 3, 2015 at 9:17 AM, Giordon Stark <gstark at cern.ch> wrote:
> >> Hi all,
> >>
> >> We're using a custom board with the ZC706 chip.
> >>
> >> Device Tree is here:
> >>
> https://github.com/kratsg/meta-l1calo/blob/940fa27aa6c9a456ccca7ec60351c26287f9f671/conf/machine/boards/preprototype/system.dts
> >>
> >> Notice that we had to modify it from the dts generated by Xilinx SDK
> since
> >> it didn't have any details about the PHY chip (not sure if that was
> >> intentional or not;
> >>
> https://github.com/kratsg/meta-l1calo/commit/940fa27aa6c9a456ccca7ec60351c26287f9f671
> ).
> >>
> >
> > It is quite intentional. Xilinx SDK can only manages things that are
> > on the chip, which the ethernet phy is not. Anything that is off chip
> > but needs to be in the dts has to be added afterwards or via a dtsi
> > setup.
> >
>

I slightly figured that. I was trying to follow what the ZC706 board
definitions were (eg:
https://github.com/Xilinx/meta-xilinx/blob/master/conf/machine/boards/zc706/zc706-zynq7-board.dtsi#L15-L24)
and I couldn't understand why it was called 'gem0' for me and
'ps7_ethernet_0' for the eval. board. I imagine this is more of a device
tree question which I'm still learning how to read/write. Also, I followed
these instructions (http://www.wiki.xilinx.com/Build+Device+Tree+Blob)
which worked but never really hinted that we had to modify the device tree
after the fact to get it working fully.

> >> Here is the log of the board's bootup:
> >> https://gist.github.com/anonymous/64ab1f335514ff246d14
> >>
> >> Notice line 163
> >> (
> https://gist.github.com/anonymous/64ab1f335514ff246d14#file-gistfile1-txt-L163
> )
> >> and lines 234-238
>
> This is cause of the nesting in the mdio node, macb thinks the 'mdio'
> node is the phy instead of the 'phy' node inside the mdio node. Remove
> the nesting and this should allow for macb to probe the phy correctly.
> (this is the posting you mention further below)
>

This seems very niche/special. Is this mentioned anywhere in Xilinx's
documentation? A lot of what I've found tends to have people citing to wrap
their 'phy' node inside the 'mdio' node -- when I guess what won't work
here. Is there something written about macb somewhere that says this?

>
> On a side note, it appears that it failed to scan for the phy at
> address 0x17, instead it picked up a phy at address 0x07?
> (
> https://gist.github.com/anonymous/64ab1f335514ff246d14#file-gistfile1-txt-L197
> ).
> Might be worth double checking the config pins for you phy to make
> sure that it is configured as expected, or if a secondary phy is also
> on the same mdio bus?
>

We have two marvell PHY chips on the board: one at 0x17 and one at 0x07 (23
and 7). It seems like it was scanning and finding the other PHY chip, which
we had disabled in the firmware which is probably why it wasn't responding.

>
> >> (
> https://gist.github.com/anonymous/64ab1f335514ff246d14#file-gistfile1-txt-L234-L238
> )
> >> seem to point to issues with the ethernet.
> >>
> >
> > I would just grep that message from 163 in kernel source to see why it
> > doesn't like your device tree binding.
> >
> > Regards,
> > Peter
> >
> >> At line 325, we looked at ifconfig
> >> (
> https://gist.github.com/anonymous/64ab1f335514ff246d14#file-gistfile1-txt-L325
> )
> >> which seems like it's showing up.
>
> It appears that it is not getting a link on the phy, if you are not
> confident that the phy is actually working correct (aka you haven't
> validated it, since you are working with a custom board) just do some
> quick checks to make sure the led's for link are lit or that the leds
> on your switch are lit for the link.
>

Definitely confident on the 0x17 that it works and we knew 0x07 wasn't
working. What was interesting is that since 0x17 is GEM0 and 0x07 is GEM1,
when we had done the ethernet echo server test provided by xilinx, it
wasn't able to get past the link speed detection check because it would
hang and wait for a response from GEM1 - even if we had not enabled it in
the firmware yet (eg: modify the BSP to skip 0x07 explicitly).

>
> Its unlikely since the 88e1116r is a straight forward phy but it is
> worth also checking to see if additional register initialization is
> needed for this phy (check with the datasheet), the reg-init dt
> property can do some of the init for you.
>
> Its also worth checking to see if the packets are making it to the
> interface (check the bytes/packet stats in ifconfig). Also install
> ethtool into your image (CORE_IMAGE_EXTRA_INSTALL += "ethtool") and
> determine what the phy's state is, whether it's advertising
> correct/etc. even try forcing the speed/etc if the physical link is
> there (e.g. link light lit on switch).
>

I basically threw up wireshark and wanted to see if I could even see the
board at all. Since I figured that the lack of any packets going out of the
board meant that nothing was getting through the RJ-45 connector, it
implied that the PHY chip still wasn't connected.

>
> >>
> >> Tried assigning an IP address at line 362
> >> (
> https://gist.github.com/anonymous/64ab1f335514ff246d14#file-gistfile1-txt-L362
> ).
> >>
> >> Lines 382-388 show the failed pings
> >> (
> https://gist.github.com/anonymous/64ab1f335514ff246d14#file-gistfile1-txt-L382-L388
> )
> >> - we have the board plugged into a router along with a computer at
> >> 192.168.0.3.
> >>
> >> Closer to the end, we tried restarting the networking interfaces which
> seems
> >> to have failed.
>
> It fails much earlier as well, just hidden with all the early booting
> info:
> https://gist.github.com/anonymous/64ab1f335514ff246d14#file-gistfile1-txt-L242

Ahh, good catch.

>
>
> >>
> >>  I saw a previous posting here with changes that I'm going to try
> applying:
> >>
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2015-April/000959.html
> >> which is the following commit in my project
> >> (
> https://github.com/kratsg/meta-l1calo/commit/69d89d1fc9e2489e90676569c8095509f9167226
> ).
>
> That is how you should set up the phy in your device tree to make it
> work for both the upstream 'macb' driver as well as the linux-xlnx
> 'emacps' driver.
>

This definitely fixed it and now works.

>
> Also macb doesn't handle the 'enet-reset = <&gpio0 51 0>;'. If you
> need to use that GPIO pin to force a hard reset in order for you phy
> to work you may have to look into doing that using some other
> kernel/u-boot/etc feature.
>

Really? That part was autogenerated by Xilinx. I'll ask one of the hardware
engineers about that. Thanks.

>
> Regards,
> Nathan
>
> >>
> >> If anyone has any more information about what's happening, that would be
> >> helpful, thanks!
> >>
> >> Giordon
> >>
> >> --
> >> _______________________________________________
> >> meta-xilinx mailing list
> >> meta-xilinx at yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/meta-xilinx
> >>
> > --
> > _______________________________________________
> > meta-xilinx mailing list
> > meta-xilinx at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20151204/54092f20/attachment.html>