Hi Nvidia Team,
I am facing issue while trying to provide a custom way for dtb during boot.
we are using this way to load the dtb using systemd-boot in Debian based custom device which is based on Jetson Orin Nano devkit.
Our boot directory structure:
ritesh@ritesh:~$ ls /mnt/
config-5.10.192-1 EFI initrd.img-5.10.192-1 loader System.map-5.10.192-1 tegra234-p3767-0003-p3768-0000-a0.dtb vmlinux-5.10.192-1
ritesh@ritesh:~$ ls /mnt/EFI/BOOT/
bootaa64.efi
ritesh@ritesh:~$ ls /mnt/loader/
entries loader.conf
ritesh@ritesh:~$ cat /mnt/loader/entries/boot.conf
title boot
linux /vmlinux-5.10.192-1
options LABEL=Boot root=PARTUUID=d94dc24c-f7b4-4390-a586-2a62e2350dc0 console=ttyTCU0,115200n8 console=ttyAMA0,115200n8 console=tty0 rootwait rw firmware_class.path=/etc/firmware fbcon=map:0 nv-auto-config video=efifb:off
initrd /initrd.img-5.10.192-1
devicetree /tegra234-p3767-0003-p3768-0000-a0.dtb
ritesh@ritesh:~$ cat /mnt/loader/loader.conf
default boot
timeout 0
Issue Observed:
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 and installing virtual address map...
Above issue is not observed with Jetpack 5.1.3 but I have verified issue observed with Jetpack 5.1.4 and Jetpack 6.2.
After checking both the log I am suspecting the issue might be with Jetson UEFI firmware but not completely sure please let me know what your observation and finding for this.
Jetpack 5.1.3 ==> Jetson UEFI firmware (version 5.0-35550185 built on 2024-02-20T04:21:22+00:00)
Jetpack 5.1.4 ==> Jetson UEFI firmware (version 6.0-37391689 built on 2024-08-28T08:47:11+00:00)
FYI: I am using the Latest Jetpack only which is 6.2 , for debug this problem i went back for older jetpacks. Please help me to find the root cause for this issue.
Do you mean that you are using the custom carrier board which design is similar as the devkit?
It seems something error in the device tree built into UEFI binary since it would load device tree from UEFI if FDT entry is not specified in extlinux.conf.
Please also provide the full device tree and serial console log in Jetpack 6.2(r36.4.3) as this is the target release you want to use.
Hi @KevinFFF,
Thanks for giving time to look into it. Please check my reply for above queries.
currently we are developing in Jetson Orin Nano devkit only, Custom board under development.
If something wrong with DTB then it must fail in case of Jetpack 5.1.3 as well but it works well. Here i have attached the dtb file which i am using for jetpack 5.1.3 or Jetpack 5.1.4. tegra234-p3767-0003-p3768-0000-a0.zip (57.1 KB)
Apart from this, I performed an experiment that helped the system boot with a custom DTB on Jetpack 5.1.4.
I replaced the uefi_jetson.bin file in the Jetpack 5.1.4 Linux_for_Tegra/bootloader directory with the one from Jetpack 5.1.3, and it booted successfully without any issues.
This makes me wonder if the Jetson UEFI firmware in Jetpack 5.1.4 has some issue related to this behavior.
If you are using the devkit, could it boot with default device tree?
(i.e. could it boot if you just use SDK manager to flash clean JP5.1.4 or JP6.2?)
If so, please help to clarify what customization in DTB causing the current boot issue.
It is working well with default dtb case even if i remove custom dtb it is booting without any issue.
for example if i remove this line devicetree /tegra234-p3768-0000+p3767-0005-nv.dtb from the loader/entries/boot.conf it uses the default dtb from Jetson UEFI and it is booting. Issue observe when I try to use custom DTB.
we are just trying to use a custom dtb file which we need to customize further. So we have provided “dtb=” with systemd-boot during wic generation something like this.
We are not using /boot/extlinux/extlinux.conf in our BSP, as we follow the Debian upstream approach for custom BSP generation.
I would appreciate your help in identifying the root cause of the following issue we’re facing with Jetpack 6.2:
“EFI stub: ERROR: Invalid header detected on UEFI supplied FDT”
To better understand the problem, here are some observations and questions:
This issue does not occur with Jetpack 5.1.3 (specifically with Jetson UEFI version 5.0-35550185). However, I observed the problem with Jetpack 5.1.4 onward. Based on this, do you think it’s valid to suspect the Jetson UEFI firmware as a potential cause, or is that unlikely?
Is there a way in the current Jetpack tooling to flash only the DTB, so we can try the DTB change?
Would it be feasible to test Jetson UEFI version 5.0-35550185 with Jetpack 6.2, just to rule out UEFI as the source of the issue?
Is it possible to get a debug-enabled Jetson_uefi.bin that can log more details during DTB loading? This might help us gather more insight into what’s going wrong.
Your guidance on these questions would be extremely helpful. This is a high-priority issue for us currently, and we’re keen to resolve it as soon as possible.
Sorry that we’ve not verified this use case locally.
We need you to clarify what customization causes current issue.
There’re many changes included in each release. I haven’t compared each of them relating to your current issue.
If you think the issue is relating to UEFI binary, please use debug UEFI binary and provide the full logs for further check.
If your DTB is loaded from UEFI-DTB or rootfs, then flash DTB would not take any effect.
Flashing DTB partition is only valid when you are loading DTB from partition.
I think it would not be able to boot since they are from such different Jetpack release.
The Error Code = -3 corresponds to FDT_ERR_NOSPACE, which means the operation needed to expand the device tree, but the buffer didn’t have enough space to contain the expanded tree.
Reference:
Solution:
To resolve this, you need to add padding to the DTB file minimum of 6KB size. For example:
Take your tegra234-p3768-0000+p3767-0005-nv-super.dtb from the boot directory and run the following commands then update the dtb in boot Dir: