Xavier AGX Flash script loads different dtb's when dtb's are purged before build

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

I’m trying to build the kernel and dtb’s for a Jetson Xavier AGX 16GB system using Diamond’s Stevie base board (NVidia official devkits are unobtainium.) The problem is that when flashing the board, it’s loading stale DTBs and not the ones I built. This causes my econ cameras to fail to initialize.

My build uses the tarball downloads (eg, Jetson_Linux_R32.6.1_aarch64.tbz2, Tegra_Linux_Sample-Root-Filesystem_R32.6.1_aarch64.tbz2)

When I clear out the precompiled DTBs from the files above then do a full kernel build, it doesn’t generate the DTBs that the flash script expects. Even stranger, the flash script expects different DTBs based on whether or not I clear out the precompiled DTBs.

Flash command:
sudo ./flash.sh jetson-agx-xavier-devkit mmcblk0p1

flash.xml snippet when not purging precompiled DTBs:

<partition name="bpmp-fw-dtb" type="bpmp_fw_dtb" oem_sign="true">
    <allocation_policy> sequential </allocation_policy>
    <filesystem_type> basic </filesystem_type>
    <size> 1048576 </size>
    <file_system_attribute> 0 </file_system_attribute>
    <allocation_attribute> 8 </allocation_attribute>
    <percent_reserved> 0 </percent_reserved>
    <filename> tegra194-a02-bpmp-p2888-a04.dtb </filename>
    <description> **Required.** Slot A; contains BPMP firmware device tree blob
      (DTB). </description>
</partition>
<partition name="bpmp-fw-dtb_b" type="bpmp_fw_dtb" oem_sign="true">
    <allocation_policy> sequential </allocation_policy>
    <filesystem_type> basic </filesystem_type>
    <size> 1048576 </size>
    <file_system_attribute> 0 </file_system_attribute>
    <allocation_attribute> 8 </allocation_attribute>
    <percent_reserved> 0 </percent_reserved>
    <filename> tegra194-a02-bpmp-p2888-a04.dtb </filename>
    <description> **Required.** Slot B; contains BPMP firmware device tree blob
      (DTB). </description>
</partition>

flash.xml snippet when purging precompiled DTBs:
Note: This will fail to flash, as it expects BPFkernel_tegra194-p2888-0001-p2822-0000.dtb

<partition name="bpmp-fw-dtb" type="bpmp_fw_dtb" oem_sign="true">
    <allocation_policy> sequential </allocation_policy>
    <filesystem_type> basic </filesystem_type>
    <size> 1048576 </size>
    <file_system_attribute> 0 </file_system_attribute>
    <allocation_attribute> 8 </allocation_attribute>
    <percent_reserved> 0 </percent_reserved>
    <filename> BPFkernel_tegra194-p2888-0001-p2822-0000.dtb </filename>
    <description> **Required.** Slot A; contains BPMP firmware device tree blob
      (DTB). </description>
</partition>
<partition name="bpmp-fw-dtb_b" type="bpmp_fw_dtb" oem_sign="true">
    <allocation_policy> sequential </allocation_policy>
    <filesystem_type> basic </filesystem_type>
    <size> 1048576 </size>
    <file_system_attribute> 0 </file_system_attribute>
    <allocation_attribute> 8 </allocation_attribute>
    <percent_reserved> 0 </percent_reserved>
    <filename> BPFkernel_tegra194-p2888-0001-p2822-0000.dtb </filename>
    <description> **Required.** Slot B; contains BPMP firmware device tree blob
      (DTB). </description>
</partition>

So… we can see that it wants tegra194-a02-bpmp-p2888-a04.dtb when the precompiled DTBs are not purge, and it wants BPFkernel_tegra194-p2888-0001-p2822-0000.dtb when the DTBs are purged.

My questions are:

1) Why does the flash script expect different DTBs when the precompiled ones are purged?

2) What is the correct DTB file to be loading for the Xavier AGX 16 GB?

3) How does NVidia assure that precompiled trash doesn’t end up in the build output? I’m not going to lie, this build platform looks ultra sketchy.

3

Hi,

I am not sure how did you get this situation. What does that mean “purging precompiled DTBs”?
And why is that related to flash.xml? How did you get flash.xml become that?

I mean where did this “BPFkernel_tegra194-p2888-0001-p2822-0000.dtb” come from? Is it coming out automatically or it is changed by you?

Some clarification here:

  1. BPMP dtb and kernel dtb are two different things. We didn’t release bpmp dtb’s source. So generally, what you changed is probably kernel dtb.

  2. When it comes to update kernel dtb, you never and should not change flash.xml. Directly put your kernel dtb to Linux_for_Tegra/kernel/dtb and replace the old one.

  3. To know what is “old one”, open the board config you are using for flash and it will tell.
    For example, if you are using

sudo ./flash.sh jetson-agx-xavier-devkit mmcblk0p1

Then your board config is jetson-agx-xavier-devkit.conf under Linux_for_Tegra.

4

I can’t answer, but it is useful to log the command line flash. This shows where flash.sh copies files into flash software directories, and then from that into “Linux_for_Tegra/rootfs/” prior to creating the flash image. Example:
sudo ./flash.sh jetson-agx-xavier-devkit mmcblk0p1 2>&1 tee log_flash.txt
(then you can see what is copied from where)

5

Ahhhh, that explains it. I didn’t realize the BPMP dtb was only provided as a binary blob and wasn’t being compiled during the build.

I wasn’t actually modifying the flash.xml- I was just using it to figure out what the flash script was trying it load. Sounds like the flash script just breaks horribly when it can’t find the precompiled dtbs that it expects to be presents. I guess I just need to be more selective to make sure I’m only cleaning out the kernel dtbs.

Thanks for the help!

6

Why do you want to “clean out” dtb? You want to leave only one dtb file on the host?

7

Hey Wayne-

I was trying to clean out the dtbs as a troubleshooting step. I thought a prebuilt kernel dtb was getting loaded onto board, and not the one I was building, but it looks like it’s something else. The new issue I’m stuck on is the display failing to initialize after the gnome-initial-setup reboots the system, but I can start a new thread for that to keep things on topic.

The high level of what I’m trying to do is to get a build working with the patch files from Diamond (for the carrier board), and from my camera vendor for my GMSL2 cameras. The patch files I got from Diamond are fine, but the ones received from this camera vendor are broken. The patch file is in the wrong direction, so it’s pretty clear they never tested them. It’s one of those cases of learning a platform by starting with a broken project.

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.