Hi Team,
we have customized jetpack6 kernel using make menuconfig for gatgetfs and could build it. After loading the kernel it was booting, but could not mount the gadgetfs.
Please share the directions to select the correct settings in the menuconfig and rebuild the kernel that could mount gadgetfs.
Thanks,
Satya.
You should always start with the configuration of the original running kernel, e.g., install that again (better yet, just leave old and new kernels both in place with different boot entries; set the default to the original first, and when alt new kernel works, make that one the default). Then use a context-aware editor, e.g., nconfig or menuconfig, to perform any edits. If you change only modules, then keep the original “CONFIG_LOCALVERSION” (see the suffix of “uname -r”; usually it is “-tegra”, which is what the default CONFIG_LOCALVERSION is). Keeping “CONFIG_LOCALVERSION”, and also keeping the original kernel source, but changing only modules, will imply you can deal with only installing new modules, and skipping any kernel main Image change.
The Gadget API has several kinds of gadgets it can work with. Are you speaking of the network gadget? The mass storage gadget? Emulating an input device gadget? You should be specific.
Also, each type of gadget may have other requirements. As an example, you should never remove loopback capability, it is used in too many ways that you probably won’t see, but mounting a file as a mass storage gadget would fail if loopback is missing (and it would have nothing to do with the gadget API).
We have kept both the original kernel (as Image) and also the customized kernel (as Image.backup) during the boot and upon choosing the option - 0 for the Customized kernel and Option -1 for original kernel to boot and could land in the Desktop UI for both the cases.
Gadget for us basically for mounting an input device gadget.
Settings used are : device drivers->usb support->gadget support->gadgetfs.
We have also included the loopback as well.
Please let me know if any more information is needed to debug the issue and help us enable the gadgetfs from the Kernel and also wanted to mount the gadgetfs over the /dev/gadget in our use case.
Thanks,
Satya.
Is the output of “uname -r” different when running the original kernel versus the new kernel? If you modified the kernel Image itself, then you want them to differ. The two would use different modules, so you would have two module directories:
/lib/modules/$(uname -r)/kernel/
Keep in mind that sometimes a driver might have other requirements. As an example, if you somehow lost loopback, then I doubt gadgetfs would work, although it might in some circumstances. A rather important question: Did you disable anything in the kernel versus the stock/original kernel? It isn’t just loopback, that’s just an example. Also, what filesystem type is the underlying file or partition?
Hi,
I see 2 different kernels in the path ‘/lib/modules/’; 5.15.136-tegra is default kernel and customized would be 5.15.136-demo.
we are currently booting from 5.15.136-demo.
In addition, we have not disabled any kernel setting related to any other feature. Only enabled the setting: device drivers->usb support->gadget support->gadgetfs; including the loopback option and gadget FileSystem.
After booting with the customized kernel, ‘lsmod’ does not show the gadgetfs loaded. Also mount gatgetfs command fails - unknown filesystem ‘gadgefs’.
Could you please put some light on this info and let me know if any other details required.
Also please guide us to fix the issue.
Thanks.
The original Image will work with modules in “/lib/modules/5.15.136-tegra/”. The new Image will only work with modules in “/lib/modules/5.15.136-demo/”. If you’ve overwritten one of the Image files (rather than using file renaming and/or different entries in extlinux.conf), then it means you’ve lost all ability to load modules from that other /lib/modules/ path. One kernel Image is hard wired to look in the -tegra location, the other kernel Image is hard wired to look in the -demo location.
If the original kernel Image (which I might refer to as Image-tegra even if that isn’t the file name) had a configuration which Image-demo (again, the file name might be this, but I’ll refer to the newer Image like this…I do often actually name my Image files like this to avoid overwriting the wrong one and have them all available as different boot entries in extlinux.conf), then other than the CONFIG_LOCALVERSION, these two kernels would be the same (they’d use different module directories). It is important to know that because you have two different module locations that you must build 100% of the modules and install all modules to the -demo location for the Image-demo. Changing CONFIG_LOCALVERSION makes this a new Image and tends to invalidate old modules (depending on case; never bet on a module being compatible after changing CONFIG_LOCALVERSION or an =y integrated feature).
If you then added module features to Image-demo before building, then other than the module directory, this would be the same Image…in which case you wouldn’t want to change CONFIG_LOCALVERSION (you could just copy the new module to the -tegra location in that case, so it is extra work to change CONFIG_LOCALVERSION in order to add a single module).
Questions:
-demo location?-tegra configuration, followed by only adding a module and changing CONFIG_LOCALVERSION to -demo?/mnt”, if it isn’t already mounted. Gadget is only half of this…the kernel must also know how to read the format of the device storage being exported through gadget.