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 <[email protected]> > --- > 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 <[email protected]> > + * > + * 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/[email protected]/ 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
