Boot stalls until HDMI cable is plugged in

We are using Xavier Industrial models with Jetpack 4.6 on a custom carrier board. The boards do not have USB-C controllers, so we have modified the DTB to disable ucsi_ccg@8 and changed the usb2-0 mode from OTG to host following the advice on a forum post. The xaviers were flashed using ROOTFS_AB=1, and initial flashing and testing seemed fine; we could boot from both partitions etc. The filesystem was then modified to remove unnecessary APT packages and run at the multi-user.target level.

We now seeing an issue where the boot process will not complete unless a monitor is plugged into the HDMI port. The issue only presents itself on some units, and with varying frequency. When it does present itself, the following block is repeated ad infinium in the kernel logs:

Could not get extcon-dev /xudc@3550000:vbus(0)
Could not get extcon-dev /host1x/nvdisplay@15210000:typec0(0)
tegra-asoc: sound: ASoC: CODEC DAI rt5659-aif1 not registered
tegra-asoc: sound: snd_soc_register_card failed (-517)
tegra-xudc-new 3550000.xudc: PMQOS CPU boost enabled
Could not get extcon-dev /xudc@3550000:vbus(0)
Could not get extcon-dev /host1x/nvdisplay@15220000:typec1(1)
tegra-asoc: sound: ASoC: CODEC DAI rt5659-aif1 not registered
tegra-asoc: sound: snd_soc_register_card failed (-517)
tegra-xudc-new 3550000.xudc: PMQOS CPU boost enabled

I’ve attached the latest kern.log which spans some boot sequences with the monitor initially detached, then plugged in while during boot. Any clues on how we could get past this problem, especially without having to reflash, would be appreciated.

Related is a question of whether or not we can use the /boot/extlinux/extlinux.conf files in each rootfs partition to attempt to modify the boot arguments (inspired by this post - No boot without HDMI). Adding extra boot arguments did not seem to effect the boot command handed to the kernel.

kern.log (4.4 MB)

1 Like

HI,

If you remove the type c, then you need to remove those related nodes too. I think only these are related to USB.

Could not get extcon-dev /xudc@3550000:vbus(0)
Could not get extcon-dev /host1x/nvdisplay@15210000:typec0(0)
Could not get extcon-dev /xudc@3550000:vbus(0)
Could not get extcon-dev /host1x/nvdisplay@15220000:typec1(1)

Please remove type C port under display nodes since you don’t have type C on your board.

Also, xudc driver is for usb device mode, since you don’t need otg, remove the lanes and vbus from it too.

Thanks - I think I have a new DTB to try. Does the A/B rootfs support reading the device tree from its partition by modifying extlinux.conf? I was having no luck modifying it to include additional boot parameters. As there is no usb-c, I can’t flash them in place so it would be nice to test before tearing things apart.

Along the same lines, if I flash another module with my new DTB could I use “dd” to make a copy of the dtb partition(s), copy that to my broken modules and “dd” them into place in leu of flashing them?

Hi,

I think it would be better to focus on one issue in each topic.

In this topic, my target is simple: we try to see if we can find out why the boot stalls. Currently, the issue looks from the usb configuration.

Thus, for something like whether “extlinux.conf” would work fine with rootfsA/B enabled is not what I want to focus now.

Actually, I am not sure if they would work fine either. Maybe it can work fine or maybe there is indeed a bug.

Thus, please just try to use the basic method which flashes the dtb into the partition. You can use devkit to flash the dtb and put it back to your custom board and try.

BTW, I think it is not wise to have no usb0 device mode design on your board.

My new DTB appears to solve the issue.

For completeness the failure to use the extlinux.conf file was caused by this: RootFS OTA update with A/B redundancy boots with wrong rootfs partition

I also agree that its not good to be missing a usb-c device; trying to purchase all the parts currently is proving impossible; that might be why you are answering the same question about removing usb-c in here all the time.

It does not matter whether this is usb-c or not. What I mean is usb device mode. Which means any kind of port which supports usb device mode is ok. For example, micro usb. The point is your carrier board should have capability to get flashed directly and even some functions that required usb device mode to run after kernel is up.

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