Yes, that is the log we want to check.
This indeed tells something.
[0009.350] I> No kernel-dtb binary path
[0009.356] I> A/B: bin_type (38) slot 1
[0009.357] I> Loading kernel-dtb_b from partition
[0009.357] I> Loading partition kernel-dtb_b at 0x91000000 from device(0x1)
[0009.368] I> Validate kernel-dtb …
[0009.368] I> T19x: Authenticate kernel-dtb (bin_type: 38), max size 0x400000
According to above log, the dtb is loaded from partition. However, it is somehow reading the kernel-dtb_b but not kernel-dtb partition. A partition with _b suffix is a redundancy partition that could be used as a backup.
And I suspect flash.sh only flash the kernel-dtb but not kernel-dtb_b partition. That is why no matter how many times you flash the dtb, it won’t take effect.
We have to check why the method from jetson_hacks will let you enable A/B redundancy and even crashed slot A.
Could you use below command and show us the status of A/B slot?
root@tegra-ubuntu:/home/nvidia# nvbootctrl dump-slots-info
and if you don’t want to figure out the root cause, reflash the whole device or write FDT in extlinux.conf are both a workaround.
But remember that the extlinux.conf you have to modify is on emmc but not ssd.