Let’s clear up a couple of your questions first.
Is the dtbfile configured on the FDT clause in /boot/extlinux/extlinux.conf really loaded or not ?
Yes, U-Boot always honors the DTB file listed via FDT. You can see that it was loaded at the beginning of your UART log dump in your initial post:
374522 bytes read in 31 ms (11.5 MiB/s)
I get strange messages coming from uboot before starting linux itself :
The 3 ‘ERROR: reserving fdt memory region failed’ messages from U-Boot are due to 3 fbX_carveout nodes in the DTB that are empty (0 address, 0 size). This is due to the fact that CBoot did not populate those nodes because it didn’t find a display attached/active for them. Typically only fb0_carveout is populated (HDMI), so you will always see these messages from U-Boot and can ignore them (you should see a similar message from the kernel).
Now on to phandle duplication/corruption in the DTB. When U-Boot is asked to load a DTB via FDT in extlinux.conf (a disk-based kernel DTB), it has to merge the internal DTB nodes/properties (from the RAM-based DTB) with this disk-based DTB before it can hand it to the kernel on boot. This feature is called DTB merge. It’s necessary because nvtboot, CBoot, and even U-Boot may have done HW probe to detect carveouts, plug-in boards, etc. that then need to be updated in the current DTB for kernel use. A disk-based DTB has none of this info, since it’s static.
When the disk-based DTB matches the ‘flashed’ DTB (that eventually becomes the RAM-based DTB), U-Boot has no issue with merging the HW info, since the phandles match. But when the disk-based DTB has been changed by an end-user/customer, depending on the extent of the changes, the disk-based DTB can have re-ordered phandles (as part of the recompilation that DTC does), which might now conflict with the phandles in the RAM-based DTB. I’ve recently made a change to L4T U-Boot to attempt to detect this and skip the merge/update of the external-memory-controller node (or any source node that uses phandles), and emit a warning during boot. But that change won’t be available until we release 32.6, which is due soon IIUC.
So in your case, it appears you are seeing duplicate phandles in the final DTB that was given to the kernel by U-Boot. This can cause the kernel driver that uses those nodes (iommu, xusb-padctl in your case) to spew warnings, abort and even hang the system. The fix for that (for now) is to use your ‘new’ DTB with your changes as the original, flashed DTB, so that nvtboot/CBoot/U-Boot all get the changed nodes/phandles from the start. Doing that means you do NOT need to also list it in extlinux.conf FDT. It’s less convenient, requiring you to either sign & ‘dd’ your new DTB from the kernel command line, or to reflash it via ‘flash.sh -k DTB “your-board” mmcblk0p1’, which will handle signing/reflashing just the DTB to your TX2’s flash (eMMC).
Another fix coming in R32.6 U-Boot is the addition of DTBO (overlay) support, which should mean you can add your DTB changes to an overlay DTB that gets loaded via extlinux.conf (label FDTOVERLAYS) by U-Boot, and any phandle issues are handled by the overlay support in the FDT lib. We’ve tested this with the same overlays (audio, CAN, SPI, etc.) that are available in the Jetson.IO package. It may be useful for your changes.
HTH,
Tom