As the title says, I rebooted after apt-get upgrade in jetson ubuntu.
It is found that the dts name has become:
“/dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/ t19x/jakku/kernel-dts/tegra194-p3668-all-p3509-0000.dts”
This is not the dtb file name I used before, but I tried to replace the device tree in /boot/dtb/ or use extlinux.conf to add FDT to directly specify the dtb path, but I couldn’t replace the Device Tree.
it’s true that apt upgrade will update the BSP for moving to the to the latest point release version.
you may check developer guide, Building Kernel Debian Packages Yourself, for making your own changes, and building the debian packages.
please check the sources list, /etc/apt/sources.list.d/nvidia-l4t-apt-source.list. it’ll move to the release version you’ve point to.
currently, 4.6.1 => 5.0 isn’t support since JP5.0 DP is now developer preview version.
are you having the device fused?
could you please also check bootloader logs, please check whether it’s loading via file system or kernel-dtb partition.
OTA means Over-the-Air update. When you run apt-get upgrade, if you didn’t remove nvidia source from source list, then it will upgrade the jetpack version. And that is the OTA I am talking about. Since jetpack does not know your device tree change, it will be gone.
Also, I am not sure why you want to mark your comment in code block. That is not necessary.
Jerry already replied your question in previous comment. Please do read it first. If you don’t understand, point out which part you cannot understand instead of keeping asking same questions again and again.
Although it has never been done, this document seems to describe how to package the BSP as a Debian deb package to install and update the OS, so that’s correct, right?
I would like to ask the OS updated by this practice, if the apt-get upgrade command is executed in the OS, is there a way to avoid this command from changing the DeviceTree?
Or is this problem avoided because of the “nvidia-l4t-core” relationship?
Because there is a passage in that document that says:
“nvidia-l4t-core also prevents a partial upgrade, in which one L4T package upgrades to a new major release (e.g. release 32.4 to release 32.5), but other L4T packages that depend on it are not upgraded as well. Partial upgrades can cause compatibility issues between firmware, programs, and libraries that have been upgraded and ones that have not.”
I compared the changes of the bootloder log before and after apt-get upgrade and found several problems. The bootloader.log before and after the update will be placed in the attachment.
CBoot was forced to update. From the update record of apt-get upgrade, it should be updated to version 32.7.2, which was originally version 32.7.1. nvidia-l4t-apt-source.list.txt (697 Bytes)
The following error occurs when the updated CBoot loads extlinux.conf, so I cannot directly specify the dts file through extlinux.conf.
[0010.122] I> ext4_read_data_from_extent:298: Total file read should not be larger than file stat size
[0010.123] E> file /sdmmc_user/boot/extlinux/extlinux.conf read failed!!
In the bootloader.log, when the dts file in the specified location cannot be obtained from extlinux.conf, it will be changed to “Loading kernel-dtb_b from partition” This description looks like reading the dtb table from the partition.
May I ask which partition you read here?
Is there a way for us to burn the dtb file dd to the partition to replace the dtb by ourselves?
What special treatment is required?
[0011.305] I> Loading kernel-dtb_b from partition
[0011.306] I> Loading partition kernel-dtb_b at 0x91000000 from device(0x1)
there’s an error for loading extlinux.conf, let me check whether the fixes is already included or not.
[0010.055] I> Loading extlinux.conf ...
[0010.055] I> Loading extlinux.conf binary from rootfs ...
[0010.055] I> rootfs path: /sdmmc_user/boot/extlinux/extlinux.conf
[0010.122] I> ext4_read_data_from_extent:298: Total file read should not be larger than file stat size
[0010.123] E> file /sdmmc_user/boot/extlinux/extlinux.conf read failed!!
[0010.124] W> Failed to load extlinux.conf binary from rootfs (err=202113305)
[0010.124] E> Failed to find/load /boot/extlinux/extlinux.conf
so, it’s loading device tree blob via kernel-dtb partition.
you may perform flash script to update its partition, i.e. $ sudo ./flash.sh -r -k kernel-dtb jetson-xavier-nx-devkit mmcblk0p1
you could also use --no-flash commands to create the dtb binary locally, then you may use dd commands to write the partition, $ sudo ./flash.sh --no-flash -r -k kernel-dtb jetson-xavier-nx-devkit mmcblk0p1
I think the topic is a little bit out of the rail.
Your original question is “you don’t want the apt-get upgrade to change your system”. But now you are asking a bug that happened after you run apt-get upgrade and system got upgraded.
Can we focus on your original issue about what is the exact question you want to ask? Do you want “apt-get upgrade” to upgrade your system or not?
Or more specific, what is your definition of “system”? To me, device tree is also part of system. To you, seems not. So better clarifying this.
What we expect is to update the kit, but we don’t want to change the deviceTree.
I don’t think DeviceTree should be updated arbitrarily.
Because the Jetson platform is a module type, it will be matched with various baseboards. If the Device Tree is randomly updated by apt-get upgrade, it will cause problems with the hardware supported on the baseboard. I think this is a bit unreasonable.
You can just take “apt-get upgrade” same as installing the sdkmanager again. But with newer version. Since sdkmanager didn’t know your change or your board, it will by default installing default jetpack software.
If you don’t want it, you need to remove it from apt source list as Jerry’s comment. But we don’t provide to remove it separately. For example, you cannot pick you only want bootloader to update but not kernel dtb. It is either all of them or none of them.
Also, your concept has something not fully correct. The device tree is actually a pair with kernel. You cannot expect everything would work fine if you only update kernel but not updating device tree.
For example, we changed the network driver in jp4.5. There were lots of users only updating kernel but not dtb at that time and their ethernet was gone then. If you understand how device tree is working, you would know what I am telling.