Re: [PATCH] spacemit: k1: add Milk-V Jupiter

[E Shattow <e@freeshell.de>]

Hi Hung-Chun,

On 10/12/26 08:15, Hung-Chun Tseng wrote:
> The SPL already maps the Milk-V Jupiter EEPROM product name
> "k1-x_milkv-jupiter" to "spacemit/k1-milkv-jupiter", and the upstream
> device tree for the board is in dts/upstream, but the board is not in
> CONFIG_OF_LIST. board_fit_config_name_match() therefore finds no
> configuration for it and U-Boot proper starts with the default
> (Banana Pi BPI-F3) device tree.
> 
> Add a u-boot.dtsi for the board and list it in CONFIG_OF_LIST. The
> board is close to the BPI-F3: the EEPROM is at 0x50 on i2c2 and the P1
> PMIC at 0x41 on i2c8, with the same buck1/buck3/aldo1 rails, so the
> dtsi follows k1-bananapi-f3-u-boot.dtsi. Like the MusePi Pro, the
> Jupiter has an SPI NOR flash on the QSPI controller, so mark it
> bootph-pre-ram as well.
> 
> Signed-off-by: Hung-Chun Tseng <alan.tseng.cs@gmail.com>
> ---
> Not tested on hardware: I don't have a way to recover the board if the
> new boot chain fails, so this is compile-tested only. What I checked:
> 
> - The FIT built from spacemit_k1_defconfig now has a
>   "spacemit/k1-milkv-jupiter" configuration (conf-2), and the Jupiter
>   DTB carries the bootph-pre-ram and regulator-name properties from the
>   new dtsi.
> - On a Milk-V Jupiter running Linux, the EEPROM at 0x50 on i2c2 holds a
>   TlvInfo product name (type 0x21) of "k1-x_milkv-jupiter", which is the
>   name board/spacemit/k1/spl.c maps to "spacemit/k1-milkv-jupiter".
> - On the same board, the P1 PMIC answers at 0x41 on i2c8, and the SPI
>   NOR on the QSPI controller at 0xd420c000 is a GD25Q64, matching the
>   nodes this dtsi marks bootph-pre-ram.
> 
> A Tested-by from someone with a Jupiter would be welcome.
> 
>  arch/riscv/dts/k1-milkv-jupiter-u-boot.dtsi | 132 ++++++++++++++++++++
>  configs/spacemit_k1_defconfig               |   2 +-
>  2 files changed, 133 insertions(+), 1 deletion(-)
>  create mode 100644 arch/riscv/dts/k1-milkv-jupiter-u-boot.dtsi
> 
> diff --git a/arch/riscv/dts/k1-milkv-jupiter-u-boot.dtsi b/arch/riscv/dts/k1-milkv-jupiter-u-boot.dtsi
> new file mode 100644
> index 000000000..24bc87669
> --- /dev/null
> +++ b/arch/riscv/dts/k1-milkv-jupiter-u-boot.dtsi
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Copyright (C) 2026 RISCstar Ltd.
> + * Copyright (C) 2026 Hung-Chun Tseng <alan.tseng.cs@gmail.com>
> + *
> + * Based on k1-bananapi-f3-u-boot.dtsi.
> + */
> +
> +#include "binman.dtsi"
> +
> +/ {
> +	memory@0 {
> +		device_type = "memory";
> +		reg = <0x00000000 0x00000000 0x00000000 0x80000000>;
> +	};
> +};
> +
> +&uart0 {
> +	bootph-pre-ram;
> +};
> +
> +&osc_32k {
> +	bootph-pre-ram;
> +};
> +
> +&vctcxo_1m {
> +	bootph-pre-ram;
> +};
> +
> +&vctcxo_3m {
> +	bootph-pre-ram;
> +};
> +
> +&vctcxo_24m {
> +	bootph-pre-ram;
> +};
> +
> +&syscon_mpmu {
> +	bootph-pre-ram;
> +};
> +
> +&pll {
> +	bootph-pre-ram;
> +};
> +
> +&syscon_apmu {
> +	bootph-pre-ram;
> +};
> +
> +&syscon_apbc {
> +	bootph-pre-ram;
> +};
> +
> +&i2c2 {
> +	bootph-pre-ram;
> +
> +	eeprom@50 {
> +		bootph-pre-ram;
> +	};
> +};
> +
> +/*
> + * The kernel pmic@41 nodes use the standard regulator-* properties only;
> + * U-Boot's regulator framework looks up suppliers by `regulator-name`.
> + * Carry the U-Boot-specific names (vdd_core / vdd_1v8 / vdd_1v8_mmc) here
> + * so SPL can program the bucks that DDR training depends on.
> + */
> +&i2c8 {
> +	bootph-pre-ram;
> +
> +	pmic@41 {
> +		bootph-pre-ram;
> +
> +		regulators {
> +			buck1 {
> +				regulator-name = "vdd_core";
> +				bootph-pre-ram;
> +			};
> +
> +			buck3 {
> +				regulator-name = "vdd_1v8";
> +				bootph-pre-ram;
> +			};
> +
> +			aldo1 {
> +				regulator-name = "vdd_1v8_mmc";
> +				bootph-pre-ram;
> +			};
> +		};
> +	};
> +};
> +
> +&qspi {
> +	bootph-pre-ram;
> +
> +	flash@0 {
> +		bootph-pre-ram;
> +	};
> +};
> +
> +&emmc {
> +	bootph-pre-ram;
> +	max-frequency = <204800000>;
> +};
> +
> +&sdhci0 {
> +	bootph-pre-ram;
> +	max-frequency = <204800000>;
> +};
> +
> +&binman {
> +	u-boot-spl-ddr {
> +		type = "section";
> +		filename = "u-boot-spl-ddr.bin";
> +		pad-byte = <0xff>;
> +
> +		u-boot-spl {
> +		};
> +
> +		ddr-fw {
> +			type = "blob";
> +			filename = "ddr_fw.bin";
> +			align = <64>;
> +		};
> +
> +		u-boot-any {
> +			type = "section";
> +			size = <0>;
> +			offset = <0>;
> +		};
> +	};
> +};
> diff --git a/configs/spacemit_k1_defconfig b/configs/spacemit_k1_defconfig
> index 39c490438..8e8ecbb6d 100644
> --- a/configs/spacemit_k1_defconfig
> +++ b/configs/spacemit_k1_defconfig
> @@ -65,7 +65,7 @@ CONFIG_CMD_EXT4=y
>  CONFIG_CMD_FAT=y
>  CONFIG_EFI_PARTITION=y
>  CONFIG_OF_UPSTREAM=y
> -CONFIG_OF_LIST="spacemit/k1-bananapi-f3 spacemit/k1-musepi-pro"
> +CONFIG_OF_LIST="spacemit/k1-bananapi-f3 spacemit/k1-milkv-jupiter spacemit/k1-musepi-pro"
>  CONFIG_MULTI_DTB_FIT=y
>  CONFIG_ENV_OVERWRITE=y
>  CONFIG_SPL_DM_SEQ_ALIAS=y

