PROCESSOR-SDK-AM65X: USB problems

user6115282

Intellectual 320 points

Part Number: PROCESSOR-SDK-AM65X

Tool/software: Linux

Hi:

We found the following two problems in using EVM boards

Test environment:

Hardware: AM654X EVM PROCESSOR BOARD (REV 1.0), 8G miscro SD card (Panasonic)
Card reader (PISEN, 川宇C396 , TS-RDF9K)
USB-HUB (Standard Microsystems, Realtek Semiconductor, Ithink)

Software: Processor SDK Linux 06_00_00_07

Q1.
In U-boot, the EVM board connects a certain type of USB HUB and inserts the U disk, some of which can not be recognized.
The test topology is as follows. The EVM board has tested three different manufacturers'USB-HUB.
The first and second types of USB-HUB can be recognized normally, while the third type of USB-HUB has three types of USB-HUB that can not be recognized.

Q2.
The kernel starts with USB and loads the kernel from the card reader SD card (using 川宇C396 card reader).
After booting, USB reset prints appear every other time, as shown below.

over 6 years ago

0 Bin Liu over 6 years ago

TI__Guru**** 169071 points

Hi,

For Q1, please apply the following two U-Boot patches.

Fullscreen 0001-phy-omap-usb2-phy-disable-phy-charger-detect.patch.txt Download

From 671bbdba149cd6a89eaa88b1063163c70ede47c7 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu@ti.com>
Date: Mon, 15 Apr 2019 14:17:54 -0500
Subject: [tiU19.01 PATCH v2 1/2] phy: omap-usb2-phy: disable phy charger detect

AM654x PG1.0 has a silicon bug that D+ is pulled high after POR, which
could cause enumeration failure with some USB hubs.  Disabling the
USB2_PHY Charger Detect function will put D+ into the normal state.

Using property "ti,dis-chg-det-quirk" in the DT usb2-phy node to
enable this workaround for AM654x PG1.0.

Signed-off-by: Bin Liu <b-liu@ti.com>
---
Fixes: LCPD-16195

v2: removed 100ms delay. It is not necessary.
    ti,dis_chg_det_quirk -> ti,dis-chg-det-quirk

 drivers/phy/omap-usb2-phy.c | 33 ++++++++++++++++++++++++++++-----
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/omap-usb2-phy.c b/drivers/phy/omap-usb2-phy.c
index 923f2c105d67..fb96f73a77e0 100644
--- a/drivers/phy/omap-usb2-phy.c
+++ b/drivers/phy/omap-usb2-phy.c
@@ -15,6 +15,7 @@
 #include <syscon.h>
 
 #define OMAP_USB2_CALIBRATE_FALSE_DISCONNECT	BIT(0)
+#define OMAP_USB2_DISABLE_CHG_DET		BIT(1)
 
 #define OMAP_DEV_PHY_PD		BIT(0)
 #define OMAP_USB2_PHY_PD	BIT(28)
@@ -31,6 +32,10 @@
 #define AM654_USB2_VBUS_DET_EN		BIT(5)
 #define AM654_USB2_VBUSVALID_DET_EN	BIT(4)
 
+#define USB2PHY_CHRG_DET		 0x14
+#define USB2PHY_USE_CHG_DET_REG		BIT(29)
+#define USB2PHY_DIS_CHG_DET		BIT(28)
+
 DECLARE_GLOBAL_DATA_PTR;
 
 struct omap_usb2_phy {
@@ -158,6 +163,12 @@ static int omap_usb2_phy_init(struct phy *usb_phy)
 		writel(val, priv->phy_base + USB2PHY_ANA_CONFIG1);
 	}
 
+	if (priv->flags & OMAP_USB2_DISABLE_CHG_DET) {
+		val = readl(priv->phy_base + USB2PHY_CHRG_DET);
+		val |= USB2PHY_USE_CHG_DET_REG | USB2PHY_DIS_CHG_DET;
+		writel(val, priv->phy_base + USB2PHY_CHRG_DET);
+	}
+
 	return 0;
 }
 
@@ -195,13 +206,25 @@ int omap_usb2_phy_probe(struct udevice *dev)
 	if (!data)
 		return -EINVAL;
 
