PROCESSOR-SDK-AM62X: Implemented Driver occasionally disappear

Hi,

Looking at the failure log, it seems like v4l2_fwnode is not loaded. When it failed, did Linux finish booting?

Is this on a custom board or AM62x EVM board?

Can you share the changes that your customer made to add the sensor driver?

Can you share the complete log of the failed case?

Thank you.

Jianzhong

Hello,

Thank you for your reply.

>When it failed, did Linux finish booting?
I'm checking it now.

>Is this on a custom board or AM62x EVM board?
It's on custom board.

>Can you share the changes that your customer made to add the sensor driver?
I'm not sure exact change, because this driver is made by third party.


>Can you share the complete log of the failed case?
I'm asking this to customer now.

Best Regards,

Hello,

We checked above remaining items and have additional question.

>>When it failed, did Linux finish booting?
>I'm checking it now.
Yes, they could also confirm kernel was booted up in this case.

>>Can you share the complete log of the failed case?
>I'm asking this to customer now.
We could not get this yet, because this condition rarely happen.

Here is additional question.

* Customer use emmc boot on their board. And when they re-performed format and re-install kernel image and filesystem, then it seems that this condition disappeared.
Then, customer asked following question.(This includes their assumption.)

Q. Here is part of customer's boot up sequence.

sleep(10);　// Wait to launch TI I2C driver
system("insmod /local/bin/gpio-pca953x.ko.1.0");// Launch IO expander of external camera module
system("insmod /local/bin/ar1335.ko.1.0");　// Launch Camera module itself

Customer assume that kernel fail to read module in case of "fail". However, could you please give your opinion about there is possibility that kernel rarely fail to read module ? 

Best Regards,

Ryuuichi machida said:

system("insmod /local/bin/gpio-pca953x.ko.1.0");// Launch IO expander of external camera module
system("insmod /local/bin/ar1335.ko.1.0");　// Launch Camera module itself

Why did your customer manually load the modules using insmod? Are they not using the device tree to tell the kernel automatically load the modules?

Hello,

>Why did your customer manually load the modules using insmod? 
I'm not sure the exact reason. However, I believe that both providing as kernel module or incorporating to kernel itself work fine.
I think that the difference is how customer consider their design concept.
Is there any problem to use custom kernel module ?

Best Regards,

Hello,

Additinal information about below.
>Why did your customer manually load the modules using insmod? 
At first, customer tried to implement their driver to kernel itself. However, customer saw that load time of this "gpio-pca953x.ko" driver was very later on SDK9.2(At first, customer developed their app by using SDK8.6. But they did not see this phenomenon.).
Because of this, eventually, "ar1335.ko" was loaded earlier than "gpio-pca953x.ko". As specification of driver, "gpio-pca953x.ko" should be loaded earlier than "ar1335.ko". Therefore, they changed driver load method.

Please continue to confirm previous question.

Best Regards,

Let me check internally and get back to you in a day or two.

Hello,

Do you have any update about this ?

Best Regards,

Hello,

Could you please give your status ?

Best Regards,

Hello,

Thank you for your reply.

>On the contrary, when you use "insmod" to load a module, you only load one specific module. It is possible some modules may be missed.
Yes, understand the difference b/w modprobe and insmod.
However, I think if code did not implement related module of ar1335 and gpio-pca953x, we can see implementation failure definitely when booting up.
What scenario did you imagine ?

Best Regards,

Hello,

Here are some reasons that I can think of why your module failed to load:

1. Module Dependencies:

• Missing dependencies: Many modules rely on other modules to function. If a required dependency is not loaded or cannot be found, the module attempting to load it will fail.
• Circular dependencies: While rare, it's theoretically possible to have a circular dependency where module A needs B, and B needs A, leading to a deadlock.

2. Module Design/Programming Errors

• Bugs in the module code: A module can contain programming errors (e.g., dereferencing a null pointer, out-of-bounds access, race conditions, incorrect memory management). When the kernel detects such an invalid operation, it often results in a "kernel oops" or even a "kernel panic," preventing the module from loading correctly and potentially destabilizing the system.
• Initialization failures: The init function within a kernel module (which runs when the module is loaded) might encounter an error and return a non-zero value, indicating a failure to initialize.

3. Insufficient memory: this is unlikely, but a very large or memory-hungry module might fail to allocate the necessary kernel memory.

Regards,

Jianzhong

Hello,

Thank you for sending your consideration.
I will check them with customer.

Best Regards,

Hello,

I would like you to confim one additional thing.
According to customer, they found that they also failed load for another module when they observed issue which I posted.

Module : "j721e-csi2rx”
Error message when this issue is observed : "j721e-csi2rx: probe of 30102000.ticsi2rx failed with error -22"

Unlike "ar1335" and "gpio-pca953x", "j721e-csi2rx" is built-in module and original module which is provided by TI SDK.
It is different situaltion from previous one, but have you ever observed similar issue on your side ?

Best Regards,

This failure is most likely caused by incorrect or missing configuration data in the device tree.

Hello,

Thank you for your reply.

>This failure is most likely caused by incorrect or missing configuration data in the device tree.
Customer do not change any setting for module of "j721e-csi2rx". Do you mean that you may have something issue on your Linux SDK ?

Best Regards,

Ryuuichi machida said:

Customer do not change any setting for module of "j721e-csi2rx".

Did they make any changes in the device tree? 

Can they add debug prints to every place where error is reported in this function https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c?h=ti-linux-6.1.y#n1606? This can help us understand what's the exact failure?

Thanks,

Jianzhong