I’ve made some changes to my device tree source file on my host. ( the file that is being used is tegra210-jetson-tx1-p2597-2180-a01-devkit.dts)
I’ve flashed the device and applied the binary files according to ridgerun’s process on the following page: Compiling Tegra X1/X2 source code - RidgeRun Developer Connection
However, when I run the dmesg log it shows that the binary file was last compiled 6 days ago.
Shown here:
[ 0.000000] Machine: jetson_tx1
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Reserved memory: initialized node iram-carveout, compatible id nvidia,iram-carveout
[ 0.000000] Tegra reserved memory:
LP0: ff2bf000 - ff2bffff
Bootloader framebuffer: 00000000 - 00000000
Bootloader framebuffer2: 00000000 - 00000000
Framebuffer: 00000000 - 00000000
2nd Framebuffer: 00000000 - 00000000
Carveout: 00000000 - 00000000
Vpr: 00000000 - 00000000
Tsec: 00000000 - 00000000
Bootloader Debug Data: 00000000 - 00000000
[ 0.000000] Nvdumper: ff23f000 - ff23ffff
[ 0.000000] cma: CMA: reserved 16 MiB at fdc00000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv0.2 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[b][ 0.000000] DTS File Name: arch/arm64/boot/dts/tegra210-jetson-tx1-p2597-2180-a01-devkit.dts
[ 0.000000] DTB Build time: May 19 2017 20:09:21
[/b]
[ 0.000000] Tegra21: Speedo/IDDQ fuse revision 4
[ 0.000000] Tegra21: CPU Speedo ID 7, Soc Speedo ID 0, Gpu Speedo ID 2
[ 0.000000] Tegra21: CPU Process ID 0, Soc Process ID 0, Gpu Process ID 0
[ 0.000000] Tegra21: CPU Speedo value 2026, Soc Speedo value 1914, Gpu Speedo value 2024
I’m confused on how to apply the dtb file when it is in the boot of the TX1.
How would I update this dtb?
Any help would be appreciated.
The dtb which is used (once in Linux) is named via the FDT key/value pair in “/boot/extlinux/extlinux.conf”. You might compare that entry to the name of your file.
hi linuxdev,
thanks for the quick reply.
I checked the FDT key/values pair in “/boot/extlinux/extlinux.conf” on my TX1.
It is the correct dtb file except for the build time:
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
Could this be a problem when I applied the binaries to the rootfs? However, when I do this it says it applies them successfully according to the steps on Compiling Tegra X1/X2 source code - RidgeRun Developer Connection
“apply_binaries.sh” and the flash.sh command itself will alter boot files in the rootfs. Edits will typically be lost if this is where you made the change…changes in rootfs boot directory configuration files before flash are not preserved, changes such as this are preserved only on a running Jetson. Were you not copying your changes directly to a running Jetson? If not, then there are ways around this using flash.sh, but it requires extra work.
I was copying my changes directly to a running jetson.
But I did go around it using flash.sh it just took awhile and was more work.
before I reflashed it I was able to use sudo, but now I don’t.
Why would that be?
Your sample rootfs probably did not have permissions preserved. You have to unpack sample rootfs using sudo, and you have to use sudo on the apply_binaries.sh step. Something easier to forget is that the underlying file system must be a native Linux type, e.g., ext3 or ext4 works, but NTFS or VFAT does not. You can run “df -H -T” to see file system type. Also the flash.sh script itself needs to be run sudo.
The native file Linux type when I type in the command “df -H -T” is ext4. So I don’t think that could be the issue.
I made sure to use sudo on the apply_binaries.sh step.
What step are you talking about when unpacking the sample rootfs using sudo?
Would I have to use sudo at the step where you overwrite and replace the default images with my own images?
Did you use sudo to unpack the sample rootfs into the rootfs directory? This is an absolute must, and failing to use sudo for unpacking guarantees the problem you are having. If you go to the rootfs subdirectory on your host, and run “ls -l sudo” from “rootfs/usr/bin/”, does it show owner/group root, and permissions like this?
-rw<b>s</b>r-xr-x.
…if not, there is the problem.
The reason I’m concentrating on this as the cause is that permissions from unpacking the sample rootfs are so easy to forget about, and that there have been probably over a dozen people who have had this same issue…and every time it turned out to be permissions of the Jetson’s sudo were not correct (the only other likely reason permissions would be wrong beyond file unpack/copy without sudo is that the system went through a failed hacking attempt).
EDIT: The name of the sample rootfs file on R24.2.1 is “Tegra_Linux_Sample-Root-Filesystem_R24.2.1_aarch64.tbz2”. This would fail from the rootfs subdirectory:
tar -xjf /where/ever/it/is/Tegra_Linux_Sample-Root-Filesystem_R24.2.1_aarch64.tbz2
…this would work:
<b>sudo</b> tar -xjf /where/ever/it/is/Tegra_Linux_Sample-Root-Filesystem_R24.2.1_aarch64.tbz2
EDIT 2: Anything which replaces or overwrites system files would have to preserve correct permissions. Not all files with the need to have correct permissions for security reasons would report an issue, but the issue would still be there. sudo has extra security on it, this will always complain if it is wrong.
Yeah that seems to be the issue when I went to the directory and type “ls -l sudo” from “rootfs/usr/bin” it gave me
-rwxrrwxr--
I don’t remember changing file permissions at anytime, but maybe I did.
Is this something I can change to the file permissions above to fix the problem or is it easier to reinstall and start over?
The trouble is you cannot unpack anything with special permissions or owned by root if the user doing the unpack is not root. Permissions and ownership would be modified by the unpacking itself in that case. Basically you have to delete your rootfs content and unpack again (plus apply_binaries.sh). Then you are ready to flash. The number of altered files from a non-root unpack needing permission changes would be absolutely enormous…fixing an entire operating system by hand is not practical (and sample rootfs is an entire operating system).