i.MX8MP FRDM: Boot Race Condition (Built-in CSI vs Module IMX219) & System Hang on Unbind

[SreeSan]

Hello NXP Community,

​I am currently bringing up an IMX219-77 camera module (Evaltec) on the i.MX8M Plus FRDM board using the official NXP Yocto BSP (Kernel 6.6.36).

​I am encountering a "No remote pad found" error during boot, which prevents the media controller (/dev/media0) from registering. All debugging points to a boot-time race condition between the built-in CSI bridge driver and the loadable sensor module. However, I cannot apply the standard runtime workaround because unbinding the CSI driver causes an immediate system hang.

​Hardware & Software Setup:

• Board: i.MX8M Plus FRDM
  
  
• ​Camera Module: Evaltec IMX219-77
  
  
• Connection: Connected to MIPI-CSI 1 using the official Raspberry Pi “Standard-Mini” (15-pin to 22-pin) ribbon cable.
  
  
• ​BSP/Image: Official NXP Yocto Demo Image (Kernel 6.6.36, No initramfs)

​The Core Issue (Timing Mismatch):

The logs reveal a significant timing gap between the host driver and the sensor driver:

1. ​[~2.05s] mxc-mipi-csi2-sam loads. Since it is compiled as Built-in in the standard image, it initializes early, probes the endpoint, fails to find the sensor (No remote pad found), and aborts the link.
2. ​[~10.00s] imx219 finally loads. Since it is a Loadable Module (.ko), it waits for the rootfs to mount, arriving 8 seconds too late.

​
Troubleshooting Steps & DTS Verification:

I have modified the device tree (os08a20.dts decompiled/adapted) and verified the following:

       Sensor Configuration:

• ​Regulators: Configured VANA-supply, VDIG-supply, and VDDL-supply to use fixed/dummy regulators to prevent probe deferral due to missing power resources.
• ​Reset GPIO: Updated reset-gpios to match the specific GPIO expander mapping of the FRDM board.
  
  • ​Endpoint: Verified data-lanes = <2> and link-frequencies match the IMX219 capabilities.
    
    Topology:
  • ​Aliases: Added csi0 and isi0 aliases; verified they appear correctly in /proc/device-tree.
  • ​Links: Manually verified phandle and remote-endpoint hex values in /proc to ensure a valid chain: Sensor -> CSI -> ISI.
  • ​ISI Interface: Set interface = <0 0 2> (for CSI-1) and added the required fsl,blk-ctl reference.

  
  ​The Blocker (System Hang on Unbind):

  
  I attempted to fix the race condition at runtime by unbinding the CSI driver to force a re-probe after the sensor is loaded:

  
  Bash command  : echo 32e40000.csi > /sys/bus/platform/drivers/mxc-mipi-csi2-sam/unbind

  
  ​Result: The command causes an immediate System Hang (SSH session closes, console freezes).

  
  
  • Hypothesis: Unbinding the CSI driver cuts power to the MEDIAMIX or VPUMIX domain, causing other active consumers to panic.
  
  
  • ​Mitigation Attempt: I modified the DTS to explicitly set status = "disabled" for HDMI, LCDIF, GPU (2D/3D), and VPU nodes to isolate the CSI bridge as the sole consumer.
  
  
  • ​Outcome: Even with these consumers disabled, the board still hangs immediately upon unbinding 32e40000.csi.

  
  ​My Questions:

  
  
  1. Given that I cannot use an initramfs with this specific image, is there a kernel boot parameter or method to force the built-in mxc-mipi-csi2 driver to defer probing until the sensor module is available?
  2. Why does unbinding the CSI driver cause a hard lockup even when all known neighbors (Display, GPU, VPU, ISI) are unbound or disabled? Is there a known safe sequence for the i.MX8MP?
  3. Is the only viable solution to recompile the kernel and change CONFIG_MXC_MIPI_CSI2_SAM from * (Built-in) to M (Module)?
     
     Please correct me if my understanding of the boot process or the hardware dependency is incorrect. I am open to any alternative approaches. If any further logs or configuration files are needed to diagnose this, please let me know and I will provide them immediately.
     
     

     ​I have attached the boot logs (dmesg) showing the timestamp gap and the modified Device Tree Source (os08a20.dts) for reference.

     ​
     Any guidance would be greatly appreciated.
     
     Thank you

     
     
     

[SreeSan]

Thank you for the detailed breakdown of the potential solutions.

I have investigated your suggestions, but I need to highlight a critical architecture constraint in this specific NXP image that prevents standard reordering or reloading techniques.

The constraint:
CSI bridge driver(imx8-mipi-csi2-sam) is compiled as built-in, whereas the sensor driver (imx219) is a loadable module.

Evidence of Driver Compilation Type

I ran the following checks on the target board to confirm this:

1. CSI Driver is Built-in:
The driver appears in modules.builtin, confirming it is statically compiled into the kernel image and initializes early in the boot sequence( before the file system is mounted).

Bash env:

root@imx8mpfrdm:~# cat /lib/modules/$(uname -r)/modules.builtin | grep -Ei "mipi-csi2-sam"

kernel/drivers/staging/media/imx/imx8-mipi-csi2-sam.ko

2. Sensor is a module
The sensor driver exists as a loadable object file on disk, i.e it can only load after the root file system is ready( approx 8 sec after the CSI driver has already failed).

Bash env:

root@imx8mpfrdm:~# root@imx8mpfrdm:~# find /lib/modules/$(uname -r) -name "imx219.ko"

/lib/modules/6.6.36-lts-next-g0d1e1544fd15/kernel/drivers/media/i2c/imx219.ko

Response to Specific Suggestions:

