Jetson-io config chage not saved

hello

While the pwm pin was being used, the pwm pin was deactivated, so I checked it with jetson-io.
The origin of the problem was this.

1.m.2 ssd is installed (but it does not boot from this.)
2. After that, io changes are not saved (fixed by default).

I looked for the cause.
It seemed to be a problem when using m.2 ssd. (Other users seem to use ssd for booting.)

It was similar, but I am not using the ssd for booting, but for storage.

Jetson tried to load the device information in the SSD every time it boots, but there is no information, so it is presumed to load the default pin setting.

/boot/kernel_*.dtb that I applied. It doesn’t seem to load the file properly

Please notify me of saving changes in jetson-io

You can try to share the boot up log so that we can tell what is going on.

Also, what is the jetpack version in use?

The jetpack version is 4.6.1, what kind of log is the bootuplog referring to?

All I know is that there are several types of logs in /var/log due to my lack of knowledge.

Ok. This is the boot log I am talking about.

A huge number of logs came out.
I hope this is the requested log.

Please forgive me for sharing.

You better attach it as as file. This forum can upload file.

Oh
I’ll upload it again.

log.txt (103.1 KB)

All the log you shared is being truncated. I mean some lines which are longer are being truncated…

Sorry for the late reply. Here are all log files.
log.txt (106.9 KB)

Still the same… do you really understand the problem I am talking about here?

The log was received through ssh.

Actually, I don’t understand why you said the log was truncated. However
minicom1.cap (105.9 KB)
, it sends the received file through the log storage function supported by minicom.

The file you are sending now can be accessed directly from the Raspberry Pi screen.
The file is received in .cap format.

Is this file correct?

If not, I really don’t know.

Now the log is correct.

Just take one line from your previous log as example.

[ 0.464467] Tegra Revision: A02p SKU: 0xd0 CPU Process: 0 SoC Process: 0
[ 0.464518] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t19x/galen/kernel-i
[ 0.464572] DTB Build time: Feb 19 2022 09:00:51

And now your log is

[ 0.467773] Tegra Revision: A02p SKU: 0xd0 CPU Process: 0 SoC Process: 0
[ 0.467815] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t19x/galen/kernel-dts/common/tegra194-p2888-0001-p2822-0000-common.dtsi
[ 0.467853] DTB Build time: Feb 19 2022 09:00:51

Is JETSON-IO not properly applied because that one line is missing?

If so, is there any way to solve it?

No, that one line is missing so that I cannot check your log. That’s all. I am checking it now.

Your log indicates

  1. Bootloader tries to boot from your nvme. But it fails because there is no valid extlinux.conf file on your nvme.

0007.340] W> Cannot find any partition table for 000a0000
[0007.345] I> Detect filesystem
[0007.354] I> Loading kernel-bootctrl from partition
[0007.354] I> Loading partition kernel-bootctrl at 0xa4c70000 from device(0x1)
[0007.366] W> tegrabl_get_kernel_bootctrl: magic number(0x00000000) is invalid
[0007.367] W> tegrabl_get_kernel_bootctrl: use default dummy boot control data
[0007.380] I> Loading extlinux.conf …
[0007.380] I> Loading extlinux.conf binary from rootfs …
[0007.383] I> rootfs path: /nvme/boot/extlinux/extlinux.conf
[0007.497] I> lookup_linear_dir:447: Invalid file block num
[0007.497] I> ext2_walk:142: ‘boot’ lookup failed
[0007.497] I> ext4_open_file:666: ‘/boot/extlinux/extlinux.conf’ lookup failed
[0007.498] E> file /nvme/boot/extlinux/extlinux.conf open failed!!
[0007.498] W> Failed to load extlinux.conf binary from rootfs (err=202113041)
[0007.501] E> Failed to find/load /boot/extlinux/extlinux.conf

  1. Actually, your device is totally boot from emmc now. NVMe is not involving it at all.

[ 0.000000] Kernel command line: console=ttyTCU0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 nv-auto-config video=tegrafb earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0xa06aa000 lut_mem=0x2008@0xa06a5000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1

  1. Jetson-IO is basically relying on extlinunx.conf. And now there is no such file, so jetson-io cannot take effect.

The conclusion is you better checking how you prepare to boot from NVMe. Why does the NVMe drive file get corrupted.

There is no boot file in NVME (m.2 SSD). I’m just using it for storage.

Are there any problems when formatting for mounting?

Ok, then what you need to do is remove nvme from your boot list.

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3261/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/getting_started.html

Remove nvme from your cbo.dts.

All right. However, I can’t find /Linux_for_Tegra/bootloader/ described in the documentation.
Does it not come out after installing with the sdk manager?

That is on your host. Not your jetson. Jetson is not able flash itself…

understand.
But the jetson is currently in a different place (far) so is there any way to fix it via ssh?