-	if (data->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT) {
-		priv->phy_base = dev_read_addr_ptr(dev);
+	priv->phy_base = dev_read_addr_ptr(dev);
 
-		if (!priv->phy_base)
-			return -EINVAL;
+	if (!priv->phy_base)
+		return -EINVAL;
+
+	if (data->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT)
 		priv->flags |= OMAP_USB2_CALIBRATE_FALSE_DISCONNECT;
-	}
+
+	/*
+	 * AM654x PG1.0 has a silicon bug that D+ is pulled high after
+	 * POR, which could cause enumeration failure with some USB hubs.
+	 * Disabling the USB2_PHY Charger Detect function will put D+
+	 * into the normal state.
+	 *
+	 * Using property "ti,dis-chg-det-quirk" in the DT usb2-phy node
+	 * to enable this workaround for AM654x PG1.0.
+	 */
+	if (dev_read_bool(dev, "ti,dis-chg-det-quirk"))
+		priv->flags |= OMAP_USB2_DISABLE_CHG_DET;
 
 	regmap = syscon_regmap_lookup_by_phandle(dev, "syscon-phy-power");
 	if (!IS_ERR(regmap)) {
-- 
2.17.1

Fullscreen 0002-dts-am65-add-ti-dis-chg-det-quirk-flag-to-usb-phy-no.patch.txt Download

From cbbf0fd50336a13cfb32f3a3fa411c5c92f6755c Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu@ti.com>
Date: Fri, 12 Jul 2019 12:54:37 -0500
Subject: [tiU19.01 PATCH v2 2/2] dts: am65: add ti,dis-chg-det-quirk flag to usb phy nodes

ti,dis_chg_det_quirk is used to disable the Charger Detect logic in the
USB PHY to workaround the silicon bug in PG1.0 which is that D+ is pulled
high in POR causing enumeration failure with some USB hubs.

Signed-off-by: Bin Liu <b-liu@ti.com>
---

 arch/arm/dts/k3-am65-main.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index f76fba2fbabd..c741a5e993a1 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -210,6 +210,7 @@
 		clocks = <&k3_clks 151 0>, <&k3_clks 151 1>;
 		clock-names = "wkupclk", "refclk";
 		#phy-cells = <0>;
+		ti,dis-chg-det-quirk;
 	};
 
 	dwc3_1: dwc3@4020000 {
@@ -247,6 +248,7 @@
 		clocks = <&k3_clks 152 0>, <&k3_clks 152 1>;
 		clock-names = "wkupclk", "refclk";
 		#phy-cells = <0>;
+		ti,dis-chg-det-quirk;
 	};
 
 	main_i2c0: i2c@2000000 {
-- 
2.17.1

You also want to apply the following two kernel patches to solve the same issue in kernel.

Fullscreen 3465.0001-phy-omap-usb2-phy-disable-phy-charger-detect.patch.txt Download

From 9e8d2e0c77f8c2d406308913b3fa9fa1aef59b6f Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu@ti.com>
Date: Fri, 12 Jul 2019 14:14:31 -0500
Subject: [tiL4.19-CON PATCH v2 1/2] phy: omap-usb2-phy: disable phy charger detect

AM654x PG1.0 has a silicon bug that D+ is pulled high after POR, which
could cause enumeration failure with some USB hubs.  Disabling the
USB2_PHY Charger Detect function will put D+ into the normal state.

Using property "ti,dis-chg-det-quirk" in the DT usb2-phy node to
enable this workaround for AM654x PG1.0.

Signed-off-by: Bin Liu <b-liu@ti.com>
---

 drivers/phy/ti/phy-omap-usb2.c | 34 ++++++++++++++++++++++++++++------
 include/linux/phy/omap_usb.h   |  1 +
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/ti/phy-omap-usb2.c b/drivers/phy/ti/phy-omap-usb2.c
index e871f2983a0e..b6c8a0bea9a4 100644
--- a/drivers/phy/ti/phy-omap-usb2.c
+++ b/drivers/phy/ti/phy-omap-usb2.c
@@ -34,8 +34,12 @@
 #include <linux/of_platform.h>
 
 #define USB2PHY_DISCON_BYP_LATCH (1 << 31)
+#define USB2PHY_CHRG_DET 0x14
 #define USB2PHY_ANA_CONFIG1 0x4c
 
+#define USB2PHY_USE_CHG_DET_REG		BIT(29)
+#define USB2PHY_DIS_CHG_DET		BIT(28)
+
 #define AM654_USB2_OTG_PD		BIT(8)
 #define AM654_USB2_VBUS_DET_EN		BIT(5)
 #define AM654_USB2_VBUSVALID_DET_EN	BIT(4)
@@ -194,6 +198,12 @@ static int omap_usb_init(struct phy *x)
 		omap_usb_writel(phy->phy_base, USB2PHY_ANA_CONFIG1, val);
 	}
 