​Regarding Suggestions #1 (Device Tree) & #2 (Module Order):
Since the Host driver is built-in, I cannot control its load order relative to a disk-based module via modprobe.d or standard dependency mapping. It will always load first.

Regarding Suggestion #3 (Driver Modification):
Modifying the driver source to add a retry mechanism would require recompiling the kernel. If a recompile is unavoidable, the standard (and cleaner) solution would be to simply change the driver configuration from Built-in <*> to Module <M>, which resolves the race condition natively without maintaining custom patches. My goal right now is to find a solution that avoids recompilation if possible.

Regarding Suggestion #5 (Reload Sensor):
I tested removing and reloading the sensor driver (rmmod imx219 && modprobe imx219). While the sensor reloads successfully, the built-in CSI Bridge does not re-trigger a handshake or probe attempt. It appears to enter a failed state during boot and stops listening.

Request for Guidance on Suggestion #4 (Deferred Probing)
​This appears to be the most viable path. Since I am trying to avoid a full kernel recompile to change the driver type, I would like to pursue the Deferred Probing approach.
​Does the imx8-mipi-csi2-sam driver support a specific Kernel Boot Parameter to force it to wait or retry probing? Is there a specific patch or mechanism in the NXP BSP to enable standard EPROBE_DEFER behavior for this bridge when the remote endpoint is not yet available?

Please correct me if there is a method to unload/reload the built-in bridge logic that I might have missed.
​
Thank you again for your time and assistance.

[Bio_TICFSL]

Hello,

This appears to be a timing issue where the sensor driver loads after the CSI driver has already attempted to establish links, resulting in the "No remote pad found" error. This prevents proper media device registration.

This race condition is a known issue with MIPI-CSI drivers that can occur when the sensor driver and host CSI bridge driver don't initialize in the proper sequence.

The system hang you're experiencing when trying to unbind the CSI driver is concerning but not entirely unexpected. Unbinding an active MIPI-CSI driver can sometimes cause issues if there are active DMA transfers or incomplete transactions.

Here are some potential solutions:

1. **Device Tree Approach**: Modify your device tree to ensure the sensor driver loads before the CSI bridge driver by adjusting the compatible strings priority or using phandle references to establish proper dependencies.

2. **Module Loading Order**: Force the correct module loading sequence by creating a modprobe configuration file that ensures the sensor driver loads before the CSI driver.

3. **Driver Modification**: Implement a retry mechanism in the CSI driver that attempts to re-establish links if initial linking fails, allowing for late-binding of sensors.

4. **Deferred Probing**: Modify the sensor driver to use deferred probing, allowing it to wait for necessary dependencies before completing initialization.

5. **Alternative to Unbinding**: Instead of unbinding the CSI driver (which causes a system hang), try using `rmmod` and `modprobe` on the sensor driver after the system is fully booted, which may trigger proper link establishment without affecting the CSI driver directly.

For immediate testing, you could try adding a delay in the boot sequence before the CSI driver loads to give the sensor driver time to initialize first.

Regards

[SreeSan]

Thank you for the detailed breakdown of the potential solutions. 

I have investigated your suggestions, but I need to highlight a critical architecture constraint in this specific NXP image that prevents standard reordering or reloading techniques. 

The constraint:
CSI bridge driver(imx8-mipi-csi2-sam) is compiled as built-in, whereas the sensor driver (imx219) is a loadable module. 

Evidence of Driver Compilation Type 

I ran the following checks on the target board to confirm this:

1.  CSI Driver is Built-in:
   The driver appears in modules.builtin, confirming it is statically compiled into the kernel image and initializes early in the boot sequence( before the file system is mounted).

   Bash env: 

   root@imx8mpfrdm:~# cat /lib/modules/$(uname -r)/modules.builtin | grep -Ei "mipi-csi2-sam"

   kernel/drivers/staging/media/imx/imx8-mipi-csi2-sam.ko

2. Sensor is a module
    The sensor driver exists as a loadable object file on disk, i.e it can only load after the root file        system is ready( approx 8 sec after the CSI driver has already failed). 

    Bash env: 

   root@imx8mpfrdm:~# root@imx8mpfrdm:~# find /lib/modules/$(uname -r) -name "imx219.ko"  

  /lib/modules/6.6.36-lts-next-g0d1e1544fd15/kernel/drivers/media/i2c/imx219.ko

 Response to Specific Suggestions:

​Regarding Suggestions #1 (Device Tree) & #2 (Module Order):
Since the Host driver is built-in, I cannot control its load order relative to a disk-based module via modprobe.d or standard dependency mapping. It will always load first.

Regarding Suggestion #3 (Driver Modification):
Modifying the driver source to add a retry mechanism would require recompiling the kernel. If a recompile is unavoidable, the standard (and cleaner) solution would be to simply change the driver configuration from Built-in <*> to Module <M>, which resolves the race condition natively without maintaining custom patches. My goal right now is to find a solution that avoids recompilation if possible.

Regarding Suggestion #5 (Reload Sensor):
I tested removing and reloading the sensor driver (rmmod imx219 && modprobe imx219). While the sensor reloads successfully, the built-in CSI Bridge does not re-trigger a handshake or probe attempt. It appears to enter a failed state during boot and stops listening.

Request for Guidance on Suggestion #4 (Deferred Probing)
​This appears to be the most viable path. Since I am trying to avoid a full kernel recompile to change the driver type, I would like to pursue the Deferred Probing approach.
​Does the imx8-mipi-csi2-sam driver support a specific Kernel Boot Parameter to force it to wait or retry probing? Is there a specific patch or mechanism in the NXP BSP to enable standard EPROBE_DEFER behavior for this bridge when the remote endpoint is not yet available?

Please correct me if there is a method to unload/reload the built-in bridge logic that I might have missed.
​
Thank you again for your time and assistance.