Hello everyone,
I followed the Kernel customization guide to build a custom kernel with GadgetFS enabled in Menuconfig. Although I successfully built the kernel, I noticed that the changes I made are not reflected in the .config files. Below are the build logs:
Could anyone suggest how to enable GadgetFS properly or what steps to take after enabling it in Menuconfig? Thank you!
Hi,
Do you use Orin Nano or Jetson Nano? The topic is created in Jetson Nano category.
sorry my bad its for orin nano
Hi,
Please try this:
Building the kernel from kernel source jetpack 6 , jetson orin nx 16GB - #5 by DaneLLL
The default path needs root permission, so yo may not build it with correct toolchain. May try to create another non-root-permission path to build it, and then copy to Linux_for_Tegra folder. And please build nvidia-oot along with upstream kernel.
Hello, thanks for the reply!
I’m fairly new to this, so I hope I don’t say anything wrong. Are you suggesting that I should extract the BSP source code to a directory where I don’t need root permissions? Or do I need to move my cross-compiler, which I currently have located at:
/home/sreeja/l4t-gcc/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-
to a non-root directory instead?
Hi,
Please extract the source code to non-root directory.
Hello @DaneLLL
I have attempted the first procedure you suggested, running it with sudo, but unfortunately, it did not resolve the issue, as I am still seeing the default settings in the configuration file. I will now try your other suggestion of placing the build in a non-root directory and building it there.
In the meantime, I have a few questions:
After building the kernel with custom menuconfig settings, is it necessary to flash the entire system, or is there an alternative way to avoid reflashing? In the future, if we need to enable additional options in menuconfig, reflashing might become a cumbersome process, especially considering the built environment would already be configured.
If reflashing is the only option, are there any additional steps beyond what’s mentioned in the documentation that we should be aware of when building and flashing the kernel?
I believe these questions would be helpful for beginners like myself.
Hi,
It is supposed to take effect by overwriting kernel image. Since you mention it doesn’t take effect, we suggest re-flash the whole system for a try.
There are some kernel-customization use-cases in
You may try these as validation. The steps in developer guide is well tested. It should work fine if you follow the instructions one by one.
Hello! As you suggested, I extracted the source code in the Downloads directory, specifically in the kernel_src folder, using the command:
tar xf kernel_src.tbz2
After that, I navigated to the source directory and ran:
./generic_rt_build.sh "enable"
Next, I entered the kernel_jammy_source directory and executed the make menuconfig command. I enabled gadgetfs as built-in and saved it to the .config file. Then, I returned to the source directory and set the CROSS_COMPILE environment variable as follows:
export CROSS_COMPILE=~/l4t-gcc/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-
Following that, I ran:
make -C kernel
However, after building the kernel, I checked the .config file again and found that GADGETFS is not set.
below is .config before building
Hi,
Please modify defconfig to enable the kernel configs.
Hi,
As you suggested, I navigated to the ‘kernel_jammy_source’ directory and ran the ‘make defconfig’ command. After that, I enabled ‘gadgetfs’ in the ‘menuconfig’ and saved the changes to the ‘.config’ file.
Next, I executed the ‘savedefconfig’ command. I then built the kernel using the command: ‘make -j$(nproc)’.
After building, I replaced the kernel image in the ‘boot’ directory of the Orin Nano. However, upon rebooting the device, it did not reflect the updated configurations
Hello @DaneLLL
we have tried another approach as stated in this Topic have implemented all commnads except we put
LOCALVERSION=-tegra
when we tried to flash using below command
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
-c tools/kernel_flash/flash_l4t_t234_nvme.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
--showlogs --network usb0 jetson-orin-nano-devkit internal
we are getting stucked at below point
as suggested in terminal we retrived Serial logs
seriallogs.txt (134.4 KB)
Hi,
Probably the config is deprecated in K5.15. Are you able to enable other configs for a try?
Hi,
I just wanted to confirm my understanding. Are you saying that the GadgetFS config could have been deprecated in K5.15? and if that is the case why is the option available in the menuconfig?
Hi,
Yes, we suspect the config may b deprecated. Other customizations in the elinux page work by following the developer guide. A bit strange this config does not work as expected.
Hi,
After booting the kernel image with default configuration, we enabled gadgetfs and rebuilt the kernel. The device booted up with new custom kernel image and gadgetfs has been installed as a module and then loaded it to the kernel using modprobe, As you can see in the images below. however we were unable to mount it. could you please suggest me how to mount gadgetfs?
I am using jetson orin nano(jetpack 6)
Hello, we were able to solve the problem using a native method and by disabling configfs. However, I still don’t understand why the flashing method isn’t working. No matter what we try, it keeps showing “waiting for bootup!”
I think you missed a step when updating the defconfig. After you have made changes to the .config file (e.g. through menuconfig etc.) you should do this:
make ARCH=arm64 savedefconfig
cp defconfig arch/arm64/configs/defconfig
Then when you run the kernel build and install scripts it will configure the kernel using your updated configuration. Once you have have built and installed the kernel, make sure you update the initrd image as well.
Hello bgriffis,
Thank you for your guidance. I followed your steps, but unfortunately, I’m still encountering the same boot issue. Here’s a detailed breakdown of what I did:
Downloaded and Set Up BSP, Rootfs, and Source Code:
Extracted Source Code and Kernel Customization:
apply_binaries.sh.public_sources.tbz2 within the Linux_for_Tegra directory, as per the Kernel Customization Guide.cd WORKSPACE/
tar xvf Jetson_Linux_R36.3.0_aarch64.tbz2
sudo tar xvpf Tegra_Linux_Sample-Root-Filesystem_R36.3.0_aarch64.tbz2 -C Linux_for_Tegra/rootfs/
cd Linux_for_Tegra/
sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh
cd ..
tar xvf public_sources.tbz2 -C Linux_for_Tegra/..
cd Linux_for_Tegra/source
tar xvf kernel_src.tbz2
tar xvf nvidia_kernel_display_driver_source.tbz2
tar xvf kernel_oot_modules_src.tbz2
Kernel Configuration:
kernel/kernel-jammy-src/.make ARCH=arm64 defconfig
make ARCH=arm64 menuconfig # Disabled configfs, enabled gadgetfs
make ARCH=arm64 savedefconfig
cp defconfig arch/arm64/configs/defconfig
Cross Compilation Setup and Kernel Build:
export CROSS_COMPILE=~/Downloads/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-
make -C kernel
Module Installation and Image Copy:
INSTALL_MOD_PATH and ran installation commands, then copied the kernel image:export INSTALL_MOD_PATH=~/Downloads/Linux_for_Tegra/rootfs
sudo -E make install -C kernel
sudo cp arch/arm64/boot/Image ~/WORKSPACE/Linux_for_Tegra/kernel/Image
Building OOT Modules:
KERNEL_HEADERS variable and built out-of-tree modules:export KERNEL_HEADERS=$PWD/kernel/kernel-jammy-src
make modules
sudo -E make modules_install
```sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \ -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \--showlogs --network usb0 jetson-orin-nano-devkit internal
Despite following these steps, the boot issue persists. Any further insights on what might be causing the boot hang would be greatly appreciated.
Thank you again for your assistance.
Best regards,
Kondru Abhay
You missed a crucial step. You need to regenerate the initrd image.
sudo ./tools/l4t_update_initrd.sh
If you have enabled any new modules that are needed prior to mounting the complete rootfs, then you will need to add those modules to the initrd by adding a line in rootfs/etc/nv-update-initrd/modules prior to running the update script.