How to save time on testing incremental changes done to the device tree?

[octonout]

Hi. I am working on making changes to the device tree as per our custom board for Jetson Nano. After some searching I found out that applying the new device tree patch with $ bitbake -c do_patch linux-tegra and then compiling the kernel with $ bitbake -f -c do_compile linux-tegra gives you the .dtb in <kernel-build-dir>/arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0002-p3449-0000-b00.dtb.

Now I would rather not bitbake the whole image to get the new tegraflash-package as it takes a lot of time. Instead is it possible to use the doflash.sh in the tegraflash archive to flash just the partitions from where the kernel gets its .dtb?

NVIDIA developer guide has this page where they touch on the same. But I am not sure how I can get the newly compiled .dtb in the partition. I tried replacing the tegra210-p3448-0002-p3449-0000-b00.dtb in the directory where I extracted the tegraflash archive. But now it doesn't show bootlogs during startup and ssh isn't working. Seems like that isn't the way t do it.

[madisongh]

You could try using ./doflash.sh -c "sign; write DTB signed/tegra210-p3448-0002-p3449-0000-b00.dtb.signed" flash just the one partition. I may not have the filename exactly right, but I'm pretty sure the DTB has to be signed before being flashed.

[octonout]

Hey. Thanks for the reply. I copied the newly compiled .dtb to the tegraflash dir and flashed it using ./doflash.sh -c "sign; write DTB signed/tegra210-p3448-0002-p3449-0000-b00.dtb.signed". The flashing was successful. But on reboot, the changes made to the DTB are not reflected? I am confused. The flash log suggests that both the DTB and DTB-1 which is the partition that stores the redundant copy of the Kernel DT is flashed.

Is the method of copying the newly compiled .dtb to the tegraflash dir wrong? Do I have to rebuild the image and get the new tegraflash archive?

[madisongh]

Well, you could flash DTB-1 the same way, but it should only use that partition as a fallback if the DTB partition is unusable. Do you have a serial console attached, so you can see any messages from the bootloaders about the device tree?

[octonout]

Returning to this topic after a long time. With the above suggestions I was able to flash newly compiled dtb onto the board. The procedure I followed was the same one that I mentioned in my first post. So I was compiling the new dtb and them replacing the tegra210-p3448-0002-p3449-0000-b00.dtb with it. I do not exactly remember whether I flashed the entire image or just the dtb with the command you mentioned in your last post. But flashing with the replaced dtb, some functionality breaks. For example I was not able to SSH into the Nano after flashing.

I was wondering whether the following could be possible,

1. bitbake -c do_patch linux-tegra
2. bitbake -f -c do_compile linux-tegra
3. The above two steps give you the dtb in <kernel-build-dir>/arch/arm64/boot/dts/_ddot_/_ddot_/_ddot_/_ddot_/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0002-p3449-0000-b00.dtb
4. Run the recipe/recipes that pull the newly built dtb from the path in step 3 into the tegraflash and create the tegraflash package.
5. Extract the newly created tegraflash and flash the entire image.

But for this I would have to know which recipes to run after the new dtb is created. Because, right now I just use the command to build the entire image. Can you tell me when exactly is the new dtb picked up and hot it is put into the tegraflash tar?

[madisongh]

The kernel recipe's do_deploy task copies the DTB to ${DEPLOY_DIR_IMAGE}. The tegraflash generator picks it up from there (see classes/image_types_tegra.bbclass).

[0xAl3xH]

can we somehow achieve this with initrd-flash as well?