change dtb file using file copy(scp) not use

I followed “Jetson_X2_Developer_Kit_User_Guide.pdf” and flash binaries using jetpack.
After then, I tried to change dtb file using file copy(scp) not
I refered below link for this and modified extlinux.conf // Add FDT /boot/tegra186-quill-p3310-1000-c03-00-base.dtb

but after this, board has not boot up with below error message.
Do I need more fix for it?

Enter choice: 1: primary kernel
Retrieving file: /boot/Image
20484864 bytes read in 537 ms (36.4 MiB/s)
append: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 memtype=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x03100000 nvdumper_reserved=0x2772e0000 gpt tegra_fbmem2=0x800000@0x969ec000 lut_mem2=0x2008@0x969e9000 tegraid= tegra_keep_boot_clocks maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2.1 androidboot.serialno=0322017038084 bl_prof_dataptr=0x10000@0x277040000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
Retrieving file: /boot/tegra186-quill-p3310-1000-c03-00-base.dtb
279208 bytes read in 63 ms (4.2 MiB/s)

Flattened Device Tree blob at 82200000

Booting using the fdt blob at 0x82200000
reserving fdt memory region: addr=80000000 size=10000
Using Device Tree in place at 0000000082200000, end 00000000822472a7
WARNING: could not set reg FDT_ERR_NOSPACE.
ERROR: arch-specific fdt fixup failed

  • must RESET the board to recover.

Unless you are using an older version of L4T you cannot use the FDT entry in extlinux.conf. The specifics vary by which release of L4T. Which version are you using?

The newer versions merge some of their boot environment into the device tree, and the device tree itself is in a partition. The flash tool may do some editing or adjustments before placing the tree into the partition.

I’m using
So, Do I have to update kernel image(Image) using file copy(scp) and update dtb to partition using flash tool seperatly?

That is correct. I know it isn’t convenient, but if you look at the list of partitions (using “sudo gdisk -l”) it looks like there is some work going on to actually ease in-place updates (I’m only speculating…but if that is the case, then the pain of the current setup will some day become easier instead of worse).

Okay, I understand.
Thank you for your answer.