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

Sat Dec 5 00:38:21 PST 2015

On Sat, Dec 5, 2015 at 1:35 AM, Giordon Stark <kratsg at gmail.com> wrote:
> 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.

The 'gem0' and 'ps7_ethernet_0' are just names, the original
iterations of device-trees for Zynq used the 'ps7_*' naming scheme
compared to the upstream device trees in the linux kernel (e.g. gem0).
Unfortunately the Zynq platform has had a troubled past when it comes
to device tree bindings, however since making its way into the kernel
source it has become much more stable, if you want to pick one naming
scheme use the kernels 'gem0'/etc. scheme.

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

This is something that only macb seems to do, its not the standard way
of handling phy's with device-trees. I have been meaning to send a
patch so that macb can use the phy-handle property, just haven't had a
chance to get to it :(.

For reference you can find the binding documentation for macb in the
kernel http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/net/macb.txt,
however some times you will have to look at the code to understand
what some drivers use for properties/etc
(http://lxr.free-electrons.com/source/drivers/net/ethernet/cadence/macb.c).

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

Good to hear.

Regards,
Nathan

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