About the packages and settings required for the initrd flash script

[koichi.tanoiri]

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.

• mtd-utils
• kmod
• parted
• libparted2

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.

---

log file

flash_1-4_0_20231114-181546.log (18.6 KB)

Regarding other contents that are being confirmed

• When using the same kernel, dtb, conf with the initrd flash and utilizing Nvidia’s sample rootfs, the flash is successful.
• When using the same kernel, dtb, conf, and rootfs with the standard flash script (flash.sh), the flash is successful.

[DaveYYY]

Hi,

Can you please also dump the serial console log during flashing?
What packages are installed in the rootfs now? I need the full list.

@koichi.tanoiri

When using the same kernel, dtb, conf, and rootfs with the standard flash script (flash.sh), the flash is successful.

This is expected because flashing with flash.sh does not require device tree/driver stuff.

[koichi.tanoiri]

Hi Dave, Thank you for your reply.
The serial console log and the list of installed packages are as follows:

serial_console_log.txt (248.8 KB)
install_package_list.txt (6.9 KB)

The base Ubuntu used is arm64v8/ubuntu:20.04.
Also, the Nvidia-related packages are integrated as follows, and the kernel is integrated using the following procedure.

• jetson-gpio-common_2.1.1ubuntu1_arm64.deb
• nv_tegra/config.tbz2
• nv_tegra/nvidia_drivers.tbz2
• nv_tegra/nvidia_tool.tbz2
• nv_tegra/nv_sample_apps/nvgstapps.tbz2
• kernel

  tar -xjpmf kernel_supplements.tbz2;
  install -o 0 -g 0 -m 0644 -CDv Image /boot/Image ;
  install -o 0 -g 0 -m 0644 -CDv /dtb/*.dtb* /boot ;
  

Thank you

[DaveYYY]

Hi,

By saying serial console log, I’m referring to something like this:

Jetson Nano & NX Style - Serial Debug Console - JetsonHacks

You are still giving log from the host side.

[koichi.tanoiri]

Hi,

I see, I misunderstood. Here is the serial console log.

serial_cosole_log.txt (96.9 KB)

Thank you.

[DaveYYY]

Hi,

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.

[DaveYYY]

For example, they are located at:

davey@dave-yu-nvidia-pc:/mnt/1T-HDD/BSP/r35.4.1/Linux_for_Tegra/rootfs/lib/modules/5.10.120-tegra$ sudo find ./ -iname qspi_mtd.ko
./kernel/drivers/mtd/devices/qspi_mtd.ko
davey@dave-yu-nvidia-pc:/mnt/1T-HDD/BSP/r35.4.1/Linux_for_Tegra/rootfs/lib/modules/5.10.120-tegra$ sudo find ./ -iname spi-tegra210-qspi.ko
./kernel/drivers/spi/spi-tegra210-qspi.ko
davey@dave-yu-nvidia-pc:/mnt/1T-HDD/BSP/r35.4.1/Linux_for_Tegra/rootfs/lib/modules/5.10.120-tegra$ sudo find ./ -iname pwm-fan.ko
./kernel/drivers/hwmon/pwm-fan.ko

I’m taking 35.4.1 for example, but it should be the same for 35.3.1.

[koichi.tanoiri]

Hi,
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.

[koichi.tanoiri]

@DaveYYY

sudo find ./ -iname qspi_mtd.ko
./kernel/drivers/mtd/devices/qspi_mtd.ko

Hi,

**@**:~/git/Orin_flash/rootfs/lib/modules/5.10.104-tegra$ sudo find ./ -iname qspi_mtd.ko
./kernel/drivers/mtd/devices/qspi_mtd.ko
**@**:~/git/Orin_flash/rootfs/lib/modules/5.10.104-tegra$ sudo find ./ -iname spi-tegra210-qspi.ko
./kernel/drivers/spi/spi-tegra210-qspi.ko
**@**:~/git/Orin_flash/rootfs/lib/modules/5.10.104-tegra$ sudo find ./ -iname pwm-fan.ko
./kernel/drivers/hwmon/pwm-fan.ko

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?

Thank you.

[DaveYYY]

Can you please show me contents of ~/git/Orin_flash/rootfs/lib/modules/5.10.104-tegra?

[koichi.tanoiri]

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)

Is there any other information you might need?

Thank you for your assistance.

[DaveYYY]

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.

davey@dave-yu-nvidia-pc:/mnt/1T-HDD/BSP/r35.4.1/Linux_for_Tegra/rootfs/lib/modules/5.10.120-tegra$ ll
total 2040
drwxr-xr-x 4 root root   4096  9月  7 10:12 ./
drwxr-xr-x 3 root root   4096  9月  7 10:12 ../
lrwxrwxrwx 1 root root     69  8月  2 03:49 build -> /usr/src/linux-headers-5.10.120-tegra-ubuntu20.04_aarch64/kernel-5.10
drwxr-xr-x 3 root root   4096  9月  7 10:12 extra/
drwxr-xr-x 9 root root   4096  9月  7 10:12 kernel/
-rw-r--r-- 1 root root 516776  9月  7 10:12 modules.alias
-rw-r--r-- 1 root root 507579  9月  7 10:12 modules.alias.bin
-rw-r--r-- 1 root root  27919  8月  2 03:49 modules.builtin
-rw-r--r-- 1 root root  50822  9月  7 10:12 modules.builtin.alias.bin
-rw-r--r-- 1 root root  30536  9月  7 10:12 modules.builtin.bin
-rw-r--r-- 1 root root 156183  8月  2 03:49 modules.builtin.modinfo
-rw-r--r-- 1 root root  88788  9月  7 10:12 modules.dep
-rw-r--r-- 1 root root 139645  9月  7 10:12 modules.dep.bin
-rw-r--r-- 1 root root    187  9月  7 10:12 modules.devname
-rw-r--r-- 1 root root  46165  8月  2 03:49 modules.order
-rw-r--r-- 1 root root    802  9月  7 10:12 modules.softdep
-rw-r--r-- 1 root root 210721  9月  7 10:12 modules.symbols
-rw-r--r-- 1 root root 261920  9月  7 10:12 modules.symbols.bin

[koichi.tanoiri]

I see. Thank you for your response. Indeed, as you pointed out, it seems like there is a lack of information such as aliases, which appears to be the cause.

**@**:~/git/Orin_flash/rootfs/lib/modules/5.10.104-tegra$ ll
合計 244
drwxr-xr-x 3 root root   4096 11月 14 17:27 ./
drwxr-xr-x 3 root root   4096 11月 14 17:24 ../
lrwxrwxrwx 1 root root     18 11月 14 17:27 build -> /work/kernel/build
drwxr-xr-x 9 root root   4096 11月 14 17:27 kernel/
-rw-r--r-- 1 root root  28341 11月 14 17:27 modules.builtin
-rw-r--r-- 1 root root 158504 11月 14 17:24 modules.builtin.modinfo
-rw-r--r-- 1 root root  45495 11月 14 17:27 modules.order
lrwxrwxrwx 1 root root     31 11月 14 17:27 source -> /work/kernel/kernel/kernel-5.10

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?

Thank you for your assistance.

[DaveYYY]

@koichi.tanoiri

I see. Thank you for your response. Indeed, as you pointed out, it seems like there is a lack of information such as aliases, which appears to be the cause.

Glad to hear that.
Then is the modprobe error fixed now?

@koichi.tanoiri

Is this information also generated during the process of apply_binaries.sh, apart from the kernel artifacts?

I’m not sure what you mean with it.
Can you please explain it more? What do you mean with kernel artifacts?

[koichi.tanoiri]

@DaveYYY

Then is the modprobe error fixed now?

Yes, thanks to your advice, the issue with modprobe has been resolved, and I have confirmed that the initrd flash is successful. Thank you.

@DaveYYY

I’m not sure what you mean with it.
Can you please explain it more? What do you mean with kernel artifacts?

I apologize for any confusion. When I mentioned kernel artifacts while discussing apply_binaries, I was referring to the contents placed in the kernel folder, which are as follows:

• Image
• data.tar.gz
• index.html
• kernel_headers.tbz2
• kernel_supplements.tbz2
• nvidia-l4t-kernel-hogehoge_arm64.deb

[DaveYYY]

@koichi.tanoiri

• Image
• data.tar.gz
• index.html
• kernel_headers.tbz2
• kernel_supplements.tbz2
• nvidia-l4t-kernel-hogehoge_arm64.deb

So you mean if you take out these files, will those modules info files still be populated with apply_binaries.sh?
Then the answer is NO, as they are extracted from kernel_supplements.tbz2.

[koichi.tanoiri]

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.

Thank you for your prompt reply.