https://forums.developer.nvidia.com/t/linking-externel-driver/249798/11
i have mentioned my doubt in this topic, unfortunately i couldn’t continue it. but still i m stuck in including external module. can you please tell me is there any different procedure for including out tree module. in that link lastly @JerryChang asked to load device tree binary via kernel-dtb. but the dtbo file whatever i m getting has imx219 device tree not our module device tree so need help to sort out this issue
I have gone through that link. I have got few doubts after reading that forum
- what does the third-party carrier board require’s?
- In the kernel message log, we could see the imx219 board things. Though we have followed the procedure we have mentioned in the above link, still our external module is not getting loaded.
So could you please suggest to us if are doing anything wrong or if we are missing out anything.
Third party carrier boards are sometimes an exact electrical layout match to the dev kit. In that case they can use the dev kit software. Most third party carrier boards differ in electrical layout, e.g., they might swap two pins in order to ease physical layout of traces. In those cases they need a new device tree. That tree might be in the form of a patch to the dev kit software. Alternatively, a lot of manufacturers will repackage the flash software and you download that (the entire flash setup) directly from them.
Most computers (both embedded and desktop) have drivers for a lot of hardware they don’t have. Chances are your desktop Linux PC has a 10 Gb NIC driver that it doesn’t have, or perhaps a driver for the XFS or ReiserFS filesystems, and you don’t have those. The imx219 sensor happens to be a driver for hardware you don’t have unless you use that exact image sensor. You see a note about the sensor because it is not “plug-n-play”, and there is no way to tell it isn’t there unless you edit the device tree.
Plug-n-play tends to mean the device can be queried to ask the device some basic information about itself, and the device responds. That information can be relayed to a “hot plug” layer, and that layer can announce capabilities to various drivers, and a driver can take ownership. This includes PCI and USB.
Other non-plug-n-play hardware is accessed at some specific physical address. Drivers have no way to know what address. Some other information is needed for non-plug-n-play hardware, e.g., the name of the driver to use. Sometimes other information. All of that has to be told to the driver, and there is no way to detect if the hardware is there other than the driver attempting to load with that information. If it works, great; if not, then a log message is generated. You don’t have an imx219 by default, so unless you added this, you will see a log message. This is the result of including a driver which a lot of people will use, but not everyone uses, when it is custom and not plug-n-play. It isn’t an error, it is in fact the software working correctly and saying non-existent hardware does not exist (or else it exists and has failed).
Also, many drivers are not in the form of a module. If you want to see a list of drivers, run this command:
zcat /proc/config.gz
The ones which are a module format have “=m”:
zcat /proc/config.gz | grep '=m'
Compare that to the number which are integrated non-modular drivers, and have “=y”:
zcat /proc/config.gz | grep '=y'
You don’t load a module unless the hardware exists and has the right arguments passed to it, e.g., the physical address of the hardware. If you did not add an imx219 sensor, then it is not possible to load the module. That’s a good thing since (A) it would be a waste of resources, and (B) the physical RAM address range for modules is limited by the direct branch assembler instruction for the CPU (on amd64/x86_64 that’s pretty large; on 32-bit ARM its terribly small, and on 64-bit ARM it isn’t huge, but it is a lot larger than the 32-bit ARM direct branch instruction). Also, some firmware shares that direct branch instruction range, so not all of it is allowed for modules; modules have resource competition.
The bottom line: Do you have an imx219 sensor? If you do, and the module cannot load, then it is because the driver does not have the correct information, e.g., physical address, but also the lane routing on which pins (they are flexible) are used. Only the manufacturer of the carrier board would know what device tree edits to make because they are the only ones with information on trace layout and how the CSI (or any non-plug-n-play device) is routed.
Hello,
We have made the custom career board with 4 lane CSI i.e., CSI0 and CSI1, have been used for 4 lane, as recommended by camera OEM and as per nvidia datasheet which is highlighted in the below picture. The OEM has given driver file suitable for Jetson platform and OEM claims that it works for them.
We have also followed the below steps recommended by OEM, by modifying the dtsi file which is enclosed herewith.
STEPS :-
1. I have made toolchain setup and extracted source codes.
2. Placed .c file and edited Makefile and Kconfig under path /nx/source/Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/i2c/
3. Then i wanted to disable the default imx219 camera driver. To disable imx219, i commented out the include “tegra194-camera-jakku-rbpcv2-imx219.dtsi” line in “tegra194-p3509-0000-a00.dtsi” file
4. And added my camera dtsi file under the path /nx/Linux_for_Tegra/source/public/hardware/nvidia/platform/t19x/jakku/kernal-dts/common/ and included my dtsi in “tegra194-p3668-common.dtsi” file.
Inspite of following the above steps, we are getting IMX219 properties in device tree, instead of OEM camera. Could you help to resolve the issue.
5. We are using L4T version of 32.5.0(Jetpack version of 4.5).
Best Regards,
Kamalesh
I’m not much use when talking about camera device tree edits, but when you compiled, did you compile the module as “=m”? If so, it is easy to just copy it to the Jetson as a normal file copy (you can do as you were mentioning and it is part of a flash after that). If the feature is added by “=y”, then it gets much more complicated to install (in theory it is not so complicated, but mistakes will make it unbootable). What was your “CONFIG_LOCALVERSION” set to during the kernel build?
Also note that if you add device tree components to the kernel source, then you have to still configure correctly, and propagate that configuration. Then you have to build the “dtbs” target.
For the .dtsi you built, if you know which dtb is being produced, you could manually add this as a file copy and adjusting the “/boot/extlinux/extlinux.conf” to use this (I’d add a second entry to leave the original alone, and add any new modules or kernel as needed, especially if there is a new kernel Image).
Hello
The CONFIG_LOCALVERSION=-tegra is used. we have tried both the ways by giving “=m” and “=y” even. but no use.
Are you using a configuration editor to change the “=y” to “=m”? Or are you editing the config file directly? Configuration editors understand dependencies, and I’m wondering if the configuration is valid.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.