+	if (phy->flags & OMAP_USB2_DISABLE_CHG_DET) {
+		val = omap_usb_readl(phy->phy_base, USB2PHY_CHRG_DET);
+		val |= USB2PHY_USE_CHG_DET_REG | USB2PHY_DIS_CHG_DET;
+		omap_usb_writel(phy->phy_base, USB2PHY_CHRG_DET, val);
+	}
+
 	return 0;
 }
 
@@ -325,13 +335,25 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->power_on		= phy_data->power_on;
 	phy->power_off		= phy_data->power_off;
 
-	if (phy_data->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT) {
-		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-		phy->phy_base = devm_ioremap_resource(&pdev->dev, res);
-		if (IS_ERR(phy->phy_base))
-			return PTR_ERR(phy->phy_base);
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	phy->phy_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(phy->phy_base))
+		return PTR_ERR(phy->phy_base);
+
+	if (phy_data->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT)
 		phy->flags |= OMAP_USB2_CALIBRATE_FALSE_DISCONNECT;
-	}
+
+	/*
+	 * AM654x PG1.0 has a silicon bug that D+ is pulled high after
+	 * POR, which could cause enumeration failure with some USB hubs.
+	 * Disabling the USB2_PHY Charger Detect function will put D+
+	 * into the normal state.
+	 *
+	 * Using property "ti,dis-chg-det-quirk" in the DT usb2-phy node
+	 * to enable this workaround for AM654x PG1.0.
+	 */
+	if (device_property_read_bool(phy->dev, "ti,dis-chg-det-quirk"))
+		phy->flags |= OMAP_USB2_DISABLE_CHG_DET;
 
 	phy->syscon_phy_power = syscon_regmap_lookup_by_phandle(node,
 							"syscon-phy-power");
