imx6ul tja1101(devkit)

[lionelrocher]

Hello,

We made a design using an imx6ul SOM and a TJA1101 evaluation kit (TJA1101AHN).

When linux starts (built with yocto), the phy is detected but when we try to send some data via ethernet. there is none transmitted. We have two identical boards linked.

Could you please check our dts file ?

We are able to give the eth0 interface an ip through ifconfig command.

I attached thereby the dts file and the schematics as well as the dmesg content.

[lionelrocher]

Hi, thank you for your fast answer.

We gave a look at this part of the reference manual and according to it, we have this value :

MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031

We linked RX CLK and TX CLK on our board because we use rmii and we had put the ref clk on TX but from the phy point of view, it should be on RX. We can observe the 25MHz signal on a scope.

The reset signal is kind of weird, it moves from 3,4V to 2,8V but never goes down to zero. We modified our dts to remove internal pull-ups given that there are already external ones on the tja1101 devkit. Another weird signal is the MDIO line which doesn't move except when restarting board (we tried ifconfig eth0 up/down and ip commands) : it stays at 3,3V.

Here is a small extract of our new dts :

pinctrl_enet1: enet1grp {
fsl,pins = <
MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b001 // CRSDV
MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b001 // RX ER
MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b001 // RDAT0
MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b001 // RDAT1
MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b001 // TDAT0
MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b001 // TDAT1
MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0101 //TX EN
MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 // REF CLK
MX6UL_PAD_ENET2_TX_CLK__GPIO2_IO14 0x10001 // RESET
MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x10001 // IRQ
>;
};

pinctrl_enet1_gpio: enet1gpio {
fsl,pins = <
MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15 0x1b0b1 // inh
MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10 0x10001 // enable
MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09 0x1b0b1 // wake
>;
};

pinctrl_enet1_mdc: enet1mdcgrp {
fsl,pins = <
/* mdio */
MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x10000
>;
};

Another point that is unclear is how the interrupt is known by the driver given that it is not mentionned?

The phy_id is not read because the ouput of cat /sys/bus/mdio_bus/devices/20b4000.ethernet-1\:00/phy_id is 0x00000000.

I was not able to find any setup_fec() function and I don't really understand why it would have an impact given that it would be overridden by the kernel once launched.

Thanks again for your help!

[igorpadykov]

>I was not able to find any setup_fec() function and I don't really understand why it

>would have an impact given that it would be overridden by the kernel once launched.

please try nxp offical uboot releases from https://source.codeaurora.org/external/imx/uboot-imx/

repository , it has setup_fec() function.

It sets enet clock direction using IOMUXC_GPR_GPR1 and this is not configured in dts and in kernel.

Best regards
igor

[lionelrocher]

Hi @igorpadykov 

We made a few changes on our hardware : the refclk from our MAC is now soldered where the tja1101 devkit's quartz used to be. We also moved the content of fec2 inside fec1 and the bit 17 of GRP1 is set to 1, the bit 13 is set to 0. Thanks to this, we have the phy_id in our u-boot and kernel ! The driver is printing its message (NXP TJA1101 2188000.ethernet-1:02: attached PHY driver [NXP TJA1101] (mii_bus:phy_add)).

Nonetheless, we did not manage to establish a connection between two boards. Ping is failing (in u-boot and kernel), TX Packets count is not increasing and the TX data lines are not moving on the scope.

After doing the ifconfig eth0 192.168.1.51 command, we can ping itself.

Do you think this comes from our device tree? Here is a snippet :

&fec1 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_enet1>, <&pinctrl_enet1_mdc>, <&pinctrl_enet1_gpio>;
	//phy-reset-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
	//phy-reset-duration = <25>;
	//phy-reset-post-delay = <1>;
	phy-mode = "rmii";
	phy-handle = <&ethphy0>;
	// /delete-property/ phy-supply;
    status = "okay";

	mdio: mdio {
		#address-cells = <1>;
		#size-cells = <0>;

		ethphy0: ethernet-phy@2 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <2>;
			// interrupt-parent = <&gpio2>;
			// interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
			max-speed = <100>;
			tja110x,refclk_in;
			// clocks = <&clks IMX6UL_CLK_ENET_REF>;
			// clock-names = "rmii-ref";
		};
	};
};

pinctrl_enet1: enet1grp {
		fsl,pins = <
			MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN	0x1b0b0 // CRSDV
			MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER	0x1b0b0 // RX ER
			MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00	0x1b0b0 // RDAT0
			MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01	0x1b0b0 // RDAT1
			MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00	0x1b0b0 // TDAT0
			MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01	0x1b0b0 // TDAT1
			MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN	0x1b0b0 //TX EN
			MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1	0x400180f0 // REF CLK
			// MX6UL_PAD_ENET2_TX_CLK__GPIO2_IO14 0x1b0b0 // IRQ
			MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x100b0 // RESET
		>;
	};

	pinctrl_enet1_gpio: enet1gpio {
		fsl,pins = <
			MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15 		0x1b0b1 // inh
			MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10 		0x10001 // enable
			MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09 	0x1b0b1 // wake
		>;
	};

	pinctrl_enet1_mdc: enet1mdcgrp {
		fsl,pins = <
			/* mdio */
			MX6UL_PAD_GPIO1_IO07__ENET1_MDC		0x1b0b0
			MX6UL_PAD_GPIO1_IO06__ENET1_MDIO	0x100b0
		>;
	};

Best regards

[igorpadykov]

Hi

in that case may be recommended to check enet clock (input/output) configuration

(ENET1,2_TX_CLK_DIR register IOMUXC_GPR_GPR1) described in 30.4.2 GPR1 General Purpose Register (IOMUXC_GPR_GPR1)  i.MX 6UltraLite Applications Processor Reference Manual

and uboot example in function setup_fec()

https://source.codeaurora.org/external/imx/uboot-imx/tree/board/freescale/mx6ul_14x14_evk/mx6ul_14x1...

Best regards
igor

[lionelrocher]

Hello Igor,

We modified the value in iomux.h from IOMUX_GPR1_FEC1_CLOCK_MUX1_SEL_MASK (0x1 << 17) to IOMUX_GPR1_FEC1_CLOCK_MUX1_SEL_MASK (0x0 << 17) so it is used by setup_fec(). This modified our REF CLK frequency but it doesn't match our expectations. On the devkit, using jumpers, we asked for 25MHz and we have 50MHz. When we do the contrary (we put jumpers to have 50MHz), we observe a 25MHz clock frequency. In our device tree, we removed the tja11xx,refclk_in line. From the driver and phy point of view, the REF CLK should be out right ? Because there is an oscillator on the board and we follow the model from tja1101ahn figure 4.a.

The phy_id still is 0x00000000 and the mdio line never moves (it stays at 3.3V). The reset line never goes down too, it moves from 2.8V to 3.4V.

How is the driver supposed to be used given that there is no "compatible" keyword?

We added a patch to our yocto to have REF CLK OUT in the tja driver : http://git.embedian.com/developer/smarc-fsl-linux-kernel/commit/3e42c9c4d8a6ece3daccd213a8a9c20e1c70...

While booting, we can do mii commands :

Doing this command makes the mdio line react.

But we had the following message just before interrupting boot :

Net: FEC1 MXC: board_eth_init:failed -12
Board Net Initialization Failed

Any idea?

Regards