Hi all,
We’ve managed to first-boot the system, and got the Ubuntu login screen.
However, I can’t go on, as the mouse and keyboard are not functioning properly.
They were connected to USB3A headers, which are connected to SOM USB0 and USB2.
See attached figure for our system configuration.
Any idea on debug will help.
Sorry, what is USB0 and USB2? What uphy is it?
Hi,
Sorry but somehow my answer was not saved - only the figure that I’ve sent.
I’ve attached a figure showing the USB0-3 and the UPHY pins.
Can I get explanation on enabling of the USB ports - are they all enabled? as Host? as Device?
Thanks,
Ok, I got it.
USB0, USB2 are pure 2.0 ports while USB1 and USB3 are mixed with 3.0 ports.
Have you read the xavier adaptation guide on our download center?
Hi,
I haven’t read the Xavier adaptation guide.
I’m a hardware designer, doing contract design, and was informed that there’s no need to do any s/w change, as long as we’ll follow the reference design.
I’m aware that if I’ll want to connect USB 3.0 device, I’ll have to do some s/w changes,
but assumed that I’ll be able to connect USB 2.0 devices (mouse/keyboard) to any of the ports - and they should work.
As it seems - all the USB ports are disabled or not enumerated.
I’m trying to debug in both directions - h/w and s/w.
For the s/w, I’ve asked my customer to assign a s/w designer to look at the Xavier adaptation guide.
For the h/w I assume that I should try connecting a terminal set 115Kbaud, 8bit, no parity, to UART3_RX_DEBUG(K60) / UART3_RX_DEBUG (H62).
Will I be able to see a log of enabling/disabling the USB ports?
Is there a document for h/w designers - I would recommend such a one, informing on shorting ‘Carrier-pwr-on’ in first power-debug - for bypassing the carrier, and also to use the DEBUG UART - and maybe other tips.
If you are creating an exact duplicate of wiring layout versus the development kit carrier board, then the default device tree will work. If ports have stopped working, and if the wiring has changed, or if the the device tree is incorrect, then the module will have an incorrect idea of the wiring layout. Is your carrier board truly an an exact duplicate of the wiring layout of the dev kit carrier board? Are you using the default device tree?
Also, if you’ve installed various items of software which are in the non-rootfs partition, and not used the provided flash software to do the install (e.g., you used “dd”), then a failure might be expected due to missing a valid signature on those partitions.
If you are able to put the board into recovery mode, and have the device mode port available to connect to the host PC, and can see the device with “lspci” from the host, then you’ve proven that at least some of the wiring is correct. That particular port, if failing once booted, may be indicative of an incorrect device tree. If you see any serial console output at all from that port during boot it would probably be useful.
FYI, the default serial console is 115200 8N1 without CTS/RTS flow control (I think software flow control works as expected). Serial console starts providing some output even prior to the Linux kernel loading. For the Xaviers you would likely see pre-Linux content switch to Linux content at the line which says something similar to this:
[0003.726] I> Linux Cmdline: root=/dev/mmcblk0p1 rw rootwait console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 OS=l4t video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt tegra_fbmem=0x140000@0xa0791000 lut_mem=0x2008@0xa078e000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.2.2 sdhci_tegra.en_boot_part_access=1
Hi,
but assumed that I’ll be able to connect USB 2.0 devices (mouse/keyboard) to any of the ports - and they should work.
Yes, that should work. If you want our help, please share the kernel log for us to check.
As for hardware design, please refer to Xavier OEM DG from DLC.
Thanks.
I’ve forwarded the reply to our s/w engineer.
My understanding is that we use a firmware taken from the reference kit, with no change.
In the hardware, we had several changes which will require some changes - e.g. we have two SSD, and I aware that will have to handle it - but we kept the ‘boot’ with no change (e.g. HDMI, first SSD)
I’ve connected external FTDI to the serial console, and saved the log - from power-off to next login.
Kindly ask to see if there’s a clue in this log file.
Thanks in advance
Ishay
teraterm-system5.log (91.6 KB)
According to the log the boot was successful.
The note about “[ 22.143626] tegra-i2c 31c0000.i2c: no acknowledge from address 0x50” makes me think you do not have an HDMI monitor connected (though it might be a different i2c controller the controller for HDMI uses address 0x50, and this occurs right at the moment when the system should be starting graphical mode).
Are you using any kind of adapter to the HDMI? What do you see from:
sudo -s
cat `find /sys -name 'edid'`
exit
Note that mouse and keyboard in graphical mode can be related to the monitor. The X server loads the video driver as a module (an Xorg module, not a kernel module). In a similar way mouse and keyboard are loaded in to the Xorg server. If for some reason the Xorg server was hung up at HDMI load, then presumably it is possible keyboard/mouse would never load.
Hi,
During this specific log I didn’t connect the HDMI, as I had no idea that USB will not operate if HDMI is not connected.
Anyway, the s/w engineer has found that the root-cause might be due to the fact that we’re not having CYPD4226 on board. (as we’re having only usb 3.x - no USB-C)
I’m attaching his dinding in PNG file.
I’m also attaching a new log, with HDMI connected, and with log of "cat find /sys -name 'edid'", even though I assume that this is not the root-cause.
I tried today to test GBE. What is the best way to test it?
I couldn’t see the lights on the connector.
Thanks for your support
Nov24-teraterm.log (98.3 KB)
Keyboard and mouse can work without HDMI, but some software works through the X server, and in those cases modules loaded into the X server bind the mouse/keyboard to the application. Software designed for a GUI (X11) application would require X before the mouse/keyboard would be visible. If you are on a purely text console, then keyboard/mouse should work (no loadable modules are used in console mode). The console video might still fail to configure correctly without an HDMI monitor, but there would be no relation to USB for this mode.
On the other hand, lack of monitor should not create a tegra19x_xusb_firmware error. I believe any of the tegra-xusb errors or issues are unrelated to having a monitor. The tegra19x_xusb_firmware and other tegra-xusb issues occur prior to any monitor software getting involved.
Lack of any of the USB hardware (the CYPD4226) would imply that you need to adjust the device tree. It is highly likely that removal of any of the USB hardware, without adjusting device tree, would result in exactly this kind of error. I do not know the specific chips, but this is a USB port controller, so you are guaranteed to have errors if the missing PHY is expected to be there.
Someone else will need to tell you which device tree changes to make, but most likely it will just be a change from “status=okay;” to “status=disabled;”. Perhaps there may also be a power rail change.
Yes, the adaptation guide could teach you how to modify the device tree if you don’t have CYPD4226.
Other forum topics have such discussion too and you could refer to it. Please ask the software engineer to help check.
Below is the one that is related to your error.
[ 13.846481] tegra-asoc: sound: snd_soc_register_card failed (-517)
[ 13.848262] tegra-xusb 3610000.xhci: USB2 port 0 has OTG_CAP
[ 13.848265] tegra-xusb 3610000.xhci: USB3 port 2 has OTG_CAP
[ 13.851333] Could not get extcon-dev /xhci@3610000:id(0)
Sorry I had no chance to ‘accept as answer’ due to illness.
Yes, we’re going in this way of modifying the device tree.
Thanks to all which helped.
Hi Guys,
We have very similar situation, we are not using CYPD4226 chip and connecting USB 2.0 signals directly to USB connectors. I understand that we probably need to change “p2972-0000.conf.common.” file. Can you please share what should be change?
Please refer to Jetson Xavier adaptation guide on our download center first.