For the moment, ignore the Stereolabs install method. Stick to the Seeed method. If Seeed does not use a modified device tree, then it should be equivalent to the NVIDIA installer method. If Seeed does use a modified device tree, then the Seeed method would give you the device tree you needed and the NVIDIA installer would be missing some subset. In the case of Seeed providing their modifications purely with a device tree overlay, then either method would work so long as that overlay is loaded prior to running driver loads. However, the errors in the log do not (at least not yet) relate to an incorrect device tree.
Note in your extlinux.conf that in one of the entries (“Stereolabs”) it names both a device tree (.dtb file) and a device tree overlay (.dtbo file). Overlays are intended to modify existing subsets of a tree. Overlays are not intended to add “new” tree branches. One of your entries in extlinux.conf (“Stereolabs”) has an overlay, the other does not (“primary”). We don’t know if the base .dtb file is the same or not because the “primary” entry does not have the FDT line to name a device tree file; instead, that entry without the FDT is taking the device tree from a partition. We don’t know if the partition content is the same or different compared to the FDT file of the “Stereolabs” extlinux.conf boot entry.
If an overlay finds the intended tree nodes, then it should “edit” those nodes. If the overlay does not find the correct node(s), then it should in theory “do nothing” and leave the original tree (I’m not sure but there should probably be an error message about loading an overlay if the overlay cannot do what it is intended to do).
I’m thinking of you adding another extlinux.conf boot entry. Explanation follows. I’m going to reemphasize a quote from one of my earlier posts:
Two things are critical at this point: The Seeed method likely names a device tree file; the other method does not. This means your base device tree for the Seeed method is that .dtb file, modified by the overlay .dtbo file; your other entry gets its device tree from a partition, not from a file, and if I recall correctly, does not have the .dtbo file. You need to keep a working entry in case something goes wrong, but you need to try an extlinux.conf boot entry which is the “primary” entry, remains without the FDT line from Stereolabs, but does include the part about the overlay .dtbo file. Post a copy of the new extlinux.conf for reference. Try this, and save a full serial console boot log (a dmesg may be less informative regarding device tree logs prior to the Linux kernel loading). Attach a serial console boot log and emphasize the boot entry this goes with for people just joining the thread.
The module which fails due to apparently missing dependencies is the sl_max96712 module. Run lsmod, verify if sl_max96712 is or is not loaded. Probably it is not loaded. *If not loaded, then use sudo modprobe <module name> on the module, but monitor “dmesg --follow” prior to attempting the module load. We are interested only in the new log which occurs as a result of the attempt to modprobe, plus any kind of message which occurs from the modprobe line itself.
If anything fails in the modprobe (assuming the command itself is correct and the module refuses to load), you must attach file “/proc/config.gz” here to the forum.
Also, if there is a failure, attach a copy of the .dtbo file named in your extlinux.conf.
What this should accomplish:
- You’ll have the Stereolabs device tree, so the devices themselves can be found by a valid driver.
- We will know about the load of the driver. Paired with
config.gzwe can perhaps guess at what is missing or suspicious about the pairing of kernel module and kernel configuration (remember, loading a module requires that (A) the module must be compiled against that kernel config, and (B) any functions/signatures required by the module are implemented either in the kernelImageor another module loaded prior to loading your module. - For good measure, show your new
extlinux.confand make sure that in any log we know which boot entry you were in.
I am interested in your observation:
This suggests that the above combination has a driver which loads into the kernel Image of the NVIDIA install method. Perhaps the NVIDIA kernel install is slightly different when using the SEEED method. *In that case we have a hint that we should use the Seeed method, but with the NVIDIA kernel, and to use the device tree and device tree overlay of the Stereolabs entry.
Another way of saying this same thing:
- A module only loads to a compatible kernel.
- Your capture card is not plug-n-play, which means the device tree is required for the driver to find the capture card. Perhaps this is in the Stereolabs device tree, or perhaps it is in that tree after the overlay is installed. This more or less defines the binary interface of the Stereolabs capture card which the driver can work with. The error you saw for loading the driver was not from lack of finding Stereolabs because the driver never loaded. It is possible that once the module loads, then there could be a failure if device tree or overlay are incorrect, but we’d make progress because the kernel module would load. Since you have a working case, I’m assuming that case has a correct device tree and overlay.
- We are going to try to get the Seeed method (which might be the same as the NVIDIA method if their carrier board layout is the same as the reference board) with the Stereolabs driver module, and so it is loading of that module we are experimenting with.
Basically, I think your observation that Seeed may have modified the kernel could be correct. However, it might just be that the Seeed kernel needs a kernel module added. Alternatively, something quite different could have occurred, e.g., some patch changed the source code itself, in which case we’d have more problems (to be discussed if we get there).
The device tree does name where to find a device when that device is not plug-n-play. Additionally, there would be a a “compatible” entry which tells the name(s) of a driver(s) which are capable of working with that hardware. Be sure to attach a copy of the device tree and the overlay named in your extlinux.conf so that we can reverse compile that and see what it actually says.
Be sure to include the /proc/config.gz for kernel configuration. Both of your existing boot entries use the same kernel I think, “/boot/Image”, and so it won’t matter which you boot to (if there is not a line entry in extlinux.conf naming the same LINUX /boot/Image, then it is possible one of them uses a partition which has a different kernel in it compared to the one in /boot; we must know exactly which kernel is used, so make sure to include that extlinux.conf after you modify it, and name which entry is booted whenever you add information like the result of attempting modprobe).
The part which is most different about the JP6 kernel from NVIDIA is that it is a mainline kernel. In the past NVIDIA has produced a modified source just for the Jetson, and the source would have been tightly controlled by NVIDIA. By switching to mainline there may be differences which NVIDIA did not create.