We are trying to run 2 cameras simultaneously (IMX258 via RAWA + OV5640 via CAMSV) on Genio 520 (MT8189, BSP aiot8391p2_64_bsp), but hit -EUSERS errors and unstable results even after raising MTKCAM_MAX_NUM_OF_MULTI_OPEN to 2. Does MediaTek officially support concurrent dual-camera on this platform/SKU? If yes, is there a reference implementation or validated sample app we can follow?
Hi @B_o_Long ,
Since you’re using aiot8391p2_64_bsp, I assume your question is about the Android camera stack. Please correct me if you’re working on the Linux/Yocto side instead.
On Android, concurrent dual-camera is technically feasible on Genio 520 (MT8371), but it is not enabled in the default BSP configuration.
Please submit an e-Service ticket with your use case described as precisely as possible, including:
- Sensor combination and the interface each one uses (IMX258 on RAWA, OV5640 on CAMSV)
- Target resolution, frame rate, and output format for each stream
- Whether the two streams need to be truly simultaneous, or sequential/switched
- BSP version and Android version in use
- Your application-level use case (e.g., preview + recording, dual preview, CV/AI pipeline)
Our RD team will evaluate the use case and provide the necessary patches and configuration guidance for your setup.
Best Regards,
Andy Hsieh
MEDIATEK e-SERVICE TICKET
Nội dung soạn sẵn để nộp qua cổng e-Service của MediaTek, theo đúng 5 mục Andy Hsieh (Community Moderator) yêu cầu.
Subject
Request for official patch — Concurrent dual-camera (IMX258 + OV5640) on Genio 520 (MT8371/MT8189), BSP aiot8391p2_64_bsp
Body
Hi Andy,
Following up on the community post regarding concurrent dual-camera support. Please find the requested details below.
1. Sensor combination and interface:
● Camera 0 (rear): IMX258, RAW Bayer sensor, connected via RAWA (CAM_A)
● Camera 1 (front): OV5640, YUV sensor, connected via CAMSV (CAMSV_2), using virtual channel (virtualChannelSupport=true)
● Confirmed via device tree: RAWA uses smi_larb17, CAMSV_2 uses smi_larb13 — separate memory bus paths
2. Target resolution, frame rate, output format:
● Camera 0 (IMX258): up to 30fps, driver supports fixed [30,30] and [60,60] (hs_video) ranges at up to 4208×3120
● Camera 1 (OV5640): 15fps (driver-level hard limit — all 5 sensor modes in ov5640mipiyuv_Sensor.c share the same preview_setting() I2C sequence, all report max_framerate=150)
● Desired result: Camera 0 stable at 30fps, Camera 1 stable at 15fps, running concurrently
3. Simultaneous vs sequential:
● Truly simultaneous (concurrent preview from both cameras at the same time), not switched/sequential
4. BSP and Android version:
● BSP: aiot8391p2_64_bsp
● SoC: MT8189 (die), commercial name MT8371/Genio 520
5. Application-level use case:
● Dual preview — both camera feeds displayed and processed concurrently (please specify your actual end use here: e.g. dual preview for monitoring, or preview + CV/AI pipeline)
Issue encountered:
After raising MTKCAM_MAX_NUM_OF_MULTI_OPEN to 2, we still hit -87 (EUSERS) and unstable behavior. Root-caused to several gaps in the default BSP:
● MTKCAM_MAX_NUM_OF_MULTI_OPEN cflag missing in one of the two build modules that reference it (mtkcam3/main/hal/devicemgr/base/Android.mk)
● PIPInfo::maxOpenCamDevNum defaults to 0 and is reset to 0 on flush(), causing the validation check in CameraDeviceManagerImpl::onValidateOpenLocked() to reject the second camera even when only 2 devices are ever registered
● After resolving the above, camera open succeeds, but result is inconsistent across runs (sometimes both cameras open at 15/15fps, sometimes only one opens, sometimes both fail with errorCode=4). Traced to ForceTwin being forced to 1 in cam_ResMgr.cpp whenever RAWB is disabled via efuse (Glob_Efuse.disable_rawb), independent of MTKCAM_HAVE_NATIVE_PIP. This appears to introduce a timing-sensitive resource registration retry loop against CAM_B (which is correctly blocked since RAWB is efuse-disabled on this SKU), and its interaction with session configuration timing is not stable.
Could your RD team confirm the correct/official handling for the ForceTwin path when RAWB is efuse-disabled but the second sensor is routed entirely through CAMSV (not RAWB), and provide the validated patch set for stable concurrent operation on this SKU?
We're happy to share our full internal investigation log/diagram if useful.