Re: [PATCH 0/4] Kendryte K230 CMU register model

Hi,
Thanks for your reply.
The clock model is not a must-have for the Linux build from the K230
SDK. the vendor clock driver allows PLL unlock:
[    0.093353] thermal_sys: Registered thermal governor 'step_wise'^M^M
[    0.409760] [ERROR K230_CLK]:pll pll0 is unlock.^M^M
[    0.414011] [ERROR K230_CLK]:pll pll1 is unlock.^M^M
[    0.417540] [ERROR K230_CLK]:pll pll2 is unlock.^M^M
[    0.421088] [ERROR K230_CLK]:pll pll3 is unlock.^M^M
[    0.456215] k230-powerdomain 91103000.sysctl_power: powerdomain init ok^M^M

But Linux mainline will boot fail, it poll STAT.bit0 of PLL forever.
From drivers/clk/clk-k230.c:
#define K230_PLL_LOCK_TIMEOUT 0
static int k230_pll_prepare(struct clk_hw *hw)
{
        struct k230_pll *pll = hw_to_k230_pll(hw);
        u32 reg;

        /* wait for PLL lock until it reaches lock status */
        return readl_poll_timeout(K230_PLLX_LOCK_ADDR(pll->reg, pll->id), reg,
                                  reg & K230_PLL_LOCK_STATUS_MASK,
                                  K230_PLL_LOCK_TIME_DELAY,
K230_PLL_LOCK_TIMEOUT);
}

Furthermore, SDHCI/USB PHY/SPI flash driver require valid clock
config, else causes fatal error.

Best regard,
Simon

On Fri, Aug 14, 2026 at 3:53 PM Bin Meng <[email protected]> wrote:
>
> Hello,
>
> On Sun, Aug 9, 2026 at 7:47 PM Simon Law <[email protected]> wrote:
> >
> > The Kendryte K230 machine currently lacks the Clock Management Unit (CMU)
> >   register interface required by the K230 SDK U-Boot and the Linux K230 clock
> >   driver. As a result, software probing the PLL and sysclk providers cannot
> >   observe the expected reset values or register update semantics.
> >
> >   This series adds a minimal, deterministic K230 CMU model.
> >
> >   The model covers:
> >
> >   - four PLL register blocks at 0x91102000..0x9110203f;
> >   - the defined sysclk registers in the 0x91100000 window;
> >   - the software-visible SPI2AXI_CLK_DIV register at sysclk offset 0x108;
> >   - reset values and writable/reserved/read-only masks;
> >   - PLL control write-enable semantics;
> >   - write-one-to-trigger update behavior;
> >   - deterministic PLL lock and initialization status;
> >   - VMState for stable PLL and sysclk register state;
> >   - qtest coverage for reset, masks, write-enable, W1T, status, sysclk
> >     updates, unknown offsets, and system reset;
> >   - K230 machine wiring and user-facing documentation.
> >
> >   The model intentionally does not propagate clock frequencies to QEMU devices or
> >   change CPU execution speed. Peripheral reset, power control, and the
> >   guest-initiated K230 reboot backend remain outside the scope of this series.
> >   Those functions require separate reset/power models and a matching OpenSBI
> >   backend.
> >
> >   The implementation is based only on the existing K230 machine and does not
> >   depend on unmerged RMU, Timer, SPI, or SDHCI device series.
> >
> >   Testing:
> >   - QTEST_QEMU_BINARY=/workspace/qemu/build/qemu-system-riscv64
> >     /workspace/qemu/build/tests/qtest/k230-cmu-test
> >     (10/10 subtests passed)
> >   - QTEST_QEMU_BINARY=/workspace/qemu/build/qemu-system-riscv64
> >     /workspace/qemu/build/tests/qtest/k230-wdt-test
> >     (7/7 subtests passed)
> >   - K230 direct Linux boot and K230 U-Boot boot
> >   - Linux K230 clock probe and clk_summary validation
> >   - CMU source/destination migration smoke
> >
> > Signed-off-by: Simon Law <[email protected]>
>
> Is this clock modeling a must-have to make U-Boot or Linux boot on the
> QEMU k230 machine?
>
> Is an unimplemented region enough to make the software happy?
>
> Regards,
> Bin