H E Shattow, On Sat, 31 Oct 2026 at 23:45, E Shattow <[email protected]> wrote: > > Hi Anand, > > On 10/31/26 09:45, Anand Moon wrote: > > Hi Hung-Chun, > > > > Thanks for testing this series > > > > On Sat, 31 Oct 2026 at 17:26, Hung-Chun Tseng <[email protected]> > > wrote: > >> > >> Hi Anand, > >> > >> Thanks for sending this. I tested the series on a Milk-V Jupiter, > >> booting from SD. It reaches the U-Boot prompt, but the SPL no longer > >> finds the PMIC: > >> > >> Get board name:k1-x_milkv-jupiter > >> No PMIC (-19), leaving rails as found > >> DDR firmware: [0xc0820740]:0xf0227179, size:0x8d98 > >> > >> With a Jupiter -u-boot.dtsi that has the same i2c8/pmic block this > >> patch removes, the SPL sets the rails before DDR init: > >> > >> vdd_core, value:900000 > >> vdd_1v8, value:1800000 > >> vdd_1v8_mmc, value:3300000 > >> > >> The commit message says the regulator configuration moves to > >> dts/upstream, but k1-milkv-jupiter.dts there has no bootph tags and no > >> vdd_core/vdd_1v8/vdd_1v8_mmc names, so the PMIC is not in the SPL > >> device tree and pmic_init() skips it. It works on this board only > >> because the rails come up at usable voltages. How do you plan to let > >> the SPL find the rails? > >> > >> The new file is also not picked up until 6/6. U-Boot includes > >> <dtb>-u-boot.dtsi, $(SYS_SOC)-u-boot.dtsi, $(SYS_CPU)-u-boot.dtsi, > >> $(SYS_VENDOR)-u-boot.dtsi and u-boot.dtsi (scripts/Makefile.lib), > >> which on K1 means k1-u-boot.dtsi or spacemit-u-boot.dtsi. Nothing > >> includes spacemit-k1-u-boot.dtsi until 6/6 sets > >> CONFIG_DEVICE_TREE_INCLUDES, so 1/6 to 5/6 build without any K1 > >> overlay, which breaks bisection. I have not built each step. Naming the > >> file k1-u-boot.dtsi would get it included from this patch on, and 6/6 > >> would not need DEVICE_TREE_INCLUDES. > >> > > I think configs/spacemit_k3_defconfig uses the same approach. > > > > CONFIG_DEVICE_TREE_INCLUDES="spacemit-k3-u-boot.dtsi" > > > > Please split up the dts reorganization changes into three-or-four > patches [A], ([B]), [C], and [D]; The initial transition to this as [A] > should be not adding or fixing any nodes: > > A1. New file 'spacemit-k1-binman.dtsi' with '#include "binman.dtsi"' at > the top just after the copyright identifier > > A2. '&binman' sections from per-board k1-*-u-boot.dtsi overrides should > merge and be moved appended to spacemit-k1-binman.dtsi > > A3. New file 'spacemit-k1-u-boot.dtsi' specified by > CONFIG_DEVICE_TREE_INCLUDES, with '#include "spacemit-k1-binman.dtsi"' > as the very last line of the file. > > A4. Merge and move from per-board k1-*-u-boot.dtsi files any properties > in devicetree root that are rejected by upstream for devicetree-rebasing > subtree. The content should be inserted after the copyright identifier > and before the last line of the file '#include > "spacemit-k1-binman.dtsi"'. An example of this is the memory controller > reg override in which we specify a sensible fixed-amount value so that > the bootloader bring-up can function, but this configuration would never > be accepted upstream. If not for [B] this should only be the memory > controller reg override, apparently. > > B. Resolve the presence of /aliases and /chosen nodes in > k1-musepi-pro-u-boot.dtsi compared to the lack of such nodes in > k1-bananapi-f3-u-boot.dtsi and then upstream and/or merge and move any > resolution to spacemit-k1-u-boot.dtsi ; I do not understand the > implications so maybe you would find that this can be ignored unchanged > and then removed in [D] > > C(n). Import to per-board -u-boot.dtsi and spacemit-k1-u-boot.dtsi all > the proposed upstream changes (i.e. bootph-pre-ram hints). These should > be grouped by upstream patch discussion thread or commit id so that from > view of u-boot git tree one upstream discussion thread (patch or commit > id) is referenced in a comment within the dtsi file(s) that import it. > > D. Delete redundant nodes and properties from per-board dtsi places > where they are redundant. This deletion is not combined with [C] because > we should be able to later do a git revert of [C(n)] when a > corresponding commit lands upstream. > > There is going to be a considerable amount of per-board overrides that > are identical over a subset of per-board override -u-boot.dtsi and so > duplication is preferable as it is (from U-Boot git log) logically > grouped by commits that reference a particular upstream discussion or > commit id. That is also to say further organizing some changesets in > additional dtsi files to be included from a subset of per-board dtsi is > considered, but I am not yet convinced it would be helpful rather than > just duplicating it among the per-board dtsi files now and having a > sensible git history for reverting later when appropriate. > Thanks for your review comments.
Yes, I will follow this procedure in future patch series. For this series, I wanted to have the changes tested on another development board so that I could better understand and follow the proposed process for restructuring the code changes. Thanks for the guidance. Thanks -Anand
