On initial inspection I don’t see anything immediately wrong. I’m not too familiar with the fixed-link node you are using. But it seems to be a valid node according to the documentation I can find. Other than that it seems like your settings/configurations for fec2 more or less mirror what we have in fec1 so that should be fine. Other than this the only thing to make sure is that the pins in pinctrl_fec2 aren’t being used for other interfaces or subsystems.
Though now that I look at your pinctrl_fec node I believe the syntax with the node isn’t correct. You’re calling a node with the panhandle &pinctrl this only works if there’s an existing node in the device tree somewhere with the panhandle pinctrl. This isn’t what you’re trying to do, you’re trying to define a brand new pinctrl node.
I updated the overlay with the suggestions in the referenced question. I am still getting a syntax error at the colibri-imx8qxp line. I copied the header file to the directory the dts file is in. I’m running the c preprocessor on it before the device tree compiler. Is this the correct way to compile this overlay? Am I adding the pinctrl group correctly?
`
How I’m compiling
cpp -nostdinc -I include -I arch -undef -x assembler-with-cpp eth2_enable.dts eth2_enable.dts.preprocess
dtc -o eth2_enable.dtbo eth2_enable.dts.preprocessed
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
// Enable the ETH2 interface
Notice the difference in how you organized your colibri-imx8qxp node?
Also why did you assign your pinctrl_fec2 node to the pinctrl-0 of iomuxc? You’re already assigning it to fec2. Plus you copied pinctrl_test to pinctrl-0 of iomuxc, this node doesn’t exist in your setup, this only exists in the context of the other thread.
I’ve updated the pin control group with the feedback in the previous post. It compiles now but when I check ethernet@5b050000 in the /proc directory it is still showing the status as disabled. I followed the instructions here Device Tree Overlays on Torizon | Toradex Developer Center.
I am not sure about the hex values listed after the pins in the pin ctrl group. I used an example from another forum post to set those. Are those the correct values?
I see you have other overlays applied related to parallel RGB and such. I’m fairly sure some of the pins used in the parallel RGB interface are being used in your 2nd Ethernet interface. You might be experiencing a pin conflict in that case since 2 interfaces are requesting the same pin(s). This can cause the affected systems to behave unpredictably or just not work at all.
You need to either resolve the conflict by not using conflicting pins or disable one of the interfaces so there is no conflict over pins.
I removed all of the other overlays except for one we are using to activate CAN1. The pinout designer says there are no conflicts with the can overlay. If there are pin conflicts shouldn’t the status still be changed?
Just to clarify is there anything actually on the other end of this Ethernet interface? Looking at your overlay it seems like you defined and configured the interface but didn’t specify any devices on that interface.
I don’t know if the interface will just show up as enabled or do anything if there’s nothing on it.
I had an ethernet cable pulled into the interface if that is what you are asking.
Could you clarify what you mean by this? Do you have a custom carrier board that has a Ethernet PHY or something similar hooked up to the pins of this second interface? The interface on it’s own doesn’t do much unless it’s hooked up to something.
Even if nothing is plugged in the status should still be set to okay for ethernet@5b050000 shouldn’t it?
This largely depends on the behavior of the software driver and what it considers “okay” for status. Since you’re not seeing any logs in dmesg related to fec2 this leads me to believe nothing is happening on this interface which is why I’m asking about your hardware configuration.
I imagine your desired use-case is similar to what we have on the fec1 node by default. Of course you’ll need to adjust this based on the actual parameters of your specific PHY.
Finally I was comparing your pinctrl group to the one used for fec1:
The pinmuxing values after each pin are a bit different than what you have for your pinctrl group.
In summary I would suggest to try and model your fec2 node and pinctrl group to closer resemble the pre-existing fec1 node since it seems your hardware use-case is similar enough. That and we know fec1 works properly as is.
I am not sure how to handle the naming in the mdio section. Would I increment the values from the mdio section of fec1 like ethphy1: ethernet-phy@3 or are those values set somewhere else? Will the reg value be incremented so it would be reg = <3>?
I have undated the pinmuxing values in the pinctrl group to match whats in pinctrl_fec1.
Would I increment the values from the mdio section of fec1 like ethphy1: ethernet-phy@3 or are those values set somewhere else? Will the reg value be incremented so it would be reg = <3>?
The numbers pertain to the PHY’s address on the MDIO interface. For example our PHY on fec1 has an address of “00010” (in binary) which is translates to “2” (in decimal) that you see in the device tree. Earlier you mentioned your PHY has an address of 00001 which is just 1.
I have updated the overlay with some of the suggestions from previous posts and the ones referenced. I have attached if to review. The pinmux values match fec1 now. I am still not seeing anything when I run dmesg | grep eth for a second ethernet interface.
Do I need to do anything for the power pin? I noticed them referenced in fec1 and in one of the other posts and added them but I’m not sure what else needs to be done. eth2_enable.dts (1.7 KB)
