ls: cannot access ‘/home/trident/Downloads/r35_4_1/Linux_for_Tegra/rootfs’: No such file or directory
Note: This is by working directory where I modify my device tree files and build it. Later will be copying the DTBS and Image file to another directory path [/home/trident/Downloads/r35_4_1/Jetson_Linux_R35.4.1_aarch64/Linux_for_Tegra] - from where I will be executing my flash command.
I think the BSP path you were asking is this path" /home/trident/Downloads/r35_4_1/Jetson_Linux_R35.4.1_aarch64/Linux_for_Tegra" as here I can see the roofs directory.
below is the output for the ls -l command for this rootfs directory.
But I have one more query regarding defconfig file update.
I am getting some loader/ unreferenced declaration error during kernel build in my xx_soc_machine_driver.c file, if i enable some driver like mttcan=y from mttcan=m inside the defconfig.
Any idea what does =m refer here? does it mean it will be loaded at runtime automatically? Thanks.
If you configure the kernel config to y, this module will be built in kernel image and loaded automatically during boot up.
If you configure the kernel config to m, this module will be built as a loadable module and you need to load it manually after boot up. (through modprobe or insmod command)
But when I enable, Codec drivers or CAN driver as y in defconfig it is giving build error during compilation in xx_machine_driver.c file.
Any reason. It works fine when I make it as m.
Heard they are upstream drivers and we should make it m always.
But for my case I need to enable these driver as part of my kernel image always by default as I don’t want to manually load them using command later on my target machine.
Thanks for the info. Also just want to know that all my folders present under ‘<Linux_for_Tegra>/rootfs’ like etc, usr, bin, var, etc will be copied as it is to my target board., so that what ever i update inside my rc.local file ‘<Linux_for_Tegra>/rootfs/etc/rc.local’ will go and sit on my target board as it is.
please confirm. Thanks.
Yes, the content under <Linux_for_Tegra>/rootfs will be built to system.img and flash into your board during flashing process.
So, your modification/files under this folder will be present on your target board after flash.
What I meant was , CAN was configured to GPIO pins GPIO-305 ( PAA-00) … to GPIO-308 ( PAA-03) ( through PIN mUX sheet or manually writing the values to the registers using some devmem command ) but it is not getting updated as GPIO–> CAN when we give this command.
Any idea?
It depends on the driver.
You could just find any pin which is reflected in sysfs node and trace the driver.
There should be the function used to request this GPIO.
There should be many examples in google search and also in the kernel source…
You should always check the device tree or even the source for the pin used by the node.
You could not just check /sys/debug/kernel/gpio and know which pin has been used because many pins have been used but not through gpio request function.
Yes, it is expected result because these pins are not requested by the driver.
How exactly to trace the driver in this case for CAN configured from GPIO pins?
where to find this function?
Also through PIN MIX sheet method where we are configuring GPIO pins as CAN, are we not really changing the GPIO pins at kernel driver level? and wont it reflect in the sysfs node?
but internally would these GPIO pin are configured as CAN right, as my CAN controllers are UP now, so this GPIO configured is CAN should have taken effect, even though it is not showing in sysfs.
pls clarify.