Please firstly send a series upstream that adds such trivial nodes as
appropriate to all supported upstream spacemit/k1-*.dts boards.

Reading for reference:
https://lore.kernel.org/lkml/20260324220950-GKB767626@kernel.org/

Any trivial -u-boot.dtsi nodes (binman, max-frequency) must go upstream
to Linux. For reasons mentioned by Yixun when there is not any working
SPL in mainline U-Boot then it is not yet possible to test completely
the bootph-pre-ram nodes for inclusion upstream and anyways they are not
needed by anyone at that moment.

Since then, as we are seeing progress to mainline U-Boot with SPL
possible on K1 SoC, the bootph-pre-ram nodes are now appropriate to send
upstream. Any "max-frequency" nodes not possible to be accepted upstream
are likely a driver issue and should be discussed further.

If you carry these trivial nodes in u-boot temporarily is fine however
when doing so I recommend there should be acceptance upstream first by
the subsystem maintainer and then here include a mailing list archive
link or commit id for where an upstream Linux subsystem maintainer has
accepted the changes. The reason I suggest this is to not burden others
with this work and make it easy to remove entirely any per-board
-u-boot.dtsi that is carried here.

I suggest to focus on sending nodes upstream that are a requirement for
a bootloader following any of all available K1 BootROM boot modes, and
to make these changes land (where appropriate) into k1.dtsi,
k1-opp.dtsi, and/or k1-pinctrl.dtsi common shared includes. Per-board
bootph-pre-ram nodes would cover board-specific additional peripherals
not contained in the K1 SoC. The patch does not need to advertise U-Boot
because upstream dts describes hardware, so the commit message
justification should be any boot loader SPL following the K1 SoC
BootROM, and T-by tags would be appropriate when mentioning what
specific boot loader is tested.

Thank you,

-E Shattow