I’ve been trying to get this to work for days but I can’t quite seem to get it to work. No matter what I try I always get stuck somewhere. Does the default initramfs in the qspi memory have the btrfs module? If not how would I create a new one?
The QSPI only has bootloader components, the file system is on either the emmc or the external drive as your NVMe ssd here.
If you don’t know where it gets stuck, maybe you should dump the serial log from uart to tell.
As for initrd, it does not enable btrf by default.
btrfs is not in l4t initrd. You can see here on how to modify it.
This is basically answered by @anhmiuhv, but I thought I’d add a comment in addition to this…
The initrd acts as an adapter. So long as the boot software can read your m.2 NVMe SSD (drivers for reading this would need to be present in boot stages prior to Linux loading, but this has no need to understand btrfs), then if you put a kernel module in the initrd’s “/lib/modules/$(uname -r)/kernel/” at the correct subdirectory, and have the kernel Image in a “/boot” directory which is also readable (in theory you would have a single partition which is small and has nothing but “/boot” in it), then the kernel can load the btrfs for rootfs and mount it on “/”, with “/boot” being mounted on “/” such that the “/boot” partition is still available once Linux runs. The “/boot” would appear as ext4, and everything else which does not cross filesystem “/” would show as btrfs.
I have not actually attempted to create a separate “/boot”, but it shouldn’t be too difficult if you are able to edit an existing initrd. The initrd is just a compressed cpio archive, which is something earlier boot stages all understand.
I tried that approach but looking at the boot log through a serial adapter, the system would only look for the files in what it determined to be the root partition. Is there a way to specify when flashing the board that the boot files are on a different partition then the root files?
Why not you share the full boot log so that we can know your exact problem? Are you talking about initrd or rootfs?
Ok I’ll try again and record the boot logs. However before I dive in again could you explain exactly how the board determines which partition the extlinux.conf file is on?
My plan is, format my ssd like this
nvme0n1p1 - boot - ext4
nvme0n1p2 - root - btrfs
Then copy the entire boot directory from an sd card install that I know works with btrfs. Place all files from /boot/* into the root of partition 1.
Then set the extlinux.conf to reflect the changes.
Finally mount /dev/nvme0n1p1 to /boot in the btrfs root system.
Does this look correct?
Thanks!
[0013.474] I> Scanning busnr: 1 devfn: 0
[0013.478] I> PCIe IDs: 0xa808144d
[0013.481] I> PCIe RID_CC: 0x1080200
[0013.484] I> PCI Config: I/O=0x3a100000, Memory=0x3a200000
[0013.490] I> MEM64 bar_num=0 bar=0x3a200000
[0013.494] I> Number of PCIe devices detected: 2
[0013.498] I> NVME page size: 4096
[0013.502] I> NVMe serial number: S59CNM0R405277F
[0013.506] I> NVMe model number: Samsung SSD 970 EVO Plus 2TB
[0013.513] I> NVMe firmware revision: 2B2QEXM7
[0013.517] I> block_count: 3907029168
[0013.520] I> supported_lba: 0
[0013.523] I> block_size_log2: 0x9
[0013.526] I> tegrabl_create_io_queue_cmd: queue size: 2
[0013.532] I> tegrabl_create_io_queue_cmd: queue size: 2
[0013.537] I> nvme device id 000a0005
[0013.540] I> nvme-5 params source =
[0013.544] I> Found 2 partitions in NVME (instance 5)
[0013.548] I> Look for boot partition
[0013.551] I> Fallback: assuming 0th partition is boot partition
[0013.557] I> Detect filesystem
[0013.560] I> Loading kernel-bootctrl from partition
[0013.565] E> Cannot find partition kernel-bootctrl
[0013.569] E> Cannot open partition kernel-bootctrl
[0013.574] W> tegrabl_get_kernel_bootctrl: failed to read primary bootctrl data
[0013.581] I> Loading kernel-bootctrl_b from partition
[0013.586] E> Cannot find partition kernel-bootctrl_b
[0013.591] E> Cannot open partition kernel-bootctrl_b
[0013.596] W> tegrabl_get_kernel_bootctrl: failed to read recovery bootctrl data
[0013.603] W> tegrabl_get_kernel_bootctrl: use default dummy boot control data
[0013.610] I> Loading extlinux.conf ...
[0013.613] I> Loading extlinux.conf binary from rootfs ...
[0013.619] I> rootfs path: /nvme/boot/extlinux/extlinux.conf
[0013.800] I> lookup_linear_dir:447: Invalid file block num
[0013.800] I> ext2_walk:142: 'boot' lookup failed
[0013.800] I> ext4_open_file:666: '/boot/extlinux/extlinux.conf' lookup failed
[0013.801] E> file /nvme/boot/extlinux/extlinux.conf open failed!!
[0013.801] W> Failed to load extlinux.conf binary from rootfs (err=202113041)
[0013.804] E> Failed to find/load /boot/extlinux/extlinux.conf
[0013.810] I> Loading kernel ...
[0013.813] I> No kernel binary path
[0013.816] I> Continue to load from partition ...
[0013.821] W> No valid slot number is found in scratch register
[0013.826] W> Return default slot: _a
[0013.830] I> A/B: bin_type (37) slot 0
[0013.833] I> Loading kernel from partition
[0013.837] E> Cannot find partition kernel
[0013.841] E> Cannot open partition kernel
[0013.845] E> A/B loader failure
[0013.848]ˇ‚
How did you prepare the file system on your nvme? It looks like the steps should be checked.
I’m going to be honest here, I’ve been winging it. Through studying the L4t release manual and some violent Google searching I’ve at least got a bootable ext4 system. But I’ve probably flashed this board and and repartitioned the drive more then 20 times in the last week.
I think I’m going to let it sit for a while and try to study the boot flow in more depth. Plus I practically dream in file system commands now. Is there a way to close this thread? Maybe In a couple weeks I’ll hit the project again for a few more sleepless nights and report back….
Thanks for the quick responses though!
Let me just put the method here for you to refer to.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.