I am working on a camera bring-up feature in U-Boot for the MediaTek Genio 520 EVK (MT8189 platform). The goal is to create a single software image capable of auto-detecting multiple front-facing camera variants (OV5640, Sony IMX258, and an OnSemi AP1302 + AR1335 coprocessor module) during the bootloader phase. The intent is to probe their distinct I2C addresses on I2C8 and dynamically apply the matching DTBO (conf-camera-*.dtbo) before booting the Linux kernel.
However, we ran into a roadblock during the I2C probing phase, and here is the technical reality of why the camera remains completely dead: routing a wire doesn’t matter if the water is turned off.
While our Device Tree pinmux successfully routes the CMMCLK clock wire to the physical camera pin, the internal CMMCLK hardware block inside the MediaTek processor is physically gated (powered off) by U-Boot by default to save power. Without writing raw, undocumented hexadecimal values directly to the SoC’s Clock Control registers, U-Boot simply cannot generate that 26MHz heartbeat required to wake up the sensors for an I2C handshake.
Has anyone successfully managed to un-gate or force-enable the camera master clocks (CAM_MCK / CMMCLK) via low-level register writes at the U-Boot stage for this SoC family? Any pointers to the relevant clock registers or clock framework overrides would be highly appreciated.
Hi @Seungmo_Kang
What do you mean by CAM_MCK / CMMCLK?
Are there corresponding Kernel DTS clock nodes and names?
Hi @chris.chen
Yes, exactly. `CAM_MCK` (Camera Master Clock) and `CMMCLK` are the hardware clock signals that drive the camera sensors. In the Linux kernel, these are typically managed by the MediaTek clock controller driver and exposed via the Devicetree clock framework. In the Linux Kernel DTS for the MT8189 / Genio 520, you will usually find them under the main clock controller nodes or a specific camera subsystem clock node (often tied to the `vidoesys` or a dedicated `camsys` clock topology). Specifically, they map to: * **Clock Node:** Usually managed by the `topckgen` or `camsys` device nodes (e.g., `compatible = “mediatek,mt8189-topckgen”` or `“mediatek,mt8189-camsys”`). * **Kernel Clock Names:** In the camera sensor DTS nodes (like the OV5640 or IMX258), they are requested via the `clocks` property, usually referencing names like `“clksq”` (frequently a 26MHz parent clock source) or explicitly `“cam_mck”` / `“cmmclk”`.
Hi @Seungmo_Kang
Yes, but I can’t find CAM_MCK or CMMCLK in mt8189.dtsi, the board DTS, camera.dtsi, or the clock driver. They don’t seem to be clocks controlled by the SoC’s clock controller.
Hi @chris.chen
MediaTek has confusing clock naming conventions by looking directly at the source code.
You couldn’t find CMMCLK in the clock driver because CMMCLK isn’t a clock—it is just the name of the physical wire. Here is the translation between MediaTek’s hardware pins and their internal clock drivers, which explains why our “Crystal Bypass” failed.
The MediaTek Translation
In the Linux Device Tree overlay you shared earlier, there was this specific clock block:
DTS
clocks = <&vlp_cksys_clk CLK_VLP_CK_CAMTG0_SEL>;
clock-names = "xclk";
assigned-clocks = <&vlp_cksys_clk CLK_VLP_CK_CAMTG0_SEL>;
assigned-clock-parents = <&topckgen_clk CLK_TOP_UNIVPLL_192M_D8>;
-
The Internal Clock (CAMTG0): Inside the SoC, the clock that drives the camera is called the Camera Timing Generator (CAMTG). As you can see in the overlay, Linux configures CLK_VLP_CK_CAMTG0_SEL to use the SoC’s Universal PLL (UNIVPLL) as its parent source, and divides it down to 24MHz.
-
The Physical Pin (CMMCLK0): CMMCLK0 is strictly the Pinmux function for GPIO 22. It tells the multiplexer: “Take whatever signal is coming out of CAMTG0 and route it to this copper pin.”
Hi @Seungmo_Kang
U-boot does not support the vlp_cksys_clk driver.
If you want to enable the CLK_VLP_CK_CAMTG0_SEL clock, you can refer to the Linux vlp_cksys_clk driver for porting.