CAN0, CAN1 not working even after enabling in PIN MUX spreadsheet

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.

total 104
lrwxrwxrwx 1 root root 7 Jul 31 2020 bin → usr/bin
drwxr-xr-x 3 root root 32768 Nov 10 12:20 boot
drwxr-xr-x 2 root root 4096 Sep 27 12:43 dev
drwxr-xr-x 140 root root 12288 Nov 17 09:54 etc
drwxr-xr-x 2 root root 4096 Apr 15 2020 home
lrwxrwxrwx 1 root root 7 Jul 31 2020 lib → usr/lib
drwxr-xr-x 2 root root 4096 May 19 2021 media
drwxr-xr-x 2 root root 4096 Jul 31 2020 mnt
drwxr-xr-x 4 root root 4096 Sep 22 10:40 opt
drwxr-xr-x 2 root root 4096 Apr 15 2020 proc
-rw-rw-rw- 1 trident trident 62 Aug 2 01:19 README.txt
drwx------ 3 root root 4096 Sep 20 2022 root
drwxr-xr-x 18 root root 4096 Jul 7 2021 run
lrwxrwxrwx 1 root root 8 Jul 31 2020 sbin → usr/sbin
drwxr-xr-x 2 root root 4096 Feb 2 2021 snap
drwxr-xr-x 2 root root 4096 Jul 31 2020 srv
drwxr-xr-x 2 root root 4096 Apr 15 2020 sys
drwxrwxrwt 2 root root 4096 Sep 22 13:14 tmp
drwxr-xr-x 11 root root 4096 Mar 4 2021 usr
drwxr-xr-x 15 root root 4096 Sep 22 10:40 var

It seems you didn’t extract sample fs in this BSP package.
Please refer to $ sudo tar xpf ${SAMPLE_FS_PACKAGE} -C Linux_for_Tegra/rootfs/ in Quick Start — Jetson Linux Developer Guide documentation (

Please run the following command on your host.

$ cd /home/trident/Downloads/r35_4_1/Jetson_Linux_R35.4.1_aarch64/Linux_for_Tegra/rootfs
$ sudo find -name "mttcan.ko"
1 Like

we extracted the same and using it. Thanks.

I was able to find mttcan.ko in this path.

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.

Just as your another topic, you could set them as m and enable them in DT.
Or you could add them in /etc/modules-load.d/modules.conf

1 Like

Thanks for the info.

I got this link, where it explains about enabling CAN through a script method which should be created in the root directory.

my question is here the root directory on the HOST PC is “/” or the my BSP folder directory under rootfs directory.


Please clarify, where should we create the .sh script

It should always mean <Linux_for_Tegra>/rootfs because it is the BSP source for your Jetson device. Please just create the script inside.

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.

1 Like

Thanks for the confirmation.

This worked and CAN0, CAN1 controllers are ip with we give ‘ifconfig’ command on the target.

But our requirement is these CAN pins should be mapped to GPIO pins and should displayed when we give the command:

$ /sys/debug/kernel/gpio
but this is not happening and it still shows GPIO pins only.

What do you mean here?
What’s your use case for the display in /sys/debug/kernel/gpio?

If the pin not be requested GPIO from driver, it wouldn’t reflect in this sysfs node.

what should be done to make it reflect in sysfs node.
where I can see the list of GPIO pins which are mapped/configured to other usages.

How to request GPIO pin configuring from driver ? Please explain elobarately

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.

For CAN driver, please check m_ttcan_linux.c.

Please find other pin which is showed in sysfs node with the gpio request function.

Have you tried to trace the code and find the gpio function…?

Please check if every pin used in device tree would reflect in the sysfs node. and you would find the answer is: NO.