Cboot XUSB Support Broken Since r32.7.1

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

I have been trying to enable the fastboot menu in the t210 cboot for use with Android projects. By adding fastboot-instructions to the kernel dt chosen node and reverting:
https://nv-tegra.nvidia.com/r/plugins/gitiles/device/hardware/nvidia/platform/t210/porg/+/519e16e8dd2be33a1f74af8cae6f2e6727bb5d2d

I am able to access the bootloader menu on a Jetson Nano 2GB. And on cboot from L4T r32.6.1, I am able to control the menu with a shield controller. However, on cboot from L4T r32.7.x, this fails with the following log lines.

[0007.307] firmware blob is not loaded and initialized
[0007.312] no usb firmware found on blob
[0007.316] xhci0: Could not load usb firmware
[0007.331] xhci0: WARNING: Probe and attach failed!
[0007.336] failed to init xhci or no usb device attached

It appears to just fails to read the partition altogether. Part of the commit message I linked above states:

For now, CBoot will still find/load the RP4 XUSB firmware blob since it is already doing it by default.

Is this an issue that can be fixed on a future r32 bugfix release? I know my usecase isn’t officially supported, but it appears that the functionality is used for supported use cases.

3

Hi,

Are you talking about even usb boot fails on rel-32.7.x?

4

I have not tried usb boot, I don’t know if the use case of usb boot from u-boot works or not. I just see that the xusb firmware is not being loaded in cboot on r32.7.x, whereas it was on r32.6.1.

5

Hi,

I was just trying to provide a proper way so that we can help check your issue… so if you understand correctly, you may try usb boot first. Check whether it is working or not…

6

The simple test would be to re-enable cboot xusb init by reverting 519e16e8dd in the porg kernel dt repo and booting with that. The cboot log would match my quote above if firmware load fails.

I will try usb boot on r32.7.3 in a few hours.

7

From the u-boot log:

starting USB...
Bus usb@7d000000: tegrausb: Invalid dr_mode 2 for host mode
probe failed, error -1
Bus xusb@70090000: Loading XUSB FW blob from RP4 partition ...
SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB

Firmware size 126464
Firmware timestamp: 0x5f23e558, Version: 50.26 release

Looks like u-boot is loading the firmware directly from the mtd on r32.7.3, not using what cboot was previously loading into ram. So the supported usecase does work. The following commit, new to r32.7.1, appears to be the reason the firmware loading support was disabled in cboot.

https://nv-tegra.nvidia.com/r/plugins/gitiles/3rdparty/u-boot/+/e5966ea9d1c425b16348e6f2015701ba95c5d47d

It’s still annoying to see previously working functionality stop working, however. I’d be able to fix things like this myself if the t210 cboot source were ever to ever be approved for release. Can support for reading the firmware blob be re-enabled if the bootloader-xusb-enable flag is set? I’d prefer to not have to use an older cboot binary to retain this functionality.

8

Sorry that then we don’t support this case. If you want to workaround it, then maybe try to use older cboot binary for this.

10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.