Trying to add in-tree kernel driver but it doesn't show up in modules.builtin

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi.

I’m trying to statically add to the kernel two different drivers for 4G and 5G modems.

Previously I had merged the driver code with already existing drivers but since it could lead to future errors and headaches, I decided to install both standalone drivers, statically, I.e. in tree.

After compiling the kernel and flashing a TX2, I do not see the drivers in /lib/modules/$(uname -r)/modules.builtin.

The steps that I’m taking are as follows:

Inside $DEVDIR/sources/kernel/kernel4-9/drivers/net/usb I’ve added two files, one for each driver. I will attatch both implementation files.
sim8200_wwan.c (16.8 KB)
sim7500_sim7600_wwan-noprobewarning.c (7.2 KB)

Inside the makefile, in the same directory, I added both drivers to the CONFIG_USB_NET object (which in the config file is set to ‘y’, therefore assigning them as statically built modules). So that line the makefile looks like this:
obj-$(CONFIG_USB_USBNET) += usbnet.o sim7500_sim7600_wwan-noprobewarning.o sim8200_wwan.o

Following the instructions provided by simcom, the driver option is also set to be built statically, in the config file. Changes to option driver included adding the usb devices to the device table.

#define SIMCOM_VENDOR_ID    0x1E0E
#define SIMCOM_SIM7600_PID  0x9001
#define SIMCOM_SIM8200_PID  0x9002

( ... )

{ USB_DEVICE(SIMCOM_VENDOR_ID, SIMCOM_SIM7600_PID)}, /* SIM7600 */
{ USB_DEVICE(SIMCOM_VENDOR_ID, SIMCOM_SIM8200_PID),
  .driver_info = RSVD(5) | RSVD(6)},                  /* SIM8200 */
{ USB_DEVICE_INTERFACE_CLASS(SIMCOM_VENDOR_ID, 0x9011, 0xff), /* Simcom SIM8200 RNDIS mode, Reserved the interface for ADB */
  .driver_info = RSVD(7) },

After compiling, in the $KERNEL_OUT directory, I can see the driver exists in modules.builtin but not in modules.order (not sure if it’s necessary though). Either way, I will link these modules files inside the compiled $KERNEL_OUT directory:
modules.order (26.9 KB)
modules.builtin (21.9 KB)
Module.symvers (831.8 KB)

I copied the generated Image and dtbs and flashed the TX2 with sudo ./flash.sh jetson-xavier-nx-devkit-tx2-nx mmcblk0p1

When flashed, inside the TX2, the drivers don’t seem to exist. They don’t show up in modules.builtin (which is what I would expect). Despite this dmesg does show:

[...] usbcore: registered new interface driver qmi_wwan_simcom7600
[...] usbcore: registered new interface driver qmi_wwan_simcom8200

So I don’t really know what to conclude from this. I would expect the drivers to show up in modules.builtin and be able run modinfo for each.

Also. when we boot the jetson with both modems connected (sim7600 and sim8200), and using lsusb, we see that they both show up with the same ID 9001 (that you can see is defined for the sim7600 modem, in the option driver). I understand that there’s something called udev rules which maps drivers to the devices, as far as I understand, but have no idea on how to work with it.

So I’m not sure if the drivers are statically built, because they don’t show up in modules.builtin (and I can’t modinfo them), but then both show up with one driver ID which confuses me, is it actually installed? What what happened to the other driver?
Hopefully I’m not being too confusing. Can anyone point something I’m doing / interpreting wrong?

Thank you.

2

Do you see your features listed somewhere in “zcat /proc/config.gz”? This is what the running kernel says its compile options were. Make sure what you built is actually running. It is possible that the kernel you think you are using is not in use.

3

Yes, they seem to match what I’ve set them to be.

Because of this, I’m very confident that I’m using the correct image.

Now I have two problems, one of which is that the when I connect the sim8200 modem, the wrong driver is being registered, but before that there’s something I want to also fix.

