How to enable tc358743 on 36.3?

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
42

I did modify hardware/nvidia/t23x/nv-public/overlay/tegra234-p3768-0000+p3767-0000-dynamic.dts

and include my tc358743.dtsi instead off rbpcv2-imx219.dtsi :

//#include "tegra234-p3768-camera-rbpcv2-imx219.dtsi"
#include "tegra234-p3768-camera-tc358743.dtsi"

However, it still appears to create the default tegra234-p3768-0000+p3767-0005-nv.dtb for /boot/dtb (output below) - but I didn’t think that was used unless we were trying to use an overlay. I have questions about this point as well, but I’ll wait until I get to a login prompt before asking.

****************************************************
*                                                  *
*  Step 2: Boot the device with flash initrd image *
*                                                  *
****************************************************
/home/parallels/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/temp_initrdflash/bootloader0 /home/parallels/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra
./tegraflash.py --bl uefi_jetson_with_dtb_sigheader.bin.encrypt --bct br_bct_BR.bct --securedev  --bldtb tegra234-p3768-0000+p3767-0005-nv.dtb --applet rcm_2_encrypt.rcm --applet_softfuse rcm_1_encrypt.rcm --cmd "rcmboot"  --cfg secureflash.xml --chip 0x23 --mb1_bct mb1_bct_MB1_sigheader.bct.encrypt --mem_bct mem_rcm_sigheader.bct.encrypt --mb1_cold_boot_bct mb1_cold_boot_bct_MB1_sigheader.bct.encrypt --mb1_bin mb1_t234_prod_aligned_sigheader.bin.encrypt --psc_bl1_bin psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --mem_bct_cold_boot mem_coldboot_sigheader.bct.encrypt  --bins "psc_fw pscfw_t234_prod_sigheader.bin.encrypt; mts_mce mce_flash_o10_cr_prod_sigheader.bin.encrypt; tsec_fw tsec_t234_sigheader.bin.encrypt; mb2_applet applet_t234_sigheader.bin.encrypt; mb2_bootloader mb2_t234_with_mb2_cold_boot_bct_MB2_sigheader.bin.encrypt; xusb_fw xusb_t234_prod_sigheader.bin.encrypt; pva_fw nvpva_020_sigheader.fw.encrypt; dce_fw display-t234-dce_sigheader.bin.encrypt; nvdec nvdec_t234_prod_sigheader.fw.encrypt; bpmp_fw bpmp_t234-TE950M-A1_prod_sigheader.bin.encrypt; bpmp_fw_dtb tegra234-bpmp-3767-0003-3509-a02_with_odm_sigheader.dtb.encrypt; rce_fw camera-rtcpu-t234-rce_sigheader.img.encrypt; ape_fw adsp-fw_sigheader.bin.encrypt; spe_fw spe_t234_sigheader.bin.encrypt; tos tos-optee_t234_sigheader.img.encrypt; eks eks_t234_sigheader.img.encrypt; kernel boot0.img; kernel_dtb tegra234-p3768-0000+p3767-0005-nv.dtb"    --bct_backup  --instance 1-8

It gets hung on ‘Step 3: Start the flashing process’ since the Orin state is ‘EFI stub: ERROR: Invalid header detected on UEFI supplied FDT, ignoring …’

