After apt dist-upgrade to jetpack-4.6.5, emc_freq dropped to 204 MHz instead of 1600 MHz

Hello experts,

we use jetson-nano based custom boards, running currently jetpack-4.6.4, Frequency of our ddr/emc as shown by tegrastats is 1600 MHz.

we tried to update to jetpack-4.6.5 by running ‘sudo apt dist-upgrade’ and rebooted with our kernel and dtb (using FDT clause in /boot/extlinux/extlinux.conf) but immediately noticed that the emc freq had dropped to 204 MHz. After further inspection we noticed that the partitions /dev/disk/by-partlabel/DTB (and DTB-1) had been overwritten by another DTB, which I surmise is a cause of that frequency drop. How can I prevent my DTB partitions being overwrittem by some unrelated DTB ?


I don’t know what is that point to tell “a weird another DTB” overwrite my partition.
If you want to upgrade jp4.6.5, of course the dtb will get updated too. It is not “another DTB”…

Your usage is wrong. If this is not NV devkit, then you cannot use apt-get upgrade to update the system.
NVIDIA does not know what kind of board you are using. We just provided the package for updating NV devkit.

Custom board cannot directly use the NVIDIA source to upgrade jetpack…

Hello Wayne,

Which specific .deb package does overwrite the DTB partitions ?

I can’t answer this, but you might find the following of use.

Not everything on the Jetson is from a package. When installing the flash software on the host PC (manually), it starts by unpacking a purely Ubuntu source. When the command “sudo ./” is run, much is added to that in the form of NVIDIA-specific content. This is almost the exact content that gets flashed by generating a loopback image of the rootfs (and there is a lot more than just rootfs).

If you were then to flash on command line, without JetPack, then the command might be something like this:

  • sudo ./ jetson-nano-devkit mmcblk1p1
    (for an SD card model)
  • sudo ./ jetson-nano-emmc mmcblk0p1
    (for an eMMC model)

The last parameter is about where to store the rootfs. The parameter before this is actually a reference to a “.conf” file (e.g., 'jetson-nano-devkit.conf). This is a series of files which will include other files, and some are specific to the module, while others are specific to the carrier board.

A side-effect of picking a target, and going through the series of files included (starting with the .conf file of the flash target) is that just prior to generating the image which will get flashed board-specific and boot-specific content will get copied into the rootfs.

Examples of content which is copied in just prior to image generation is the kernel Image and device trees. Very closely related to this, the actual “boot/extlinux/extlinux.conf”. This latter file specifies things like the kernel, initrd (if used), and device tree (the FDT entry).

Normally the extlinux.conf will state where to get the device tree, including its name, but there are exceptions. To talk about exceptions one has to know something about whether this is a dev kit or if this is an eMMC module on a third party carrier board.

For dev kits there is no eMMC. All of the content which boot and the equivalent of a BIOS goes into QSPI memory on the module itself. In the case of an eMMC model, this normally goes to partitions in the eMMC (remember that .conf file? this specifies some of this).

Note that non-rootfs content also contains a device tree. When you specify a board target through that .conf file there will be a device tree file named somewhere in the chain of included configuration. For an eMMC model there will be a device tree in both the /boot and in a partition as binary content.

Everything placed in a non-rootfs partition of an eMMC model is signed before going into that partition. This is all binary content which can be read without understanding any filesystem type. If the content does not have a valid signature, then that content will be refused. However, a default eMMC model does not have the security fuses burned, which means the signature is a NULL signature. The QSPI content of an SD card dev kit model does not use this fuse mechanism, so talking about a signature is kind of pointless in QSPI, but know that QSPI also have the equivalent of the binary partitions of eMMC (but it is in QSPI memory, not eMMC).

Any time the extlinux.conf sees the FDT entry, then this is normally the highest priority, and that file will be used. Changed the extlinux.conf? You just likely changed the FDT entry. If that entry does not exist, or if the entry names something that is not valid, then device tree reverts to the partition or QSPI content, depending on model. The same is true for more parameters, e.g., the kernel Image file is named in extlinux.conf, and this is how a kernel is normally found; if no entry exists, or if the entry is invalid, then search reverts to the binary content of the partition or QSPI (if it exists). If the security fuses of an eMMC model are burned, then only the partition content is allowed even if extlinux.conf names files that are otherwise valid.

Perhaps your extlinux.conf changed, and only an update to the boot entry which is default is needed; the FDT might just need to name a different file. Perhaps there is no entry, and boot has reverted to a binary partition. Perhaps this is an eMMC model and security fuses were burned, and you only changed content in the rootfs without updating binary partitions.

If you really want to see what is going on you must get a full serial console boot log. This log shows what goes on during boot stages as well as the content of the dmesg from when the Linux kernel loads. You need to see what happens for device tree content before Linux ever starts (the bootloader is its own bare metal operating system and uses devices that are not plug-n-play, so the bootloader needs to know how to find those devices and what specifications/arguments to use). Knowing this wouldn’t change what is used, but you could understand where the device tree is initially loading from (device trees have many nodes, some might be added later on in boot).

Note that a normal flash uses default non-rootfs content. If you’ve cloned an eMMC Jetson, and you put your clone in to replace the generated content, and then flash to tell it to reuse the existing (cloned) image, all content is flashed, but the non-rootfs content is standardized (think of this flashing the BIOS…which a Jetson does not have…but that it is very rare that someone wants modified boot content). If that content is at least partially from a package, then your upgrade might have altered this. Boot content is possibly modified for a custom carrier board even if it is only in the device tree or the specification of which device tree to use.


saving /dev/disk/by-partlabel/DTB and DTB-1 before the update and restoring them after the update solves the problem.