Is it possible that, while I’m using the correct image, the file that contains the builtin modules is not being updated?

I ask this because, when I connect the sim8200 modem, it registers the driver at that usb, but dmesg shows a bunch of export duplicate symbols for a symbol existing in usb_wwan. Now, this driver (usb_wwan.o) is set to be built statically into the kernel. This is what it’s on the makefile obj-$(CONFIG_USB_SERIAL_WWAN) += usb_wwan.o, the inside the jetson, the output of zcat /proc/config.gz | grep -i CONFIG_USB_SERIAL_WWAN is CONFIG_USB_SERIAL_WWAN=y, therefore it is statically built. And to remove any doubts, running modinfo usb_wwan yields intree: Y. So, I’m pretty certain that this is indeed already builtin.

Here’s dmesg in case it’s usefull somehow:
dmesg (1).txt (81.7 KB)

Both modem drivers have this driver as a dependency, I.e. sim8200 and sim87600 depend on the usb_wwan. And I think that when I plug in the modem, and it registers the driver at that USB, it also tries to install the dependency usb_wwan (which it should not, since is already builtin). So I assume that, somehow, it doesn’t know that that driver is already builtin and tries to install it again, therefore throwing the export duplicate symbol errors.
The only reference i have is the modules.builtin file (which does not contain usb_wwan, despite again, it being installed.

What could I be missing during the compile/flash process for the kernel to not know that the usb_wwan driver is statically built?

4

First, run the command “uname -r”. Then find out if the modules you are interested in are in a subdirectory of “/lib/modules/$(uname -r)/kernel”. If no modules are present, then modules are being searched for in the wrong location due to an incorrect pairing of “uname -r” and module install (usually due to not configuring CONFIG_LOCALVERSION for the suffix of “uname -r”).

Second, if new modules are installed, or even a new kernel with modules present, then consider updating module and feature metadata:
sudo depmod -a
(this will force an update of everything, and not just new modules)

If you have a module present which duplicates the feature(s) of a new integrated kernel Image, then you can no longer use the module. You could find them, and assuming they are not loaded, then temporarily disable them for testing via something like “bzip2” of the module file (and if you want it back, then just bunzip2 the file).

In some cases there might be more than one driver capable of handling a device based on chipset detection. The better driver might not be used if the other driver is found first. There are ways to blacklist a driver, or perhaps use udev to mark the better driver for a given device if plug-n-play. If not plug-n-play, then the driver would be changed in the device tree node for that device (the “compatible” node would remove the other driver and put in the new/better driver). It wouldn’t be unusual for a “knock-off” device (think “imitation of the real manufacturer’s device”) to use a generic chipset driver when there is a better driver (a “knock off” device might be cheaper to make because it doesn’t contain the actual better chipset, but I have no reason to think this is what is going on; it is only for illustration, but it is not a rare event).

I don’t know anything about your particular modem or driver. It seems though that you might have both a module and integrated kernel for the usb_wwan driver. Often people look for a feature via “lsmod”, and no (non-duplicated) driver symbol shows up there, so they build the driver as a module only to find out they now have a duplicated symbol. That’s why I suggest checking “/proc/config.gz”, and if you know there is not a duplicated module, then run “sudo depmod -a” (normally people just run “sudo depmod -A” if adding a single module and everything was ok and no actual integrated kernel Image was added). If you get a duplicated symbol, then it is not because the driver of two separate devices use the same driver; the reason is that the driver is already resident in the kernel and something is trying to add a conflicting driver…either the same driver a second time, or another driver with the same symbol (one example would be if there are two releases of a driver, one being an update, and the original is not removed first). Do you have a module still in place from a previous kernel which is incompatible (or a duplicate of) the original kernel’s configuration? Does “sudo depmod -a” show any debug output?

5

Hi.

sudo depmod -a doesn’t show any debug output. After depmod, pluging the modem still shows that error in dmesg, which makes sense since usb_wwan doesn’t exist in modules.builtin, I’m guessing.

From what I could gather, I do not have any other module that duplicates the symbol. Only the usb_wwan module is exporting usb_wwan_chars_in_buffer.

The only explanation that I can think of is that, when I plug the modem, It is trying to load all the modules that the driver depends on, For instance:
If I go to /lib/modules/(uname -r)/modules.builtin and manually add this entry kernel/drivers/usb/serial/usb_wwan.ko and then run sudo depmod -a, the duplicate symbol error goes away when I plug in the modem. Another error comes up though (in dmesg), which is Driver 'option' is already registered, aborting..., which tells me that it’s trying to add option when, again, it’s already statically built.
If I go ahead and do the same thing for option (add to modules.builtin, depmod -a) and reboot. When I plug in the modem, no errors whatsoever, the qmi_wwan_simcom8200 driver registers and we’re able to connect to 5G.

So I guess I’m pretty sure that the kernel, somehow, doesn’t know that both option and usb_wwan are already built in, and is trying to install them when it detects the usb modem.

Because manually editing the modules.builtin doesn’t seem like the canonical way of doing this, what should I be doing (when setting up the kernel / compiling /flashing etc…) that might be preventing the kernel from knowing they’re builtin?

6

Duplicate symbols can of course be from modules or drivers loaded by other modules or drivers, so you are correct to suspect that this could be from another driver or module (which is a driver). Do you have this working on another Linux system? If on the other system this is supported by modules, then you could find the output of “lsmod” and see which modules load as a requirement of that module. Each module listed shows “used by” at the right side. If you can do this on a system without duplicate symbols it should show the chain of required kernel features. This could be used on the Jetson to figure out what is needed, and also figure out where duplicates might be. The down side of this is that if your PC runs a 5.x kernel (and the Jetson runs a 4.x kernel), then there might be major changes.

Also, if your device is not plugged in, and you record the Jetson’s output from “lsmod”, and then plug in the device followed by checking “lsmod” again, what are the differences? You’d have to save both a “before” and “after” listing, then go through it line by line (or with a diff program, but that might require sorting).

Incidentally, which exact kernel source is this? Did you download from the specific L4T release? What L4T release is this (see “head -n 1 /etc/nv_tegra_release”)? What is your “uname -r”?

1 Like
7

Unfortunately, I currently do not have a working linux system where I could compare results. This particular driver that I’m trying to install (for the 5G sim8200 modem) is technically for the Jetson Nano, plus I think they also provide their own specific Image, on top of the driver itself, and currently I am not able to replicate, on a jetson nano, exactly how this installation behavior would’ve been.

lsmod shows the same output for both plugged and not plugged in. I’m not sure how that works. dmesg tells me that a driver is registered at usb… but I don’t see any actual difference in lsmod.

You can refer to this dmesg if you need to, to see what it does when I plug and unplug the modem.

NV tegra release is 32.6.1
Kernel release is 4.9.253-tegra

Sorry I can’t be more helpful, I’m a little lost at the moment at why this is happening.

8

I would expect lsmod to not differ between plugged-in and unplugged since there is a duplicate symbol error; your integrated feature will take precedence and always be there, and then a module plug-in attempt with duplicate symbols would provide an error message and fail to load.

I did look at the function which tries to export symbols already existing:
[ 254.889948] usb_wwan: exports duplicate symbol usb_wwan_chars_in_buffer (owned by kernel)

The error message does not say what the symbols are, but the file is:
drivers/usb/serial/usb_wwan.c

This file is part of the Linux kernel. This is also part of the serial UART control of the device. You added drivers, and so apparently what you added already exists…at least the UART part. So let’s back up a moment: Why did you add these external files? Are you certain the driver did not already exist? It is conceivable that the driver for the chipset did not exist, but it also added UART content which already exists. If that is the case, then you might need to find out which symbols are duplicated, and remove those from the source you add. It would be even better if you found out that the driver already exists in the default kernel source, in which case you could simply add that to the kernel config and not add source code. How did you determine that the default source code did not have the driver (which is different than simply not being configured)?

1 Like
9

Hi.

I would interpret from that that the duplicate symbol would be usb_wwan_chars_in_buffer, but then again, at this point I’m not one to trust error messages that much. Are you suggesting that we don’t know if that is the exported symbol, if there could be multiple duplicate exported symbols not mentioned, or if that usb_wwan_chars_in_buffer doesn’t mean anything at all and could be any symbol?

I’m asking this because, you asked if I was certain if the driver did not already exist. I’ve asked myself this as well, as it’s not obvious to me that the driver I attached in the first post (sim8200_wwan.c) is supposed to replace qmi_wwan.c or if it’s suppose to be an independent module. Running a diff check on both files, the similarities are obvious. But the fact that, in the implementation of the sim8200 driver, they remove all devices from the device table and only leave the SIM8200 module (the following snipper):

static const struct usb_device_id products[] = {
	{QMI_FIXED_RAWIP_INTF(0x1e0e, 0x9001, 5)},  /* SIMCOM 8200 */
	{ }					/* END */
};
MODULE_DEVICE_TABLE(usb, products);

And in my head, there’s no reason to remove all other usb_devices from there, other than assuming this is being implemented independently from the original qmi_wwan, thus having those usb_devices, plus the one in the sim8200 driver. With that said, while both drivers do not export any symbol (at least that I can tell), they both have same dependencies, or at least they share usb_wwan as one.
I think that, because they’re both loading that dependency, it’s being loaded twice (I don’t know why it wouldn’t know it’s already loaded), and exporting a duplicate symbol of that dependency (usb_wwan).

Hopefully this made sense to you.

I mean, at this point I could try to merge qmi_wwan.c and sim8200_wwan.c but it wraps back to what we’ve discussed back in the other thread. It could lead to problems down the road when that module has to be updated.

I am simply following these instructions provided by SIMCOM, to use with their module. I understand what you mean and I don’t think the default source code already has a driver for this.
Back in the end of 2020, my company was having the same struggle to add a driver for their 4G modem (sim7600), which would not work without the driver, so I’m going based on that. I’ve also attached that driver on the first post (sim7500_sim7600_wwan-noprobewarning.c) and that driver is loaded separately and worked fine since we’ve been able to successfully added it as a module to the source code.

I can’t say I’m certain of that, but I’m going both on our past experience with the sim7600 driver (that we added the module to the source code), and the instructions provided by SIMCOM for this driver. While these instructions don’t ask to implement the driver directly in the source code, I’m working around that problem we discussed in this thread, where “modprobing” their provided driver yielded exec format error.

I understand I’m working under a lot of assumptions, but otherwise it gets a little overwhelming. I’m going to try to be sure there’s not already a driver in the source code capable of handling this modem to be sure that the sim8200 driver is indeed to be added to the source code.

Do please answer me this.
Is it possible that say, 2 modules have the same dependency, the first module loads (and it’s dependency). Somehow the kernel doesn’t know the dependency is loaded, so when we load the second module, it tries to install the dependency again, and if that dependency exported any symbols, they would be duplicate (thus an error like that one we’ve seen would probably happen, I’m guessing).

Is this scenario possible?

10

I see this log message:

[  239.052947] usb_wwan: exports duplicate symbol usb_wwan_chars_in_buffer (owned by kernel)
[  239.116783] usb_wwan: exports duplicate symbol usb_wwan_chars_in_buffer (owned by kernel)
[  239.160981] usb_wwan: exports duplicate symbol usb_wwan_chars_in_buffer (owned by kernel)
[  239.205567] usb_wwan: exports duplicate symbol usb_wwan_chars_in_buffer (owned by kernel)
[  239.252825] usb_wwan: exports duplicate symbol usb_wwan_chars_in_buffer (owned by kernel)
[  239.296952] usb_wwan: exports duplicate symbol usb_wwan_chars_in_buffer (owned by kernel)

It does look like usb_wwan shows the duplicate message six times, but the duplication is only once (I should pay closer attention :P) for usb_wwan_chars_in_buffer. The feature with this export is “USB_SERIAL_WWAN”. There are other features which would also enable this feature (they don’t export this, but they require this). It is true though that there might be others. The implication is that if it is the module itself being duplicated, then every symbol exported would be a duplicate, and load stopped because of the first duplicate. Then again, it might be the only duplicate if there are not more symbol exports.

In your kernel source, from the root/top, what do you see from:
egrep -R 'EXPORT_SYMBOL.usb.wwan.chars.in.buffer' *
(make sure you also run this against your added files if they are not already part of the source being examined)

Every place where this is exported has the potential to be a source of duplication. The Kconfig of each can be used to determine which feature enables that symbol. If there is only one export (presumably from USB_SERIAL_WWAN), then we know that it is the same feature installed twice, and the plausible means of exporting one feature twice is from having both integrated and module formats. The module format is the last to load, and so it would fail to load due to an integrated feature.

The two files you’ve added don’t seem to have that export. My thought is that this is likely one feature installed twice rather than being symbols duplicated by the addition of your files. If that is the case, then we have to figure out why the content for export is in both the integrated kernel and the loadable module.

Note that if you use a configuration editor (which understands Kconfig), then enabling a feature which depends on other features will enable those other features, but it will also detect incompatibilities. Some features don’t have any dependencies (e.g., the most common “CONFIG_LOCALVERSION”), and can be safely hand edited, but unless you know for certain about this, then it is better to use a Kconfig-aware editor. When you’ve added source code files, and if those files don’t include Kconfig code adjustments, then they might fail even if you use a Kconfig-aware editor. Maybe. I did not see any export in those two files you posted, and so Kconfig changes to avoid conflict might not be needed. Thus the above “egrep” search question.

I doubt merging the two files is useful. They might not even be the problem. We have to know where the export is duplicated to go further.

Sometimes instructions for adding external source were intended for a different release…I don’t know about those SIMCOM instructions, I have not tried building this since I don’t have the device. The problem isn’t so much about not having a driver as it is failing to load a module for a duplicated export; it is possible that failed module has other non-duplicated exports, and the module load keeps the device from loading. “egrep” is your friend! :P

Normally the exec format error implies a wrong architecture, e.g., built for a PC but running on a Jetson. Lately I’ve been finding that this can also be a “bad error message” (™).

Once we’ve figured out the duplicate symbol, and if that is preventing other symbols from loading, we’ll be able to simplify this and continue.

Quite often two modules have the same dependency. Another feature depending on that should not normally fail, that is what the EXPORT is for…so that it is registered and found. If it is exported, then the other module depending on this will always see it. If the EXPORT does not exist, then loading a module providing that feature won’t complain of duplicates. You can’t have both. modprobe is the tool which helps us manually assist resolution of symbols (you could load a module with insmod, and then another with insmod, and if the symbols were added in the right order it would work; if in the wrong order, then the lack of symbol would be a complaint and load would fail; modprobe is the same other than understanding and ordering the insmods correctly).

Trivia: modprobe and Kconfig editors are analogous to each other, but one is at load time, the other is at compile time preperation.

1 Like
11

Output only this line:
drivers/usb/serial/usb_wwan.c:EXPORT_SYMBOL(usb_wwan_chars_in_buffer);
Which would support the case for the usb_wwan (somehow) being loaded twice.

Do you mean nconfig? I must confess I do not use this, and I probably should. Only until very recently I’ve become aware that editing a defconfig manually could lead to problems, if they had dependencies (it was actually you who said that). So I guess I should start enabling features with that, assuming you mean nconfig.

I agree, I mentioned it just to get it out of the way, because in the other thread I mentioned that as the ‘solution’, but let’s just do it the right way instead.

Yes, initially I spent way too much time trying to solve a problem that wasn’t the actual problem. I didn’t realize, until recently, how misleading bad error messages could be.

In what context are you referring when you mean “the EXPORT”? I’m not sure if you mean something in the Kconfig file, or the defconfig file.
I guess a follow up is, how can I be sure if usb_wwan is being exported (using your terminology, though I don’t really know what that means) and be sure it is registered? Assuming, of course, that the duplicate symbols come from this module being loaded but not registered (?) I’m guessing.

I guess we’ve narrowed down to: only usb_wwan exports that symbol, therefore it must be being loaded more than once, and thus duplicating a symbol it already exported previously.

I think I understand what you’re saying overall but I don’t really know how to proceed from here.
Any ideas on how I should go to try to solve this issue with this information?

Thank you.

12

If loaded twice, then either the module is already loaded, and then it is attempting to load again, or else, much more likely, the symbol exists as integrated into the kernel before trying to load the module. Just to verify, what do you see from:
zcat /proc/config.gz | grep 'CONFIG_SERIAL_WWAN'

There are several Kconfig-aware editors. My favorite is nconfig. There are also menuconfig and xconfig. The README file at the top of the kernel source lists many, although not all of them are interactive. When enabling a feature with one of these any dependency will also be automatically selected. At load time modprobe has essentially the same purpose. You can use any of those editors, e.g., nconfig, menuconfig, or xconfig. It just happens that nconfig is what I consider “the best” (with search functionality, but otherwise it is identical to menuconfig), plus it runs in a terminal and does not require a GUI (which xconfig requires). If you edit a configuration for kernel build without those you are very likely going to have issues. This is one case where if you changed config from module to integrated format using a regular editor, then this would contribute to the issue (it would still switch from module format to integrated, but if other features need to change when the module-to-integrated switch occurs, it would fail to adjust). Note that if you change an integrated feature, then often it is a good idea to change the CONFIG_LOCALVERSION and completely rebuild modules.

In mentioning EXPORT I am referring to symbol export. Kernels have a lot of symbols in them which the outside world does not see. It is the exported symbol which is basically presented for sharing across different locations. The error itself is an attempt to export a symbol twice. The kernel source code has this line (which is what the egrep command listed before was searching for in kernel source):
EXPORT_SYMBOL(usb_wwan_chars_in_buffer);

Since the export occurs in only one feature, it means the only possibility of duplication is from loading the feature twice (this is why I say that the files you added don’t cause a duplicate feature…they don’t have a separate EXPORT_SYMBOL(usb_wwan_chars_in_buffer);, and shows it is not a collision of incompatible features).

Is it possible you still have modules from the previous kernel build? If for example the module for CONFIG_LOCALVERSION already exists, and then you change it to integrated (“=y” instead of “=m”), then both module and integrated features would exist. If it does, then you can temporarily disable the module by using bzip2 or gzip on it when it isn’t loaded (and it can’t load due to duplicate symbol issues). The driver would be there, but it wouldn’t show up as a module.

Incidentally, is there a reason why you need this in integrated format? Is that what the docs said to use (the “=y” for this exact driver)?

This is correct:

Basically we have to find out if we can use the driver in the current integrated format. If not, then you might be rebuilding both kernel and modules using a new “uname -r” (with an altered CONFIG_LOCALVERSION, e.g., something like “CONFIG_LOCALVERSION=-usb-wwan”).

Double check the output of "zcat /proc/config.gz | grep 'CONFIG_SERIAL_WWAN'. Also note the current “uname -r”.

1 Like
13

Hi.

We no longer have the [ 254.889948] usb_wwan: exports duplicate symbol usb_wwan_chars_in_buffer (owned by kernel). The ultimate solution was the fact that CONFIG_USB_SERIAL_OPTION was set to =y, I.e. the option.o module was being built statically, instead of as a module, as it should’ve been.
The rest of this post will just give context on why this was like this, and why I think it solved it (just because I want to be sure I understand what happened and why this was the solution).

Back in the end of 2020, we integrated the SIM7600 modem, and the previous person in my company who was working on this, followed their instructions, which included adding the driver I mention in the first post (sim7500_sim7600_wwan-noprobewarning.c) and making some manual changes to tegra_defconfig, which I’ve now learned it’s not such a great idea, if you’re not sure about the dependencies of what you’re changing. Don’t really have a lot of context on that particular process, but I know it involved setting CONFIG_USB_SERIAL_OPTION to =y, which worked fine until now, when we now want integrate a 5G modem, the SIM8200.

Because I wasn’t aware that option module was out of tree by default, I never questioned it, a lack in my judgement honestly because it all pointed to it now that I think about it. Because option.o depends on USB_SERIAL_WWAN (usb_wwan,o) (which was an out of tree module), I assume usb_wwan was being loaded immediately, since option was in-tree, usb_wwan as a dependency, had to be loaded aswell immediately.
So then, when I plugged the modem, i guess the kernel was trying to load usb_wwan again, and the duplicate symbol error would occur.

This also explains why, prior to added the sim8200.o driver to the source code, using modprobe would yield the same duplicate symbol error, yet insmod would work as intended and the driver would indeed work.

So, to end this thread, I want to make sure I understood what happened. What do you think about this interpretation of what happened? Do you think this is accurate at all about what could’ve been happening?

Either way, now the driver registers and unregisters correctly when i plug in and out the modem, respectively, and I guess one thing I’ll take from this, i’ll start using nconfig more often, as you suggested, which could’ve avoided this issue entirely, if this was indeed what was happening.
Thank you for your help on this issue.

Francisco Zacarias

14

Also, just for clarity, one thing that I want to mention that isn’t really connected to the issue directly, but could cause some confusion, and certainly did cause to me.

I initially said that we had 2 modems (SIM7600 (4G) and SIM8200 (5G)) both SIMCOM. The instructions for the driver for sim7600 mentioned setting CONFIG_USB_SERIAL_OPTION=y (not sure why) but would not work otherwise. The reason why I got away with changing this back is because the driver for SIM8200, not only required it to work (apparently) but the driver itself is interchangeable between the two modems I.e. this SIM8200 driver is works as a driver for SIM7600 aswell, and therefore we will probably remove the SIM7600 driver we had to begin with, since now (I think) the solution is much cleaner.

Also, both modems have the same VID and PID, so the same driver gets assign to both with no further configurations, which I guess is fine because both work with it, but I think it’s weird two different devices from the same vendor having the same PID. This is something I have reach out to SIMCOM to understand better.

But anyway, this was just for context because I mentioned both modems at the beginning of the thread. But it’s not really an issue for the scope of this thread (or this forum even, I think).

15

I think you are correct about what happened with out-of-tree content. FYI, if anyone wishes to edit tegra_defconfig, I will instead recommend creating a duplicate with a new name, and then overwriting that with a generated “.config” (the active config in the output directory). Briefly:

  • make O=/some/where mrproper
  • make O=/some/where tegra_defconfig
    (now “/some/where/.config” exists and is an exact duplicate of tegra_defconfig)
  • make O=/some/where nconfig
    (any Kconfig-aware editor works, or if you know there are no dependencies, then direct edits work, e.g., for CONFIG_LOCALVERSION)
  • Now copy “/some/where/.config” (which has your modifications beyond tegra_defconfig) with a new name; example if already at the top of the kernel source:
    cp /some/where/.config ./arch/arm64/configs/tegra_custom_config
  • Now you can use “make tegra_custom_config” the same way you can “make tegra_defconfig”.
  • Hint: You could have a git repo of configs.

Usually serial requirements for a modem are because data and/or control is over a serial UART. Some versions of m.2 slot (and other variations) actually have USB available in addition to PCI.

1 Like
16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.