diff --git a/include/linux/phy/omap_usb.h b/include/linux/phy/omap_usb.h
index 2e5fb870efa9..60557a841a3e 100644
--- a/include/linux/phy/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -66,6 +66,7 @@ struct usb_phy_data {
 #define OMAP_USB2_HAS_START_SRP (1 << 0)
 #define OMAP_USB2_HAS_SET_VBUS (1 << 1)
 #define OMAP_USB2_CALIBRATE_FALSE_DISCONNECT (1 << 2)
+#define OMAP_USB2_DISABLE_CHG_DET (1 << 3)
 
 #define OMAP_DEV_PHY_PD		BIT(0)
 #define OMAP_USB2_PHY_PD	BIT(28)
-- 
2.17.1

Fullscreen 0002-dts-am65-add-ti-dis_chg_det_quirk-flag-to-usb-phy-no.patch.txt Download

From ea0ebc4243f9b1ba5c18f97f5dd5183b78b270d1 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu@ti.com>
Date: Fri, 12 Jul 2019 13:45:26 -0500
Subject: [tiL4.19-CON PATCH v2 2/2] dts: am65: add ti,dis_chg_det_quirk flag to usb phy nodes

ti,dis_chg_det_quirk is used to disable the Charger Detect logic in the
USB PHY to workaround the silicon bug in PG1.0 which is that D+ is pulled
high in POR causing enumeration failure with some USB hubs.

Signed-off-by: Bin Liu <b-liu@ti.com>
---

 arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 93b72d5e2b4c..6f59beedab06 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -1417,6 +1417,7 @@
 		clocks = <&k3_clks 151 0>, <&k3_clks 151 1>;
 		clock-names = "wkupclk", "refclk";
 		#phy-cells = <0>;
+		ti,dis-chg-det-quirk;
 	};
 
 	dwc3_1: dwc3@4020000 {
@@ -1454,6 +1455,7 @@
 		clocks = <&k3_clks 152 0>, <&k3_clks 152 1>;
 		clock-names = "wkupclk", "refclk";
 		#phy-cells = <0>;
+		ti,dis-chg-det-quirk;
 	};
 
 	main_spi0: spi@2100000 {
-- 
2.17.1

After applied the above 4 patches, please re-run your test and let me know if Q2 still happens.

0 user6115282 over 6 years ago in reply to Bin Liu

Intellectual 320 points

Hi,

First of all, thank you very much for your help.

As shown in the figure, (0001-phy-omap-usb2-phy-disable-phy-charger-detect.patch.txt) this should not be the patch of the kernel, right?

0 Bin Liu over 6 years ago in reply to user6115282

TI__Guru**** 169071 points

Hi,

I am sorry for the mistake. Yes, that was not a kernel patch.

I have edited my post above to include the correct patch. Please download it again.

0 user6115282 over 6 years ago in reply to Bin Liu

Intellectual 320 points

Hi,

About Q2, following your steps,After applied the above patches, Q2 still happens.

0 Bin Liu over 6 years ago in reply to user6115282

TI__Guru**** 169071 points

Hi,

You mentioned in Q2 that linux is running from a SD card using 川宇C396 card reader and usb communication failed.

Is any of the 3 hubs mentioned in Q1 used on Q2 test case? If so does the failure happen with all the 3 hubs? Does the issue happen without any usb hub?

Does the issue only happen with this SD card? Or other U-Disks also show the same problem?

0 user6115282 over 6 years ago in reply to Bin Liu

Intellectual 320 points

Hi,

First, Q1 and Q2 are two separate issues.

Q1: We found similar problems on the board using the third type of HUB chip (Standard Microsystems) shown in the figure under U-boot,
so it should be related to the driver of the HUB chip under U-boot.

Q2: We use other brands of card reader or SD card, they will have the probability of Q2 problems, but the use of 川宇 C396 card reader is inevitable.

0 Bin Liu over 6 years ago in reply to user6115282

TI__Guru**** 169071 points

Hi,

I understand the two issues all happened on the same evm, but it would be great to create two separate e2e threads for the two irrelevant issues to avoid any initial confusion.

The reset error could be caused by any SCSI communication error. The log seems indicating the card reader was attached to the USB port prior powering on the evm. Does the reset issue happen if plug in the card reader after the evm is booted?

Does the reset issue happen if you plug in the card reader to the other USB port on the EVM (the port next to the usb-uart port, it should be usb bus #3)?

Does the reset issue happen if you format the SD card on a Linux PC first?

0 user6115282 over 6 years ago in reply to Bin Liu

Intellectual 320 points

Hi,

Yes, as you said, Q1 and Q2 should be asked separately.

About Q2:

1. If the card reader is inserted after startup, the problem will not occur under the Linux terminal, only when the card reader is used as the startup disk.

2. Inserting another USB port has the same problem.

3. Formatting SD card on PC Q2 still happens.

We tracked the kernel code and found that Host sent CBW commands to write SD card logic blocks, but device did not respond, and then the kernel triggered a timeout mechanism to let it reset.

Reset Call trace log:

0 Bin Liu over 6 years ago in reply to user6115282

TI__Guru**** 169071 points

Hi,

Thanks for the detail information.

Can you please try to run 'usb start' command in U-Boot prompt then boot Linux to see if the issue Q2 still happen in Linux?

U-Boot 'usb start' command will trigger the patch before Linux start. This test will tell if Q2 is still related to the known hw issue or not.

0 user6115282 over 6 years ago in reply to Bin Liu

Intellectual 320 points

Hi，

Follow your steps use 'usb start' and the experiment will Q2 still happen.

0 Bin Liu over 6 years ago in reply to user6115282

TI__Guru**** 169071 points

Hi,

Okay, this indicates the issue Q2 is different one.

Can you please attach the full kernel dmesg log? I'd like to check the log of the card reader enumeration. If you use minicom, you can use command 'Ctrl-A L' to capture minicom screen messages to a file.

0 user6115282 over 6 years ago in reply to Bin Liu

Intellectual 320 points

Hello,

1. This issue should have something to do with LPM. I checked this links (the solution should be provided by you), and then modified it according to the method in the links , Q2 'usb reset' did not happen. It should solve the problem of Q2.

link:

http://e2e.ti.com/support/processors/f/791/t/545437

2. Also want to ask, why do you modify it so? Is our board not able to achieve this function?

Thanks.

0 Bin Liu over 6 years ago in reply to user6115282

TI__Guru**** 169071 points

Hi,

Thanks for the update. I am glad the issue is solved.

Regarding the patch, please see the comment for function hub_set_initial_lpm_policy() in the code:

4409 /*
4410 * There are reports of USB 3.0 devices that say they support USB 2.0 Link PM
4411 * when they're plugged into a USB 2.0 port, but they don't work when LPM is
4412 * enabled.
4413 *

Basically the USB 2.0 LPM Addendum is not properly supported by some devices. The Linux driver tries the best to handle it, but I found there are some some cases in which LPM negotiation still causes USB enumeration failure. So simply disabling LPM as what the patch does can solve the issue.

Processors

Processors forum

PROCESSOR-SDK-AM65X: USB problems