Hi there!
stock bootloader and kernel, dtb modified by the manufacturer carrier board.
after power on
+8 sec. load UEFI
+58 sec. initialization of HDMI interface ?
+33 sec. UEFI menu start
+5 sec. Booting Linux Kernel
+28 sec. full system start with active display !!!
I can not understand the reason for such a long pause ~91 sec. after the start of the uefi.
Thank you.
loadOrin_x230D.txt (131.7 KB)
Hi videodev,
From your serial console log, it seems an old UEFI version in use
[15:12:38:983] Jetson UEFI firmware (version 1.0-d7fb19b built on 2022-08-10T20:18:13-07:00
Could you help to upgrade to current Jetpack 5.1 to verify if the ~91 sec delay still exists?
For any abnormal boot time coming from UEFI, please enable full UEFI log by rebuild the binary in debug mode.
Based on past experience, it has some process pending in UEFI. Mostly such case happens on custom board.
I must have missed some instructions.
compiled a new UEFI (log_build_UEFI.txt),
Replaced the new UEFI in the bootloader nvidia SDK folder.
flashing with a new UEFI causes problems (log_flash_error_new_UEFI.txt)?
log_build_UEFI.txt (2.2 KB)
log_flash_error_new_UEFI.txt (25.8 KB)
Do you replace the Linux_for_Tegra/bootloader/uefi_jetson.bin with uefi_Jetson_DEBUG.bin which you just built?
You could use the following command to flash UEFI only after you replace the uefi image.
$ sudo ./flash.sh -r -k cpu-bootloader <board config> mmcblk0p1
Hi KevinFFF,
the original file has been replaced with a new one,
USER/nvidia/nvidia_sdk/JetPack_5.0.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/bootloader/uefi_Jetson.bin or uefi_Jetson_DEBUG.bin
the script with the command does not update the bootloader -`
sudo ./flash.sh -r -k cpu-bootloader jetson-agx-orin-devkit mmcblk0p1
log below
log_flash_error_DEBUG_UEFI.txt (40.0 KB)
Thanks!
Sorry, please use the following command for Orin
$ sudo ./flash.sh -r -k A_cpu-bootloader jetson-agx-orin-devkit mmcblk0p1
Hi KevinFFF,
*** Error: the file for writing A_cpu-bootloader or signing is not specified. ****
this sequence also does not work
sudo ./flash.sh -k cpu-bootloader –-image bootloader/uefi_Jetson.bin jetson-agx-orin-devkit mmcblk0p1
*** Error: the file for writing cpu-bootloader or signing is not specified. ****
Could you help to provide the full flash log as file when you run the command I just provided?
Is there “uefi_jetson.bin” under your …/nvidia_sdk/JetPack_5.0.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/bootloader/ ?
Please notice the spelling and capitalization.
Sorry, the file name was changed,
UEFI update was successful, corresponding log
log_WORKING_FLASH_NEW_UEFI.txt
Another log from the console, system boot.
log_system_load_DBG_UEFI.txt
Thanks!
log_WORKING_FLASH_NEW_UEFI.txt (64.9 KB)
log_system_load_DBG_UEFI.txt (346.7 KB)
From your log, there are two significant delay both relating to Phy.
[20:12:38:278] PROGRESS CODE: V03040002 I0␍␊
[20:12:38:283] ␊
[20:13:05:217] SNP:PHY: PhyDxeInitialization () Failed to reset Phy␍␊
[20:13:35:496] ArmSbmrStatusCodeCallback: Failed to send IPMI command - Unsupported␍␊
[20:14:02:314] SNP:PHY: PhyDxeInitialization () Failed to reset Phy␍␊
There’s a similar issue as yours also on the custom carrier board.
Please refer that to check if it could help.
UEFI with RGMII is slow to boot - Jetson & Embedded Systems / Jetson AGX Orin - NVIDIA Developer Forums
I don’t think this is the proper way to ask the question with this board here.
Doesn’t Auvidea provide you their customized BSP for you to flash? You should never use sdkmanager to flash any custom board…
Hi,
KevinFFF
the problem lies in the initialization of a non-existent ethernet controller.
Is it possible to disable this initialization in the .dts bootloader file?
WayneWWW
Indeed, the board manufacturer provided its own implementation of the BSP.
But if this BSP worked correctly and the manufacturer would answer my questions, i would not bother the forum, i think this is obvious.
I am not a low-level developer for embedded devices.
I hoped that I would acquire an already suitable platform for the implementation of my algorithms. But as I already understood, I will have to dive into the process of setting up the hardware.
Thanks!
For your question,
Please check ethernet@681xxxx in your device tree. Disable it and replace the old one in Linux_for_Tegra/kernel/dtb and Linux_for_Tegra/bootloader.
I just want to clarify again. Are you using board vendor’s BSP now or you are still using pure jetpack from sdkmanager?
i would not bother the forum, i think this is obvious.
Sorry for asking this question because we already had too many users here didn’t know they should not use sdkmanager on custom carrier board and didn’t know vendor provided the customized BSP.
WayneWWW,
I just want to clarify again. Are you using board vendor’s BSP now or you are still using pure jetpack from sdkmanager?
part of the BSP (without source codes) and instructions from the board manufacturer
How_to_flash_AGX_Orin_with_nvidia_sdkmanager.txt (1.2 KB)
kernel_out.zip (1017.0 KB)
ok, is there any problem or not sure how to conduct above comment to disable etherent node?
ethernet@6810000
found in .dts files for the kernel
and only in .dtb files of the bootloader
borin@b-orin:~/nvidia/nvidia_sdk/JetPack_5.0.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra$ grep -r “ethernet@681”
Binary file bootloader/tegra234-p3701-0004-p3737-0000.dtb.rec matches
Binary file bootloader/kernel_tegra234-p3701-0004-p3737-0000.dtb matches
Binary file bootloader/system.img.raw matches
Binary file bootloader/tegra234-p3701-0000-p3737-0000.dtb matches
Binary file bootloader/system.img matches
Binary file bootloader/kernel_tegra234-p3701-0004-p3737-0000.dtb.sb matches
Binary file bootloader/tegra234-p3701-0004-p3737-0000.dtb matches
Binary file kernel/dtb/tegra234-p3701-0004-p3737-0000.dtb.rec matches
Binary file kernel/dtb/tegra234-p3701-0000-as-p3767-0000-p3737-0000.dtb matches
kernel/dtb/tegra234-p3701-0004-p3737-0000.dts: ethernet@6810000 {
kernel/dtb/tegra234-p3701-0004-p3737-0000.dts: mgbe0_aqr113c_phy = “/ethernet@6810000/mdio/ethernet_phy@0”;
Binary file kernel/dtb/tegra234-p3701-0002-p3711-0000.dtb matches
Binary file kernel/dtb/tegra234-p3701-0000-as-p3767-0001-p3737-0000.dtb matches
Binary file kernel/dtb/tegra234-p3701-0000-p3737-0000.dtb matches
Binary file kernel/dtb/tegra234-p3701-0000-as-p3701-0004-p3737-0000.dtb matches
kernel/dtb/tegra234-p3701-0000-p3737-0000.dts: ethernet@6810000 {
kernel/dtb/tegra234-p3701-0000-p3737-0000.dts: mgbe0_aqr113c_phy = “/ethernet@6810000/mdio/ethernet_phy@0”;
Binary file kernel/dtb/tegra234-p3701-0004-p3737-0000.dtb matches
Binary file rootfs/opt/ota_package/t23x/bl_update_payload matches
Binary file rootfs/opt/ota_package/t23x/bl_only_payload matches
Binary file rootfs/opt/ota_package/t23x/kernel_only_payload matches
You can read your flash log to tell which file is in use.
“You can read your flash log to tell which file is in use.”
I guess I don’t understand the question very well.