I have successfully adapted and booted a pynq image for my board following the Retargeting to a Different Board instruction and modifyng few settings in the petalinux-config Kconfig, as reported in a different thread.
But I don’t have ethernet…
In my hardware the PS has got the ENET0 enabled:
What can I do to fix or at lest debug? My PHY is KSZ8794, it may not be the same as the PYNQ-Z1 or Z2
My boot dump is attached. boot.log (31.3 KB)
My petalinux-config:
internet settings:
dtb image settings:
A scan of the boot log seems to indicate the PHY is not being detected and hence the Ethernet driver is not being loaded. Do you have an entry in the device tree corresponding to the PHY? As a first pass you could try seeing if the one we use for the PYNQ-Z1/2 works - PYNQ/system-user.dtsi at master · Xilinx/PYNQ · GitHub.
Have you had any success with Ethernet in a pure Petalinux environment?
At the beginning, in the image coming out of make BOARDDIR=myBoard, there was no system.dtb in the fat partition, only boot.bin and image.ub, so I think I didn’t have an entry in the device tree.
Then I added the following to the system-user.dtsi:
rebuilt and added the generated system.dtb to the boot partition but no luck.
I fear the PHY specific reset signal may not be released early enough for the zynq to see the IC alive… such an occurrence is mentioned somewhere on the Xilinx forum
Is your reset coming from PS or the board? Looking through the PHY device-tree bindings (linux-xlnx/phy.txt at master · Xilinx/linux-xlnx · GitHub) it looks like you should be able to specify the reset-gpios property to ensure that the reset is deasserted before the chip is probed.
modified the network settings in petalinux-config to “manual”, the log messages: PHY is not detected GEM PHY init failed No ethernet found.
disappeared, but there is still no ethernet. boot2.log (29.3 KB)
what it means? is it a device tree problem, an hardware problem, a driver problem? Has anyone seen something like this? my PHY is a KSZ8794, the device tree (system.dtb dtc to dts to dts.txt because dts files can’t be loaded) is attached and the complete log, too.
Help! boot_log_2019_06_03_02.txt (29.0 KB)system.dts.txt (19.6 KB)
I’m not sure that fixed-link is the correct child node to use in this case - have you tried with a regular phy node instead? It looks from your PS7 config that you are using MDIO to communicate with the PHY which would imply that a phy node should be present in the device tree.
Ok, I will try as you suggest… thank you.
There are two things I must highlight, maybe will make my life and your helping effort easier :
The MDIO bus pins are not externally connected to the PHY, an SPI from PL is used for communication instead, so I should probably remove the setting in the PS7 IP customization
I have got another board, different shape and features but same hardware arrangement, for which I used the PYNQ-Z1 SD image (I believe it was 2.1) and replaced only the three boot partition files, generating them out of petalinux, and worked perfectly… this one instead, didn’t even boot with modified 2.1. Since I now found why this one wasn’t booting (i.e. was looking for bootenv in a non-existing primary flash) maybe I should retry 2.1. modified, just to make sure is not something related with kernel\driver incompatibility after update.
I don’t know if this might be relevant. The truth is I need to get petalinux to acknowledge my PHY as not-MDIO connected… I disabled the MDIO pins in the PS7 customization and I am eagerly waiting for the Vivado implementation to complete.
I finally got it working!
As planned I regenerate the hdf file after disabling MDIO for ENET0 in the PS7 IP Vivado customization panel, and though there is no evidence that it changed anything in the device tree, the bootlog shows the macb finally awake… macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 29 (1e :57:8c:b9:3a:8c) Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixe d-0:00, irq=POLL)
I honestly believe this might be an issue with my board hardware arrangement exploiting a macb driver weakness or bug, because the MDIO bus is scanned nevertheless.
I attach the ultimately successful bootlog, the device tree and a link to the xilinx macb page for future reference
And I’ll ask the web manager to close this thread, as I like to get up from the table as a winner!!! Downloads.zip (15.2 KB)