Some updates. I have an NVME disk for data only (PCIe). Apparently there are some changes in how bootloader works. In 4.3, it reads /boot/extlinux/extlinux.conf from mmc, but in 4.6, it tries to read from my nvme data disk. Since I don’t have a /boot on my nvme data disk, bootloader doesn’t try to use /boot on mmc and directly boots using kernel/dtb partitions.
Regarding my other questions, I see Linux_for_Tegra/bootloader/flash.xml has below:
<partition name="UDA" type="data">
<allocation_policy> sequential </allocation_policy>
<filesystem_type> basic </filesystem_type>
<file_system_attribute> 0 </file_system_attribute>
<allocation_attribute> 0x808 </allocation_attribute>
<percent_reserved> 0 </percent_reserved>
<align_boundary> 4096 </align_boundary>
<description> **Required.** Automatically takes all remaining space on the device except space
occupied by `secondary_gpt`. Allocation attribute must be set to 0x808. This
partition may be mounted and used to store user data. </description>
Does that mean I can freely mkfs.ext4 on this partition and use it in /etc/fstab for both my rootA/B? I assume future flash.sh will still clear it, but other than that, will nvidia tools/scripts/system ever delete my data on UDA partition?
we cannot reproduce issue by adding a new entry with a test kernel (LINUX) and test dtb (FDT) with r32.7.1 on Xavier. (this is test with/without enable rootfsAB).
could you please check the path definition, how about having test kernel image under /boot/ instead of /boot/test/..
You can ONLY reproduce if you have NVME drive (PCIe) that is mounted as data. My /boot directory is on the mmc, but in JP 4.6/4.6.1, bootloader tries to read /boot from NVME. Since my NVME is just data disk and doesn’t have /boot, bootloader fails to find /boot and decides to boot from kernel/dtb partitions. It never bother to try mmcblk0. In JP 4.3, bootloader reads mmcblk0 first and can find /boot.
I saw the new 32.7.2 just released, and tried it. It is even worse now. The bootloader is neither reading the /boot/extlinux/extlinux.conf from nvme, nor emmc. In the last release, as mentioned above, bootloader at least reads the one from nvme.
I need to capture and post later, but what I did yesterday was to put a long TIMEOUT in the /boot/extlinux/extlinux.conf on emmc and nvme, I watched the booting fly through without any pause. I also added something in APPEND, but didn’t see it in /proc/cmdline after system boots up.
Originally the issue was reported for 32.7.1 (JP4.6.1), and was told to be fixed in next release. When the next release (32.7.2) was released, I was just testing the fix and report back the finding. That’s why you see them in the same thread.
There two conversations. Maybe you don’t consider them bugs:
If there is a data nvme disk without OS files or /boot, the emmc will boot but the /boot on the emmc will be ignored. See attached boot.1.txt. Bootloader attempted to find extlinux.conf from nvme but there is none, so it moves on to boot the kernel partitions from emmc. Even though boot order says nvme, emmc, it never moves on to the extlinux on the emmc. boot.1.txt (31.6 KB)
I pulled out the nvme drive, now the extlinux.conf on the emmc is being read, but there is an compatibility issue. Now it is mandated to have an APPEND line to define root device or else boot will HALT.