Hi all
i am powering up my custom carrier for the first time.
5VDD is good
POWER ENABLE goes high
After the orin nano is powered up the SYS_RESET (pin 239) goes high
my 3.3V carrier supplies are then enabled
But,… I get nothing on UART2 (Debug) and I cannot see the USB0 on my pc at all… If i hold FORCE_RECOVERY (pin 214) low it does not enter force recovery mode either…
The pc just cannot detect USB0
Also the fan doesnt run
I am testing with fresh Orin nano (production module 4GB) and a blank nVME SSD.
So i am not sure what to check next … any guidance would be appreciated.
ok, heres an update
I did get it to detect uso0 in recovery, there esd diodes were causing an issue (not sure why yet (i used ESD9L5.0ST5G)
Anyway i successfully flashed the image itself…
I can then login to the root
upon logging in, i cannot see the orin nano on usb0 so i cannot “finish” the flash as such as i cant install the SDK components…
any thoughts?
also not that the system is headless, there is no display and my only access to root is currently via UART2 (debug)
so other than login to the freshly formatted system, i haven’t done anything. But the nVME is definitely working well as the image was fully flashed.
If this is custom board and your host cannot see jetson as device in lsusb, it probably means hardware design mismatch from devkit so that original software cannot work.
Further change in linux kernel/device tree is required here.
But I really wonder if above is correct, how did you flash your orin nano? Did you ever play the orin nano on devkit before using custom board to understand how things work here?
It is a custom board yes…
But there is no design mismatch with respect to USB0.
I flashed it through USB0 using recovery mode and it was fine (flash to the NVME)
Yes I used the devKit for a number of months; I understand the flashing process
It is only when the unit boots in “normal” mode, not usb recovery mode that I cannot see it on my host at all with lsusb…
If I reboot into recovery mode, it appears again
The problem is I need it booted normally to flash the sdk components…
I still need to apply my custom pinmux but that doesn’t affect usb0, as my design for usb0 matches the devKit design
I must correct myself, the USB0 force recovery is not the same as the devkit design, here it is;
its absolutely fine for the flash itself, it is detected as expected when in force recovery mode…
BUT, when the unit then boots into linux it is not detected by the host…
Also, i have other usb ports on my carrier, which all work and can find things like a usb camera if i plug it in… these are connected to USB1 and USB2 buses on the orin.
So, i am wondering if there is something special about USB0 when the unit has booted with a custom carrier?
Hi,
I have some other posts that already explained this many times.
-
Recovery mode is a pure hardware defined event. If the hardware puts the board into recovery mode, the device will be in recovery mode. In this case, no software is involved. If you think it more, as recovery mode has no software running, it is of course no software got involved…
-
To make usb to work in normal boot mode, software is involved. In this case, device tree change may be needed.
-
initrd flash and flash.sh are different route to flash the board. For initrd flash, it also needs usb software to work in normal boot mode. Initrd flash basically boots into initrd first and then flash your nvme.
For flash.sh, it does not need usb software to be correct. Thus, what I am confused previously is whether your flash is using initrd flash, or you are using flash.sh. If you are using initrd flash, it means software should be okay too so we shouldn’t see such issue after boot up.
-
It is okay that your design is different. It is very common on this forum.
1 Like
Hi Wayne
I see, well i just used the standard SDK flash process, i didnt do i by scripting on the command line (i have done it both ways on the development board)
So I guess it was the flash.sh way? Is that what the SDK uses? I manually did it as the nVME was a fresh new one, so i jumpered the pins on my pcb to enter force recovery, then flashed with sdk.
I am wondering why USB0 device tree change would be needed as i am using the same pins as devkit, routed directly to the connector?
Hi @scott104
-
If we are really talking about Orin Nano or Orin NX case, then it will not be flash.sh. It will be initrd flash. Your flash log will tell.
-
If it is really initrd flash, then usb0 device mode must work once during flash process because initrd flash must use usb0 device mode to flash something to nvme.
-
If (2) is true, then usb device mode was working fine in (2) but somehow goes failure after you boot up in kenrel.
Thus, share UART logs here. First uart log is from the flash process. Second uart log is from the normal boot up process.
I am wondering why USB0 device tree change would be needed as i am using the same pins as devkit, routed directly to the connector?
USB configuration is a very sensitive to any change on custom board design. I’ve seen many users talking about “I am using same design as devkit”, but turns out their usb just cannot work because there are still minors change. Please be aware that as I notice lots of users have a wrong understanding…“Recovery mode working does not mean your usb design is 100% correct”.
Hi Wayne
thanks, ok i will send logs…
Do you want “NV_L4T_FLASH_JETSON_LINUX_COMP.log” ?
Here is the start fo the log…
------ 2023-06-27 04:23:24 ------
------ SDK: JetPack_5.1.1_Linux ------
04:23:24.643 - Info: [host] [ Disk Avail:32.85 GB ]
04:23:24.643 - Info: change working directory to /home/scott/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra
04:23:24.643 - Info: [ Component Install Started ]
04:23:24.643 - Info: current working directory is /home/scott/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra
04:23:24.643 - Info: exec_command [host]:
#!/bin/bash
set -e
set -e
unset LC_ALL
echo sudo ./nvsdkmanager_flash.sh --storage nvme0n1p1 --nv-auto-config --username test
sudo ./nvsdkmanager_flash.sh --storage nvme0n1p1 --nv-auto-config --username test
sleep 20
It mentions a lot about :
/home/scott/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml --showlogs --network usb0 -p -C nv-auto-config -p --no-systemimg -c bootloader/t186ref/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal
I have just used the standard flash for now and the carrier + orin nano boots fine, i can use other usb ports… but once booted cannot use usb0 thats all…
Yes it is initrd flash log. I need the uart log then.
you mean the debug uart log right? when it boots?
I didnt connect UART debug durung the flash you see…
I need them for boot and flash both.
heres the boot log, i will need to reflsh to get the flash log
can you see anything from this?
boot_uart2.txt (86.3 KB)
This log seems indicating usb device mode is not triggered.
oh right, i am not sure what to do about that :)
As i have designed a usb hub on USB1 bus and its working perfectly well.
Any idea what i can do ?
on dmesg i see it says “l4tbr0: port 2(usb0) entered disabled state”
Could you connect your type C cable to host and dump below node result from your jetson?
cat /sys/class/usb_role/usb2-0-role-switch/role
it just comes back with “none”
Also, want to clarify. If you are not using fusb310 as the devkit, then the default device tree may not work.
no i am not, see the schematic above.
i designed the carriwer when you only had the orin nano migration guide avaiable so didn’t know about that fusb310…
my design is almost exactly the same as your design guide…
