I have two iMX8QP. if I activate imx8qp-apalis-v1.1-ixora-v1.1.dts (torizoncore-builder dt custom, torizoncore-builder union, torizoncore-builder deploy), one board seems to work as expected, the other says no carrier on ethernet.
Once I rollback to an image without specific ixora support, like e.g. 5/apalis-imx8/torizon/torizon-core-docker/nightly ethernet works again.
it’s quite strange… I also switched the ixora boards, same result
Greetings @bearsh,
Just to clarify to make sure I understand the situation. So you’ve isoalted the Ethernet issue to a specific i.MX8QP module?
Correct me if I’m wrong but you’re situation is like this then:
Additionally could you provide the exact versions of Torizon you are working with? Output of cat /etc/issue should suffice.
Also are both the i.MX8QP you have version 1.0B?
Best Regards,
Jeremias
it’s like the following:
the torizon version is 5.1.0-devel-20201125-build.131
regarding the hw version, I think so, according the order confirmation they are both 1.0B (SN 06517961 and 06517962)
Understood.
I did a quick test to reproduce on my setup. I only have 1 i.MX8QP but I was able to reproduce the ethernet issue you described when using an Ixora-based device tree. Seems like we might have a bug here, though it’s interesting you have 1 module where this happens and 1 where it does not. Let me report this as a bug for further investigation and see what the team finds.
In the meantime is there a reason you’re trying to use the Ixora device tree? Or would the evaluation board device tree suffice for now?
Best Regards,
Jeremias
thx @jeremias.tx
Yeah that’s really strange.
What I needed was a quick way to enable a Power-Key (on a GPIO), so I created a dts file which included the imx8-apalis-ixora-v1.1.dtsi and mapped the powerkey to the gpio.
Btw, the doc regarding the Power-Key seems to be slightly outdated, with a current torizoncore build, now udev rule is needed, it works out of the box once the Power-Key is set up in the devicetree
Hi @bearsh,
Thanks for the feedback on GPIO with Linux for Shutdown.
I’ll be adding that in the queue for improving that article.
Best regards,
André
Just to add an update, this has been tricky for us to test since it seems inconsistently reproducible. As you noted only some i.MX8QP modules can recreate this error.
I will say that on the newer revisions of the i.MX8QP we have replaced the ethernet PHY: Apalis iMX8 | Toradex Developer Center
On the newer PHY we haven’t noticed this issue though this doesn’t necessarily mean the issue isn’t present with the newer PHY. But we’d need to do some further testing on the older PHY that runs on the 1.0B to determine if there really is an issue.
Best Regards,
Jeremias
Jeremias
Thank you for your additional comments and information. Given what you said it may be possible this is some kind of instability/issue with the previous Ethernet PHY that we used on the initial QM and QP versions. I have a newer QM with the new PHY and have yet to recreate this issue. While on my QP with the older PHY I can reliably reproduce this.
Strange, I don’t think I’ve had this issue with older BSP versions, but I guess that’s moot since there’s a new hardware version anyway 
Thanks for the feedback.
As a final comment to all of this the R&D team noted that they did notice some issues with auto-negotation turned on with the old PHY. Which would explain why you had some success with your ethtool configurations @SvenAlmgren. Though in general it just seems the old PHY can be rather buggy.
So for now unless we get more information I would this seems to be related to the old PHY and that the ethtool workaround is most likely the best solution on the older PHY.
Best Regards,
Jeremias
I have the same issue with both Apalis iMX8QP 2GB WB V1.0B and Apalis iMX8QM 4GB WB V1.0B.
If I change the PHY settings with ethtool I can sometimes get the ethernet to work, but the only options I’ve seen function have been 10 Mbit half duplex without autoneg, and it only works sometimes, but if I change the settings a couple of times and tries to ping in between I’ve been able to get a response.
ethtool -s eth0 speed 10 duplex half autoneg off
But I’ve only tried to on the QM module, and only a couple of times, but I’ve had the network function at least 3 times with this voodoo 
(I saw the comment from @jeremias.tx that they PHY has changed for newer versions, but I wanted to drop this here in case someone else want to have a go at it)
Cheers / Sven
edit 1: ps. I had full duplex working just now too, but I’ve never gotten a connection with autoneg or speed above 10 Mbit, but that could just be due to luck and some race condition maybe?)
edit 2: okay, 100 mbit half duplex too, I think it’s just a random change of it working when sending commands to the PHY, maybe? I think 100 full could work too, but not sure about autoneg as that would involve more communication later?