Hi
I know extlinux.conf file can be modified after boot up.
but I want to do in source file - drivers/bsp/Linux_for_Tegra/
After flashing, I want extlinux.conf options work at the first booting.
Thank you
*** Please note that this reply is generated by LLM automatically ***
The extlinux.conf file is a configuration file used by the extlinux bootloader, which is used on the Jetson Orin Nano platform. This file contains settings that control the boot process, such as the kernel image and device tree binary (DTB) to use.
By default, the extlinux.conf file is generated during the flashing process and is stored on the device’s boot partition. However, as you’ve discovered, modifying this file after booting up does not persist across reboots.
To modify the extlinux.conf file in the source file, you’ll need to modify the drivers/bsp/Linux_for_Tegra directory, which contains the source code for the Linux kernel and bootloader configuration.
Specifically, you’ll want to modify the extlinux.conf file in the drivers/bsp/Linux_for_Tegra/bootloader directory. This file contains the default settings for the extlinux bootloader.
After modifying the extlinux.conf file, you’ll need to reflash the device using the flash.sh script. This will update the bootloader configuration on the device.
As you’ve noted, the changes to the extlinux.conf file will take effect on the first boot after flashing. This is because the bootloader configuration is stored in the device’s boot partition, which is updated during the flashing process.
It’s worth noting that modifying the extlinux.conf file in the source file is a more permanent solution than modifying it after booting up. However, it does require reflashing the device, which can be a more involved process.
In comparison, modifying the extlinux.conf file after booting up is a more temporary solution, as the changes will not persist across reboots. However, it can be a useful way to test changes to the bootloader configuration without having to reflash the device.
In summary, to modify the extlinux.conf file in the source file, you’ll need to modify the drivers/bsp/Linux_for_Tegra/bootloader directory and then reflash the device using the flash.sh script. This will update the bootloader configuration on the device and ensure that the changes persist across reboots.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Hi
you.mentioned " In summary, to modify the extlinux.conf file in the source file, you’ll need to modify the drivers/bsp/Linux_for_Tegra/bootloader directory"
In that directory, which file should I do it?
Thank you
Not a full answer, but some starting information…
Most of what you see in the host PC’s “Linux_for_Tegra/rootfs/” is copied exactly when creating the boot image. The parts which change are due to arguments passed to the flash software. One argument is the specific flash target, and another is the destination, e.g., to the eMMC if that exists, or to the QSPI if no eMMC for non-rootfs content.
In the “Linux_for_Tegra/” directory of the host PC, run this command:
ls -l jetson*.conf
Every one of those files, if you remove the “.conf” of the file name, are flash targets. The flash.sh script is what actually flashes, at least on command line, and there used to not be any kind of GUI front end to flash. Some contrived examples of command line flash would be something like these if not using the GUI and not performing any special boot case (e.g., not to NVMe):
sudo ./flash.sh jetson-nano-devkit mmcblk1p1(SD card)sudo ./flash.sh jetson-nano-emmc mmcblk0p1(commercial module eMMC)
Each of the “jetson-*.conf” files are symbolic links. They point to files with names such as these (just illustrating, the particular file is unimportant):
p3449-0000+p3448-0002.confp3449-0000+p3448-0000-qspi.conf
Those “real” file names are a technical number for the module type along with the carrier board, and possibly revision or some other detail. Those “real” files include other files. If you were to combine a different carrier board with a particular module, then half of the file name would still name the module, and the “include” content would combine module specs with the new carrier board specs. These are all plain text and are human readable, so you might look around at them.
Probably the best way to see what is going on is to perform a command line flash and to save the log. This will tell you about ever file which is copied into “Linux_for_Tegra/rootfs/boot/”, including kernel, device tree, and extlinux.conf. If you have your Jetson in recovery mode, and you run a command such as this, then it will log the flash and you can examine the log to see where it comes from (I’m making up the flash target; adjust for your specific Jetson model):
sudo ./flash.sh jetson-orin-nano-devkit mmcblk1p1 2>&1 | tee log_flash.txt
Note that the actual flash command above is:
sudo ./flash.sh jetson-orin-nano-devkit mmcblk1p1
The suffix " 2>&1 tee log_flash.txt" just creates a log file. The mmcblk1p1 is just what a Nano would use if it is a dev kit for the partition being flashed (an SD card). If it were eMMC, then instead of mmcblk1p1 it would be mmcblk0p1. If you go to an external boot device instead of the built in SD card or eMMC, then you have to use different flash commands.
The actual docs for your L4T release tell you how to modify kernel and other content for flashing, but it can be a long read. Your L4T release is from the “/etc/nv_tegra_release” file, and you can look up docs and software specific to that release here:
https://developer.nvidia.com/linux-tegra