The drivers of its own chips?
How to code and load the drivers of its own chips? Which directory we should put the drivers so them could be loaded automatically upon start up?
How to code and load the drivers of its own chips? Which directory we should put the drivers so them could be loaded automatically upon start up?

#1
Posted 04/16/2018 02:43 AM   
U-Boot has its own drivers and must be compiled directly into U-Boot. When Linux loads it uses the drivers which are integrated into the kernel Image (named in "/proc/extlinux/extlinux.conf", the default is "/boot/Image"). After Linux loads it is capable of loading drivers in the module directory. The distinction is that if the module is needed to do initial work it must be integrated within the Image...if not it can often be built as a module. Note that not all features can be modular and that there may be some inefficiency if too much is a module. When building a kernel it has a base version number, e.g., "4.4.38". The configuration (hopefully you've set CONFIG_LOCALVERSION) is appended to this to create the output you would see at runtime from the command "uname -r". Modules are searched for at: [code]/lib/modules/$(uname -r)/[/code] If you compile from the source_sync.sh downloaded kernel source (recommended...this is a file from the driver package), then it will append a "+" on the end of this. Example "uname -r" where base source is version 4.4.38 and CONFIG_LOCALVERSION is set to "-custom": [code]# Not from source_sync.sh: 4.4.38-custom # If compiled from source_sync.sh downloaded source: 4.4.38-custom[b]+[/b][/code] If you copy your running Jetson's "/proc/config.gz" somewhere and "gunzip config.gz" to decompress it then you can see the options used at the time this running kernel was built. Options with "=y" were integrated. Options which show as "=m" are options which were built as a module and can be seen somewhere under "/lib/modules/$(uname -r)/".
U-Boot has its own drivers and must be compiled directly into U-Boot.

When Linux loads it uses the drivers which are integrated into the kernel Image (named in "/proc/extlinux/extlinux.conf", the default is "/boot/Image").

After Linux loads it is capable of loading drivers in the module directory. The distinction is that if the module is needed to do initial work it must be integrated within the Image...if not it can often be built as a module. Note that not all features can be modular and that there may be some inefficiency if too much is a module.

When building a kernel it has a base version number, e.g., "4.4.38". The configuration (hopefully you've set CONFIG_LOCALVERSION) is appended to this to create the output you would see at runtime from the command "uname -r". Modules are searched for at:
/lib/modules/$(uname -r)/


If you compile from the source_sync.sh downloaded kernel source (recommended...this is a file from the driver package), then it will append a "+" on the end of this. Example "uname -r" where base source is version 4.4.38 and CONFIG_LOCALVERSION is set to "-custom":
# Not from source_sync.sh:
4.4.38-custom
# If compiled from source_sync.sh downloaded source:
4.4.38-custom+


If you copy your running Jetson's "/proc/config.gz" somewhere and "gunzip config.gz" to decompress it then you can see the options used at the time this running kernel was built. Options with "=y" were integrated. Options which show as "=m" are options which were built as a module and can be seen somewhere under "/lib/modules/$(uname -r)/".

#2
Posted 04/16/2018 03:08 AM   
sirius850120, I don't think there would be a folder that would do this automatically. You need to use "insmod" or "modprobe" to load your kernel loadable module or just build it into kernel image.
sirius850120,

I don't think there would be a folder that would do this automatically. You need to use "insmod" or "modprobe" to load your kernel loadable module or just build it into kernel image.

#3
Posted 04/16/2018 03:18 AM   
That's something I forgot..."sudo depmod -a" would update the kernel's information on modules which are there for use in automated loading. "sudo modprobe <modulename> [optional,module,parameters]" would look at dependencies while inserting a module (which in turn would use information from the previous depmod). "sudo insmod <modulename> [optional,module,parameters]" would blinding insert the module without requiring any "depmod" style information. If you've added a module and run the "sudo depmod -a", then each reboot should automatically make the module available on demand (it might not be loaded if it wasn't used...insmod will force load even if not used).
That's something I forgot..."sudo depmod -a" would update the kernel's information on modules which are there for use in automated loading.

"sudo modprobe <modulename> [optional,module,parameters]" would look at dependencies while inserting a module (which in turn would use information from the previous depmod).

"sudo insmod <modulename> [optional,module,parameters]" would blinding insert the module without requiring any "depmod" style information.

If you've added a module and run the "sudo depmod -a", then each reboot should automatically make the module available on demand (it might not be loaded if it wasn't used...insmod will force load even if not used).

#4
Posted 04/16/2018 03:52 PM   
Scroll To Top

Add Reply