ethernet interface regression

[bvacaliuc]

As of f58523c, the KSZ9893R switch was recognized and working. As of 395540b, it is not (NOTE: this is not the first change, but rather a change). It appears the SPI bus no longer operates. The differences between a working and not-working configuration is confined to the .dtb file as shown:

imx6q-iris2-R1-good-vs-bad.txt

[bvacaliuc]

The first observation is the introduction of HDMI-supply, and how that re-orders the rest of the handles:

$ diff -s /mnt/imx6q-iris2-R1.dts /mnt/imx6q-iris2-R1-bad.dts
295a296
>                       HDMI-supply = <0xd>;
302c303
<                       dmas = <0xd 0x2 0x19 0x0>;
---
>                       dmas = <0xe 0x2 0x19 0x0>;
314c315
<                       pinctrl-0 = <0xe>;
---
>                       pinctrl-0 = <0xf>;

[bvacaliuc]

The above seems to have made it work, except that there are still alot of differences in the resulting .dts

[bvacaliuc]

the above still seems to work

[bvacaliuc]

So it would seem that the offending line was:

&hdmi_video {
	fsl,phy_reg_vlev = <0x0294>;
	fsl,phy_reg_cksymtx = <0x800d>;
	HDMI-supply = <&reg_usb_h1_vbus>; /* <<< this broke ethernet */
	status = "okay";
};

I'll bet what is happening is that at startup while the ethernet is communicating the above supply is cycled causing the KSZ9893R switch to reset, and spoils its communication.

[bvacaliuc]

But more testing shows that all this .dtb file manipulation was a red herring in that there are times in which even the "apparently working" file fails. Failure is defined as the KSZ9897 driver attempts to identify the device ID register, gets back 0x0 and bails out of loading.

Since in the Iris 2, the RGMII ingress delay (see: uvdl/meta-ornl#3 (comment)) is required on the switch side, this effectively prevents ethernet operations from the CPU to the switch.

[bvacaliuc]

I have determined that using this kernel: 5ff1e5c results in a kernel that loads the KSZ9897 driver ok but when accessing the SPI bus (to set the needed RGMII ingress delay) it hangs the process.

[bvacaliuc]

However, if the .dts is extracted from the .dtb, and this text is added:

2400a2401,2411
>
>       gpio-keys {
>               compatible = "gpio-keys";
>
>               user {
>                       label = "User";
>                       gpios = < 0x0c 0x0a 0x01 >;
>                       linux,code = < 0x100 >;
>                       gpio-key,wakeup;
>               };
>       };

Then, writing the KSZ9893 register via the SPI bus does not hang, and the ethernet interface works as desired.

[bvacaliuc]

I confirm that an overnight test of 365 power on cycles produced 365 successful programs of the KSZ9893 switch to set the RGMII ingress delay.

The question now remains as to why this gpio-keys setting on this particular GPIO line (gpio5[10]) has this effect on the spi-ksz9897 driver.

[bvacaliuc]

I confirm that the yocto image built from uvdl/yocto-ornl@5d1f2b8 has the same behavior. Both bad and good (following the applied workaround).

[bvacaliuc]

on 07/30/2019, Bogdan Vacaliuc wrote:

From "3.1. DART MX6 Connector Pin out" from the datasheet version 2.7 (12/05/2019), it defines some types as I, O and IO. There are several pins that are listed as I or O and we would like to use them as IO. We have the following experience:

J1.20, CAN2_RX, I, FlexCAN-2, GPIO4[15], AC7 - we use this successfully as an output
J1.39, UART3_CTS, O, UART3 port, GPIO3[23], K24
J3.29, SPDIFIN, I, SPDIF, GPIO3[21], K29
J3.31, SPDIFOUT, O, SPDIFIN, GPIO3[22], K28
J3.48, ENET_MDC, O, Gigabit Ethernet, GPIO1[31], AJ21 - we use this as an IEEE1588 input but the switch we have populated cannot drive the signal
J3.56, DISP0_DAT0, O, LCD Data, GPIO4[21], AH29
J3.63, DISP0_DAT16, IO, LCD Data, GPIO5[10], AB24 - we use this for an external GPIO and observe an anomaly (* see below)

We currently have N/C on J1.39, J3.29, J3.31, J3.56, but we would like to use them for GPIO IO. Are there directional buffers on the DART that define the type as I or O as listed in the table? If so, can you verify the accuracy of all pins in the version 2.7 table (since we definitely use J1.20 as an output successfully).

Finally, we are seeing a very strange behavior regarding J3.63/GPIO5[10]. We wanted to use this as an output. Our kernel configuration defined a gpio-key input for this GPIO. We found that if we removed the gpio-key so that we could use the sysfs GPIO, our SPI bus suffered from hangups in our driver code (even though at boot up, the driver correctly identified the chip ID and loaded successfully). We are still diagnosing this issue, but it would be helpful to know if you have any experience with this pin being special in any way.

on 01/08/2019, Aviad Hadad/Variscite, LTD. wrote:

The pins listed above are routed directly to from CPU to SOM connector, GPIO numbers are as you listed. You should verify you are defining these pins as GPIOs correctly in the device tree and disabling/removing current configuration of these pins if they exist. Please refer to our wiki page: http://variwiki.com/index.php?title=VAR-SOM-MX6_GPIO

[bvacaliuc]

confirm this remains a problem without the gpio-keys entry