ADV7282-M with iMX8M Plus

[kamalesh]

Hi,

I am using the kernel-6.6.52-2.2.0 image on the i.MX8M Plus. I have configured both the driver and the device tree. With one module, I was able to get the output, although in an alternate format.

However, when using the same driver and device tree on a different i.MX8M Plus module, it does not work. What could be the issue?

When I try to capture a video frame using GStreamer, it stops at the message:
New clock: GstSystemClock

There are no errors shown after this point. It behaves the same way as the working module up to that point, but no video is displayed.

I’ve been stuck with this issue for the past week.

Could you please help identify what might be causing the problem?

Regards,
Kamalesh

[Manuel_Salas]

Hello @kamalesh 

I hope you are doing very well.

Are you using i.MX8MP EVK? Or, please, explain what do you refer with "different i.MX8M Plus module". Maybe a SOM from another vendor?

Best regards,

Salas.

[kamalesh]

Hi, 

We got I.MX 8M PLUS modules from technexion.

What may be the issue??

Thank you.

Regards, 

Kamalesh

[kamalesh]

Hi,
Update:-
Both the working and non-working modules are showing the same kernel messages. I’ve shared the kernel log below. Please advise us.

[ 230.972349] Entered enum bus code
[ 231.008440] isi-capture 32e02000.isi:cap_device: Requesting format from mxc-mipi-csi2.1: code=0x200f, 720x576
[ 231.008465] isi-capture 32e02000.isi:cap_device: Received format from mxc-mipi-csi2.1: code=0x2006, 720x576
[ 231.013476] bypass csc
[ 231.013483] input fmt YUV4
[ 231.013487] output fmt YUYV
[ 231.013496] isi-capture 32e02000.isi:cap_device: ISI configured: src fmt=YUV32 (X-Y-U-V) 720x576, dst fmt=YUYV-16 720x576
[ 231.013507] isi-capture 32e02000.isi:cap_device: Buffer queued: index=0, size=829440 bytes
[ 231.013513] isi-capture 32e02000.isi:cap_device: Buffer queued: index=1, size=829440 bytes
[ 231.013518] isi-capture 32e02000.isi:cap_device: Buffer queued: index=2, size=829440 bytes
[ 231.013526] isi-capture 32e02000.isi:cap_device: Buffer queued: index=3, size=829440 bytes
[ 231.013531] isi-capture 32e02000.isi:cap_device: Buffer queued: index=4, size=829440 bytes
[ 231.013536] isi-capture 32e02000.isi:cap_device: Buffer queued: index=5, size=829440 bytes
[ 231.013542] isi-capture 32e02000.isi:cap_device: Starting streaming, buffer count=6
[ 231.014785] isi-capture 32e02000.isi:cap_device: ISI streaming setup complete
[ 231.014804] isi-capture 32e02000.isi:cap_device: Calling s_stream(1) on adv7282 4-0021
[ 231.014811] isi-capture 32e02000.isi:cap_device: Calling s_stream(1) on mxc-mipi-csi2.1
[ 231.029721] isi-capture 32e02000.isi:cap_device: Calling s_stream(1) on mxc_isi.1
[ 232.574681] isi-capture 32e02000.isi:cap_device: Calling s_stream(0) on adv7282 4-0021
[ 232.574703] isi-capture 32e02000.isi:cap_device: Calling s_stream(0) on mxc-mipi-csi2.1
[ 232.574730] isi-capture 32e02000.isi:cap_device: Calling s_stream(0) on mxc_isi.1


Regards,
Kamalesh

[Manuel_Salas]

Hello @kamalesh 

From logs, it make me think there is a hardware issue.

Could you please check with scope that the CLK signal?

Also, please try to do a i2cdump -y to the MIPI device and see if everything is working well.

Best regards,

Salas.

[kamalesh]

Hi,

Could you please elaborate how to check the mipi clock signals using i2c dump?

It will be helpful to debug the issue?

[kamalesh]

Note: We have 10 carrier boards. That working module is worked in all the 10 boards without any missing. Other modules are not working.

Regards,
kamalesh

[kamalesh]

Hi Manuel,

Update,

