I am currently considering using a customized rootfs on the Orin Nx.
It seems that the initrd flash script ( l4t_initrd_flash.sh ) requires specific packages to be present in the rootfs.
I have understood that the following are necessary.
But it still seems insufficient, and using that rootfs causes the initrd flash script to fail when flashing to the qspi.
mtd_debug: error!: open()
QSPI storage size: bytes.
[ 132]: l4t_flash_from_kernel: Successfully flash the external device
[ 132]: l4t_flash_from_kernel: The device size indicated in the partition layout xml is smaller than the actual size. This utility will try to fix the GPT.
[ 132]: l4t_flash_from_kernel: Error flashing qspi
I checked the document pages but could not find any that mentioned such information.
Please tell me about the packages and settings that need to be introduced into the rootfs for using the initrd flash. Thank you for your time.
modprobe: FATAL: Module qspi_mtd not found in directory /lib/modules/5.10.104-tegra
modprobe: FATAL: Module spi-tegra210-qspi not found in directory /lib/modules/5.10.104-tegra
modprobe: FATAL: Module pwm-fan not found in directory /lib/modules/5.10.104-tegra
Did you run sudo ./apply_binaries.sh so kernel modules are populated correctly?
No matter how you customize your rootfs, these stuff is still needed.
Thank you for the prompt analysis.
In order to choose which Nvidia packages to integrate, I have not completed the entire process of apply_binaries.sh, and have limited myself to the above-mentioned kernel integration process. I understand that I have also omitted essential contents in the integration process of apply_binaries.sh.
I will make the necessary corrections and test the operation.
I will provide an update on the results of the verification later.
When I checked the rootfs deployed in the environment where the flash was performed, it seems that the target .ko file exists even without any modifications. However, since the error you pointed out is occurring in the serial console, it indeed appears that there is an issue with the kernel linking. What could be the possible causes? Are there any other items that should be checked?
It seems challenging to upload everything under the target folder as is, even if compressed, due to size constraints. For now, I will send you the actual ko files mentioned above and a list of contents from under the target folder. ko.zip (531.0 KB) lib_modules_list.txt (124.8 KB)
I mean I only need the result of ls under that folder.
For example, modprobe relies on all these modules.xxx stuff to search for the kernel modules being loaded, so if modules are not listed here, or these dependency files do not even exist, modprobe will fail even if the .ko is placed correctly.
However, a point of concern for me is that, even when using the same kernel artifacts, this information is included when running apply_binaries.sh based on the nvidia sample rootfs. Is this information also generated during the process of apply_binaries.sh, apart from the kernel artifacts?
I understand that apply_binaries.sh is not performing actions like depmod, but rather, it is retrieving relevant information from the synthesized content. It seems likely that there may have been a misunderstanding on my part regarding the process during synthesis, so I will double-check this on my end. The main issue of this topic has been resolved with your previous response.