Hi - I am currently bringing up a new CPU card we designed that uses the i.MX6 SoloX processor.
The card utilizes an USB3503 HSIC USB to meet the design requirement of 3 native USB channels. The USB3503, as stated, connects vis High-speed inter chip (HSIC) communications to the i.MX6 SoloX processor and we are running the 4.9.11 variant of the Linux kernel modified by NXP to run on their processors. In addition to the HSIC connection, there is a 24MHz reference clock running from a GPIO pin of the Solo X to the REFCLK input of the USB3503. The clock is sourced from the internal clock domains of the NXP processor. Lastly, there is an I2C connection from the Solo X to the USB3503 for configuration and control of the device. Details of the design and implementation are below.
Linux device tree: The pertinent bits of the Linux device tree are listed below.
I2C (includes RST# signal):
&i2c4 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c4>;
status = "okay";
/*This is the I2C connection to the USB3503 Hub. It is used for configuration
of the part only. Currently the only parts of this configuation mechanism used
are to disable ports 1 and 2 of the hub. The usbh USB<->HSIC bridge node defined
below (&usbh) is the interface for the high-speed USB communications over HSIC
to the SoloX microprocessor*/
usb3503@08 {
compatible = "smsc,usb3503";
reg = <0x08>;
disabled-ports = <1 2>;
reset-gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
initial-mode = <1>;
clocks = <&clks IMX6SX_CLK_OSC>;
clock-names = "refclk";
refclk-frequency = <24000000>;
};
};
pinctrl_i2c4: i2c4grp {
fsl,pins = <
MX6SX_PAD_SD2_DATA1__I2C4_SCL 0x4001b8b0
MX6SX_PAD_SD2_DATA0__I2C4_SDA 0x4001b8b0
>;
};
Clock/Reset:
pinctrl_hog: hoggrp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO12__CCM_CLKO2 0x000B0
MX6SX_PAD_SD4_CMD__GPIO6_IO_13 0xE0B0
>;
};
HSIC:
&usbh {
compatible = "fsl,imx6sx-usb";
pinctrl-names = "idle", "active";
pinctrl-0 = <&pinctrl_usbh_1>;
osc-clkgate-delay = <0x3>;
pad-supply = <&swbst_reg>;
phy_type = "hsic";
dr_mode = "host";
status = "okay";
usb_hub: usb-hub {
compatible = "smsc,usb3503";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbhub>;
clocks = <&clks IMX6SX_CLK_OSC>;
reset-gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
clock-names = "refclk";
assigned-clocks = <&clks IMX6SX_CLK_CKO2_SEL>,<&clks IMX6SX_CLK_CKO2>;
assigned-clock-parents = <&clks IMX6SX_CLK_OSC>;
assigned-clock-rates = <0>, <24000000>;
};
};
pinctrl_usbh_1: usbhgrp-1 {
fsl,pins = <
MX6SX_PAD_USB_H_STROBE__USB_H_STROBE 0x00081030
MX6SX_PAD_USB_H_DATA__USB_H_DATA 0x00080030
>;
};
pinctrl_usbhub: usbhub_rst {
fsl,pins = <
MX6SX_PAD_SD4_CMD__GPIO6_IO_13 0xE0B0
>;
};
Schematic:
Linux boot log:
When everything is running properly, from POR, we see the pertinent outputs from the Linux boot log:
I2C communications with USB3503:
usb3503 3-0008: switched to HUB mode
usb3503 3-0008: usb3503_probe: probed in hub mode
HSIC communications with USB3503:
usb 3-1: new high-speed USB device number 2 using ci_hdrc
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 1 port detected
**Please note – these messages would not appear if REFCLK was not being correctly clocked @ 24MHz.
At this point a USB mass storage device can be inserted, and Linux will see the device:
# usb 3-1.1: new high-speed USB device number 3 using ci_hdrc
usb-storage 3-1.1:1.0: USB Mass Storage device detected
usb-storage 3-1.1:1.0: Quirks match for vid 4146 pid ba01: 80
scsi host0: usb-storage 3-1.1:1.0
scsi 0:0:0:0: Direct-Access Pretec 256MB Tiny 1.00 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 512000 512-byte logical blocks: (262 MB/250 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Asking for cache data failed
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
Issue Statement: The desired behavior outlined above is not achieved if a soft reset of the device is performed. This is accomplished from a ‘reboot’ command at the Linux command line:
# reboot
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processesci_hdrc ci_hdrc.2: remove, state 1
usb usb3: USB disconnect, device number 1
usb 3-1: USB disconnect, device number 2
usb 3-1.1: USB disconnect, device number 3
ci_hdrc ci_hdrc.2: USB bus 3 deregistered
ci_hdrc ci_hdrc.1: remove, state 4
usb usb2: USB disconnect, device number 1
ci_hdrc ci_hdrc.1: USB bus 2 deregistered
ci_hdrc ci_hdrc.0: remove, state 4
usb usb1: USB disconnect, device number 1
ci_hdrc ci_hdrc.0: USB bus 1 deregistered
reboot: Restarting system
U-Boot 2017.03 (Dec 10 2020 - 14:21:32 -0600)
CPU: Freescale i.MX6SX rev1.4 at 792MHz
CPU: Industrial temperature grade (-40C to 105C) at 39C
Reset cause: WDOG
Model: CPU Board running NXP i.MX6 SoloX. DTS file vers 0.45
Board: MX6SX v2 CPU
I2C: ready
DRAM: 512 MiB
MMC: FSL_SDHC: 0
In: serial
Out: serial
Err: serial
Init function board_late_mmc_env_init() running
It can be seen from the boot log that the device is now unable to talk via I2C:
I2C:
usb3503 3-0008: SP_ILOCK failed (-6)
usb3503 3-0008: usb3503_probe: probed in hub mode
HSIC:
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 1 port detected
usb 3-1: new high-speed USB device number 2 using ci_hdrc
usb 3-1: device no response, device descriptor read/64, error -71
usb 3-1: device no response, device descriptor read/64, error -71
usb 3-1: device no response, device descriptor read/64, error -71
usb 3-1: device no response, device descriptor read/64, error -71
usb 3-1: device not accepting address 4, error -71
usb 3-1: new high-speed USB device number 5 using ci_hdrc
usb 3-1: device not accepting address 5, error -71
usb usb3-port1: unable to enumerate USB device
Plugging the same USB Mass storage device into the board yields no result (the drive is not recognized).
HW Analysis: At this point it was determined to measure the HW signals going to and from the USB3503 during POR and soft reset to determine if any differences could be detected. REFCLK, RST#, I2C SDA/SCL and HSIC STROBE/DATA were all measured. The only differences noted between POR and soft reset were on the HSIC signals. Therefore, for brevity, oscilloscope captures of the other signals will not be listed. PLEASE NOTE: measurements taken with a long timebase do not have good fidelity of the HSIC STROBE and DATA signals because of the limitations of the instruments being used. The measurement device was a Tektronix MDO3104 Mixed-Domain Oscilloscope with 1GHz bandwidth.
POR:
On POR, the HSIC STROBE comes high (low to high) when the Linux kernel starts (a few seconds after POR):
After this Low to High transition, the STROBE and DATA lines begin toggling and talking as they should – note this is a ‘zoomed in’ view of the STROBE/DATA lines from above:
Soft Reset:
However, when a soft reboot is performed, the STROBE line never goes low, which we believe results in the errant behavior, as it is the only HW difference between POR and soft reset. It attempts to communicate via HSIC when the kernel starts as it does above, but then gives up and is just a “flat line” with the STROBE high, and the DATA low:
It appears that STROBE is weakly latched high after a SoloX soft reboot. Briefly connecting a 100k PD after the Linux CLI soft reboot, but prior to the kernel attempting HSIC comms, results in drive recognition.
Is there a patch that can be made to uboot to force the STROBE signal low, so that it properly recognizes the USB3503? I have read other threads that show issues connecting to the USB3503, and have tried the solutions mentioned there without success. Also, I have tried different combinations of the iomux configuration for the HSIC STROBE and DATA signals in the device tree.
thanks for looking.
kind regards
Chad Wolter