I have taken the clk_summary file details of working and non-working module. Could you please review and give comments to resolve the issue.

Please see this below files in drive.
https://drive.google.com/drive/folders/17sE6Zr-y0daN3xQ-vqKleOAQ_sKwBgmj?usp=sharing

Thank you.

[kamalesh]

Hi,
UPDATE:-

Actually we have done the I2C dump on this working as well as non working module.

Result:- register are proper in working module. But every reboot the register of non working module changing and it is not in a stable state.

These modules are same series only. Why this miscommunication happening?

Please help me to resolve this issue.

Thanks.

Regards,
Kamalesh

[Manuel_Salas]

Hello @kamalesh 

It appears it is a device tree issue.

Please provide the device tree for both modules.

From logs for clk_summary I could see the I2C1 is the difference (if MIPI is connected there). 

Best regards,

Salas.

[kamalesh]

Hi,

Apologies for the late reply.

Actually, I am flashing the same image to all modules using the UUU flashing tool along with a UUU flashing script.
How can the device tree differ between two identical modules?

Is it possible that there is another device tree present which is overwriting the one in my image? How could this be happening?

Regards,
Kamalesh

[kamalesh]

Hi,

Is there are any way to find out the issue here?
Any overwritten of information here?

Regards,
Kamalesh

[kamalesh]

Hi,
Is there any steps or informations to share?

Regards,
Kamalesh

[Manuel_Salas]

Hello, 

Could you please try to contact to the vendor where you get the modules?

If possible, get the schematics from both modules "to see if those are really the same".

Also, check if the part number of the processor (i.MX8MP) is the same in the modules.

Best regards,

Salas.

[kamalesh]

Hi Manuel,

Actually Both Modules part numbers are same and they are having the same schematics.

Please answer to this below question.
If any other software bootloader or other software files are overwriting my new uploading image. Is there any possibility for these?

Note:- I have checked the probe, getting Mipi signaling same in these two modules.

Regards,
Kamalesh

[Manuel_Salas]

Hello @kamalesh 

Could you please share the steps/method you used to load your images to the boards?

Then I can try by my side and confirm.

Best regards,

Salas.

[kamalesh]

Hi,

I am flashing the image using uuu tool with uuu.auto script. Script given below.

uuu.auto

uuu_version 1.2.39

# This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ
SDP: boot -f imx-boot-axon-imx8mp-sd.bin-flash_evk

# This command will be run when ROM support stream mode
# i.MX8QXP, i.MX8QM
SDPS: boot -f imx-boot-axon-imx8mp-sd.bin-flash_evk

# These commands will be run when use SPL and will be skipped if no spl
# SDPU will be deprecated. please use SDPV instead of SDPU
# {
SDPU: delay 1000
SDPU: write -f imx-boot-axon-imx8mp-sd.bin-flash_evk -offset 0x57c00
SDPU: jump
# }

# These commands will be run when use SPL and will be skipped if no spl
# if (SPL support SDPV)
# {
SDPV: delay 1000
SDPV: write -f imx-boot-axon-imx8mp-sd.bin-flash_evk -skipspl
SDPV: jump
# }

FB: ucmd setenv fastboot_dev mmc
FB: ucmd setenv mmcdev ${emmc_dev}
FB: ucmd mmc dev ${emmc_dev}
FB: flash -raw2sparse all imx-image-full-axon-imx8mp.rootfs-20250611051821.wic
FB: flash bootloader imx-boot-axon-imx8mp-sd.bin-flash_evk
FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi;
FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0
FB: done


I placed this file under tmp/deploy/images/axon-imx8mp/.
Part No:- MIMX8ML8CVNKZAB


Regards,
Kamalesh

[kamalesh]

Hi,

Any updates to identify the issue?

Regards,
Kamalesh

[kamalesh]

Hi,

Thank you for the support.

I have resolved the issue. Now i can receive the video stream over adv7282-m.

Regards,
Kamalesh

[kamalesh]

Hi,

Is there any update for us?
Please tell me any suggestion to resolve the issue.

Regards,
Kamalesh

[kamalesh]

Hi,

Could you please give any update or diagnosing steps to do?

Regards,
Kamalesh