We have an embedded system using Jetson TX2 SOM and running Yocto Linux based on meta-tegra.
Originally we use two ports, SS#0 and SS#1 in our application:
The port 0:
C43 – USB_SS0_TX+
C44 – USB_SS0_TX-
F43 – USB_SS0_RX+
F44 – USB_SS0_RX-
The port 1:
D42 – USB_SS1_TX+
D43 – USB_SS1_TX-
G42 – USB_SS1_RX+
G43 – USB_SS1_RX-
There ports worked until recently as USB3 SuperSpeed.
After updating meta-layers (including meta-tegra and some others), the SS#1 port stopped working as USB3, and now only works as USB2, and even if we downgrade back the Yocto, the change is irreversible, and does not restore the USB3 functionality of the SS#1 port. I mean even if I install back the “working” Yocto image, where this functionality was definitely there, it does not work still. This is tested on more then one device, so it is definitely not some peculiarity or a specific hardware.
After a bit of digging, I saw in the technical reference manual, p. 3371, that the USB3 functionality can be activated separately for each port via the XUSB_PADCTL_SS_PORT_CAP_0 register, in particular the XUSB_PADCTL_SS_PORT_CAP_0[PORT1_CAP] is USB SS setting for port 1 and XUSB_PADCTL_SS_PORT_CAP_0[PORT0_CAP] is USB SS setting for port 0.
The question is how to activate SuperSpeed functionality on the specific USB port (USB PORT1, SS#1)?
Did not find any information where this is done. Need to enable USB3 functionality on the SS lines.
Can I somehow check what functionality (USB3/USB2) port provides?
Is it possible to write to the XUSB_PADCTL_SS_PORT_CAP_0 register directly or somehow check their content?
Where USB is initialialized during the boot process and what makes change irreversible?
In Yocto, the ODMDATA value is set in different places. One needs to make sure the “correct” value does overrule default one in all the places. That was exactly the problem in our case.
Although in our recipe we were using the correct value, wrong ODMDATA value was used in the u-boot-bup-payload which set the value in the boot table in Jetson TX2.
One can check the current ODMDATA configuration in the running system here (in Jetson TX2): /sys/firmware/devicetree/base/chosen/plugin-manager/odm-data
One can check the value which is used in the u-boot-bup-payload with: bitbake -e u-boot-bup-payload | grep -B 4 -A 6 ODMDATA
Additionally to my collegues post above, I’d like to specifically share what the wrong and right place for setting ODMDATA value was:
Wrong place: Image recipe
Right place: local.conf
Setting it in the image recipe overwrites meta-tegra BSPs default for the tegraflash package, but not for the u-boot-bup-payload. When setting ODMDATA in local.conf, the default gets overwritten for both the tegraflash package as well as u-boot-bup-payload as well as any other package built.
This problem became apparent only now, because it seems that only since this commit Mender (our OTA update solution) updates the bootloader update package (BUP).