How exactly UEFI bootloader changes with Device Tree?

On Orin with JetPack 5.0.2 and Jetson 35.1
I am trying to follow instructions in
and modified several .dtsx files to create a new camera.
Then I built DTB and got ./kernel_out/arch/arm64/boot/dts/nvidia/tegra234-p3701-0000-p3737-0000.dtb
Then I applied my overlay and got new file tegra234-p3701-0000-p3737-0000-with-overlay.dtb,
decompiled it and verified that all my modified entries are as expected.
Then I transferred tegra234-p3701-0000-p3737-0000-with-overlay.dtb to /boot/test/tegra234-p3701-0000-p3737-0000-with-overlay.dtb
and added
FDT /boot/test/tegra234-p3701-0000-p3737-0000-with-overlay.dtb
to /boot/extlinux/extlinux.conf.

OK, system boots, my tegra234-p3701-0000-p3737-0000-with-overlay.dtb is being used,
but multiple entries there are modified, apparently by the bootloader
and I cannot figure out why.

There are many changes in DTB, in particular:

was changed from “disabled” to “okay”
even if I do not have imx185_a@1a camera.
chanhed from 2 to 1

I thought that UEFI bootloader applies some overlays at run time.
Is it true?
But I tried to delete all .dtbo and .dtb files in /boot directory,
but these changes still happen.

So, I find it hard to troubleshoot device and camera integration
if my carefully created .dtb file is being modified using some unknown rules and overlays.

Please, tell how we should understand and troubleshoot UEFI bootloader behavior
in regard to DTB modifications (I dot not have time to rebuild and replace and debug bootloader code myself right now).
In particular, why did it decide that imx185_a@1a camera is present, when it is not
and why it reduced num-channels from 2 to 1?
Is there some verbose option or a debug build of the bootloader, which I can apply?

Thank you

The correct method to put overlay dtb now is putting it to the list in your board config but not directly use them.

Yes, I figured this out myself that I need to remove overlays (especially tegra234-p3737-camera-imx185-overlay.dtbo) from OVERLAY_DTB_FILE to avoid them being erroneously applied.
I was not planning to use overlays at all since my camera does not have EEPROM, I am using plain static DTS/DTB.

My biggest complain is the lack of documentation and diagnostics for UEFI bootloader.
I suggest that you will have to rewrite the bootloader with more detailed diagnostics, otherwise you will have a flood of complaints in the next years, which you will not be able to solve because of lack of diagnostics.

For example, do you know what error message:
EFI stub: ERROR: Invalid header detected on UEFI supplied FDT, ignoring …
You will never guess, google is also silent about that,
but this message always happen simply when UEFI failed to apply overlay!
If any of the overlay fragments contain target key, which happened to be absent in the base DTB,
then UEFI silently fails to apply overlay and sends uninitialized memory to kernel EFI stub, which prints this confusing message.
This has to be fixed with more logging in the bootloader.

Please download the UEFI source code and check edk2/EmbeddedPkg/Library/FdtLib/fdt.c.

The error “ERROR: Invalid header detected on UEFI supplied FDT, ignoring …” is due to check in fdt_check_header returns error.

May be,
but my point is that UEFI bootloader must log what it is doing and certainly must log errors, but currently it does not, which makes it impossible to troubleshoot
and it was a waste of time for me to troubleshoot failed overlay
and it will be a nightmare for you to troubleshoot obscure errors like
“EFI stub: ERROR: Invalid header detected on UEFI supplied FDT, ignoring …”
which is caused by UEFI failure.
It has to be rewritten with more verbose logs.


Did you rebuild the UEFI already? There is a debug build if you rebuild the UEFI source. And verbose log will be printed after you reflash your jetson with that debug binary.