MAINTAINERS | 4 + docs/system/riscv/k230.rst | 22 ++ hw/misc/Kconfig | 3 + hw/misc/k230_cmu.c | 881 ++++++++++++++++++++++++++++++++++++++++++++ hw/misc/meson.build | 1 + hw/misc/trace-events | 9 + hw/riscv/Kconfig | 1 + hw/riscv/k230.c | 14 +- include/hw/misc/k230_cmu.h | 58 +++ include/hw/riscv/k230.h | 2 + tests/qtest/k230-cmu-test.c | 310 ++++++++++++++++ tests/qtest/meson.build | 3 +- 12 files changed, 1302 insertions(+), 6 deletions(-)
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 <0860734llx@gmail.com>
---
Simon Law (4):
hw/misc: model K230 CMU registers
hw/riscv: connect the K230 CMU
tests/qtest: add K230 CMU coverage
docs/system/riscv: document K230 CMU support
MAINTAINERS | 4 +
docs/system/riscv/k230.rst | 22 ++
hw/misc/Kconfig | 3 +
hw/misc/k230_cmu.c | 881 ++++++++++++++++++++++++++++++++++++++++++++
hw/misc/meson.build | 1 +
hw/misc/trace-events | 9 +
hw/riscv/Kconfig | 1 +
hw/riscv/k230.c | 14 +-
include/hw/misc/k230_cmu.h | 58 +++
include/hw/riscv/k230.h | 2 +
tests/qtest/k230-cmu-test.c | 310 ++++++++++++++++
tests/qtest/meson.build | 3 +-
12 files changed, 1302 insertions(+), 6 deletions(-)
---
base-commit: f893c46c3931b3684d235d221bf8b7844ddbf1d7
change-id: 20260809-feat-k230-cmu-9b62e6dd23f3
Best regards,
--
Simon Law <0860734llx@gmail.com>
Hello, On Sun, Aug 9, 2026 at 7:47 PM Simon Law <0860734llx@gmail.com> 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 <0860734llx@gmail.com> 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
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 <bmeng.cn@gmail.com> wrote:
>
> Hello,
>
> On Sun, Aug 9, 2026 at 7:47 PM Simon Law <0860734llx@gmail.com> 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 <0860734llx@gmail.com>
>
> 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
© 2016 - 2026 Red Hat, Inc.