Q1 - I did not think that the original build had an FDT line, so it appears it’s trying to load from the UEFI partition and that is somehow broken? (like here - DTB_FILE setting not used in JetPack 6.0 - #25 by DaveYYY )

Q2 - how do I see the UEFI supplied FDT ?

The previous attempt booted to kernel crash, the rebooted itself after sometime and hung, then rebooted again into a recovery (?) shell. I can not find my notes where I captured that output, but I could not interact with the Orin via console once it boots up, which inspired the full rebuild.

Q3 - when it failed to the recovery bash prompt - I was unable to interact with the console, however when the Orin first boots up I am able to access the BIOS menu and choose which option I want to use from extlinux.conf file - so I know the keyboard works. But once the OS starts up, the Orin console does not respond to keypresses. Is that expected behaviour ?

Thank you

43

I just noticed there wasn’t the line
L4TLauncher: Attempting Direct Boot
after ‘Enter to continue boot.’ in the log - which led me to this page :

Which has allowed me to boot to /boot/Image.backup and access the system. So the system is not reflashed (since the flash command couldn’t install on to the disk in the ‘Unbootable’ state…).

I am going to fix the header and capture the console output after applying the .dtbo to see if the issue persists.

44

Update :

root@sthd-6:/boot# /opt/nvidia/jetson-io/config-by-hardware.py -n 2=“ET tc358743 Dual”
<Jetson.board.Board object at 0xffff957ab910>
Traceback (most recent call last):
  File "/opt/nvidia/jetson-io/config-by-hardware.py", line 127, in <module>
    main()
  File "/opt/nvidia/jetson-io/config-by-hardware.py", line 104, in main
    hw_mods = parse_hw_args(args.name, len(headers))
  File "/opt/nvidia/jetson-io/config-by-hardware.py", line 80, in parse_hw_args
    raise NameError("More than one HW module on Header %d!" \
NameError: More than one HW module on Header 1!

I suspect this is happening because the IMX_219 driver is already loaded by default from tegra234-p3768-0000+p3767-0000-dynamic.dts

I’ve commented out the imx219 line (per post above) and recompiled everything but am unable to re-flash my Orin - even after “fixing” the direct boot issue. When I put the Orin in recovery mode and attempt to reflash, it once again hangs without attempting the Direct Boot. When I go in to the BIOS, it lists the drive a ‘Bootable’.

Is there some other flag or procedure I need to run to be able to re-flash the Orin ?

45

So did you get the same error as shown here?
Can you please re-flash the device with the UEFI debug binary and put the log here?

46

Yes.

Can you link to more information about using UEFI debug binary?

Thank you

47

You can build UEFI according to instructions mentioned here:

(Building with docker is the recommended way.)
You will end up getting two binaries, one is the release version, and the other one is the debug version.
Replace Linux_for_Tegra/bootloader/uefi_jetson.bin with this new file and flash your device again.

48

Thank you DaveYYY. I will attempt this procedure today.

49

consoleDebugLog.txt (101.7 KB)

Here is the serial log using uefi_Jetson_DEBUG.bin

Thank you.

50

And I’ll go ahead and get a head start on what I believe the next support suggestion will be, which is to try and re-flash from the most recent SDKManager - which I tried and it failed as well.

sdkm-2024-07-13-23-01-38.log (206.2 KB)

Failure root cause: Failed Component ID: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS#36.3.0. Error Code: 1011. Error: Failed to execute commands with GenericInstaller.

I’m really surprised it’s this easy (?) to get the Orin in an unflashable state. Is there a physical or hardware reset to get back to its original state?

Thank you.

51

Can you try switching the L4T Boot Mode to Kernel Partition according to this guide?
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/Bootloader/UEFI.html#dtb-support
Or keep the Boot Mode as is, and add the FDT line back into /boot/extlinux.conf.
If both of them still lead to boot crash, then maybe your overlay is somehow problematic.

23:03:37.883 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: [   0.5309 ] Sending bct_br
23:03:37.883 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: 
23:03:48.130 - error: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: [   0.5485 ] ERROR: might be timeout in USB write.
23:03:48.130 - info: Event: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS - error is: [   0.5485 ] ERROR: might be timeout in USB write.
23:03:48.130 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: 
23:03:48.139 - error: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_ORIN_NANO_TARGETS: Error: Return value 3

Check this:

52

Changed the L4T Boot Mode to ‘Kernel Partition’ and it did not make a difference, I was unable to re-flash the Orin. It stopped at :

ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
Failed to find memory test protocol
......!!! enter DisableFRB2Handler()!!!
DetectSmbiosChange: Failed to get UEFI Variable SmbiosHash Not Found
UpdatePcieControllersWithGpuDevice: failed to enumerate GPU device handles: Not Found
EsrtFmpDxe: Can't install ESRT table because it is NULL.
[Bds]Booting UEFI NVIDIA Rcm Kernel Boot
Loading driver at 0x00229B60000 EntryPoint=0x0022B84B1B4
Loading driver at 0x00229B60000 EntryPoint=0x0022B84B1B4
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: Invalid header detected on UEFI supplied FDT, ignoring ...
EFI stub: Generating empty DTB
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services...
Link didn't transition to L2 state
Link didn't go to detect state as well
PROGRESS CODE: V03101019 I0 D6A2CB7F-6A18-4E2F-B43B-9920A733700A

It appears that the L4TLauncher is not being run and I do not understand why. It still boots up normally when the recovery mode jumper is not connected.

FDT in extlinux.conf is not relevant at this point, because L4TLauncher is not starting. I expect to see :

ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
......
      L4TLauncher: Attempting Kernel Boot
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services...

in the console, but I don’t when I attempt to flash the Orin (first output above)

I tried

sudo -s
echo -1 > /sys/module/usbcore/parameters/autosuspend

But that did not make a difference. I flashed the Orin several times when using 5.1.2 - never had it get stuck like this.

Thank you.

53

If FDT entry is specified then it will skip reading DTB from whatever dedicated partitions.

You need to un-plug the flashing cable, put the device in force recovery mode again, plug in the flashing cable, and try again.

54

I thought L4TLauncher read the /boot/extlinux/extlinux.conf file from the boot drive - is that incorrect? Mine is

root@sthd-6:~# cat /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} root=PARTUUID=6c05e10b-6c14-4a77-84ec-337c0cdaa5dd rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0

No FDT lines.

That gave the same result as before. Can you explain what is happening from the line
Failed to find memory test protocol
to
Link didn't go to detect state as well
from the output above ?

Thank you.

55

The USB timeout error is not related to UEFI at all.
Search over the forum and you can find a lot of posts talking about the same stuff.

56

When I’m running

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device sda1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml"   --showlogs --network usb0 jetson-orin-nano-devkit internal

from my development machine and it get’s stuck on

Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Timeout
Device failed to boot to the initrd flash kernel. Please retrive the serial log during flashing to debug further.
Cleaning up...

because the Orin is having an issue with the EFI stub - I do not think it is a USB timeout issue. We’ve already gone through that and this is not the same situation. When I first kick off the flash, I see the Orin module in lsusb as

Bus 001 Device 009: ID 0955:7523 NVIDIA Corp. APX

the flash program goes through several more steps and reboots the Orin a few times ( the ‘Device’ number increases a few times) and then – when it worked in 5.1.2.-- it would come back as

Bus 004 Deivce 010: ID 0955:7035 NVIDIA Corp. Linux for Tegra

and all the files would be copied over, but that second part on bus 004 isn’t happening, so it times out.

Even attempting to flash the Orin from the SDKManager - without any changes - is failing in the same place.

Why?

57

Are you still going with this change?

58

I’m certainly trying to, but my Orin won’t flash!

So, I have stepped back to just tying to flash the Orin from the most SDKManager - without any changes and it is failing as mentioned above, log files posted from that attempt as well.

Thank you.

59

You mean even flashing with SDKM gives the UEFI FDT error?

60

YES ! That’s what I posted here :

61

Please make sure where you actually get stucked.

I have said that the SDKM log here is about the USB timeout error, not UEFI.
You are not supposed to get the UEFI FDT error if you are sure it’s the default BSP without any customization.