i.MX 8QuadMax USB HSIC Functionality

[marcelziswiler]

While earlier we always required some additional HSIC patches from you we are glad that NXP BSP L5.4.70_2.3.0 seems to have those already integrated now. However, for us HSIC functionality is still rather flaky with frequent error spews upon boot as follows:

[ 3.957412] usb 3-1: device no response, device descriptor read/64, error -71
[ 4.209389] usb 3-1: device no response, device descriptor read/64, error -71

This is with HSIC routed to a Microchip (formerly SMSC) USB3503A. Our design has been carefully checked and this production lot has even been X-rayed to make sure everything is really properly soldered. Full log file attached.

Could we know how exactly and on which exact hardware NXP has validated HSIC on the i.MX 8QuadMax?

Any further assistance you could give us in this matter is greatly appreciated, thanks!

[marcelziswiler]

Looks like NXP is unable to answer any of our questions!

[jamesbone]

All our SW Efforts are made for the i.MX8QuadMax MEK board.

https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-8quadmax-m...

[marcelziswiler]

> All our SW Efforts are made for the i.MX8QuadMax MEK board.

Hm, but the i.MX8QuadMax MEK board does NOT have any HSIC available as far as I can tell. So you mean this functionality has NOT been validated at all!?

[fmonte]

Hi, we have a design based on mx8qm-mek with HSIC. We did not notice such errors, and everything works fine.

Have you double checked the design?

[marcelziswiler]

Looking through RM_Rev_F I stumbled over the following however, double-checking L5.4.70_2.3.0 this does not seem to be used anywhere and the RM anyway just says TODO!?

9.2.5.1.225 IOMUXD_CALIBRATION_0_HSIC (IOMUXD_CALIBRATION_0_HSIC)

9.2.5.1.226 IOMUXD_CALIBRATION_1_HSIC (IOMUXD_CALIBRATION_1_HSIC)

I guess the RM leaves more to desire:

9.2.5.1.227 na (iomuxd_group_2_5)

Maybe this is a wake-up call?

Any insight on this which may help us?

[marcelziswiler]

> we have a design based on mx8qm-mek with HSIC. We did not notice such errors, and everything works fine.

OK, could you reveal details (e.g. schematics maybe even layout and kernel configuration and device tree)?

> Have you double checked the design?

Yes, as mentioned in my question we double/triple-checked everything. While some devices are pretty good others fail all the time, especially at higher temperatures. So there is some big variance we are seeing.

[fmonte]

This is the device tree relevant part:

pinctrl_usbh1: usbh1grp {
	fsl,pins = <
		SC_P_USB_HSIC0_DATA_CONN_USB_HSIC0_DATA		0x000000CF
		SC_P_USB_HSIC0_STROBE_CONN_USB_HSIC0_STROBE	0x000000CF
	>;
};

pinctrl_usbh1_active: usbh1activegrp {
	fsl,pins = <
		SC_P_USB_HSIC0_DATA_CONN_USB_HSIC0_DATA		0x000000CF
		SC_P_USB_HSIC0_STROBE_CONN_USB_HSIC0_STROBE	0x000000FF
	>;
};

&usbh1 {
	isable-over-current;
	pad-supply = <&reg_usb_hsic>;
	osc-clkgate-delay = <0x3>;
	pinctrl-names = "idle", "active";
	pinctrl-0 = <&pinctrl_usbh1>;
	pinctrl-1 = <&pinctrl_usbh1_active>;
	interrupt-parent = <&gic>;
	srp-disable;
	hnp-disable;
	adp-disable;
	vbus-supply = <&reg_usb>;
	status = "okay";
};

It's pretty standard btw. Regarding the schematics or the layout, I cannot share them, I'm sorry.

[marcelziswiler]

@fmonte Thank you very much! Looks like your pinmux settings work wonders and it is now very robust in our design as well. Turns out them settings we were using so far came from some initial NXP device trees years back and likely have not been validated at all!

@jamesbone We would still love to get some more answers from NXP to our open questions. Let me summarise those:

1. Could we know how exactly and on which exact hardware NXP has validated HSIC on the i.MX 8QuadMax?
2. Has the HSIC functionality been validated at all!?
3. RM_Rev_F has TODOs resp. unclear documentation in section 9.2.5.1.225, 9.2.5.1.226 and 9.2.5.1.227. Could you please clarify?
4. What are NXP's recommended HSIC pinmux settings?

Thanks!

[marcelziswiler]

NXP dare to comment?