Re: [PATCH v3 0/2] riscv: dts: spacemit: mark K1 boot nodes bootph-pre-ram

[E Shattow <e@freeshell.de>]

Hi Hung-Chun,

On 10/24/26 02:25, Hung-Chun Tseng wrote:
> On the SpacemiT K1 the BootROM loads the next boot stage into SRAM, and
> that stage sets up DRAM. This series marks the nodes it needs for that
> bootph-pre-ram: the SoC clocks, UART, boot media and the two I2C buses
> in k1.dtsi, and the board EEPROM (which holds the DRAM configuration),
> the PMIC rails and the SPI NOR in the board files.
> 
> The vendor confirmed that the BootROM itself does not access the
> EEPROM [1]. It is tagged because bootph-pre-ram covers the phase that
> sets up SDRAM, and DRAM cannot be trained without it.
> 
> Testing: all K1 DTBs build, and dtbs_check is clean for them with and
> without this series.
> 
> I used Claude to help read the U-Boot SPL and the device trees. I
> checked the changes and ran dtbs_check myself.
> 
> Changes in v3:
> - Reword both commit messages to describe the hardware instead of what
>   an SPL does, and drop the U-Boot paragraph from patch 1 (E)
> - Tag i2c2 in k1.dtsi too, as every K1 board has the EEPROM there
> - Tag eeprom@50 on the OrangePi RV2 and R2S, missed in v2 (Sashiko)
> - Drop the Assisted-by tags, see commit 1e035297ffda
> - Keep E's Reviewed-by on both patches, as the changes are the ones
>   discussed on v2
> - Link to v2: https://lore.kernel.org/all/20261017180141.3477743-1-alan.tseng.cs@gmail.com/
> 
> Changes in v2:
> - Tag i2c8 in k1.dtsi instead of in every board file (Yixun)
> - Rebase onto the spacemit dt-for-next branch
> - Link to v1: https://lore.kernel.org/all/20261012235624.77993-1-alan.tseng.cs@gmail.com/
> 
> [1] https://lore.kernel.org/all/20261021083425-GKA125937@kernel.org/
> 
> Hung-Chun Tseng (2):
>   riscv: dts: spacemit: k1: mark boot-critical SoC nodes bootph-pre-ram
>   riscv: dts: spacemit: mark K1 board boot devices bootph-pre-ram
> 
>  arch/riscv/boot/dts/spacemit/k1-bananapi-cm6.dtsi |  5 +++++
>  arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts   |  5 +++++
>  arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts |  6 ++++++
>  arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts    |  6 ++++++
>  arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts  |  5 +++++
>  arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts  |  6 ++++++
>  arch/riscv/boot/dts/spacemit/k1.dtsi              | 14 ++++++++++++++
>  7 files changed, 47 insertions(+)
> 
> 
> base-commit: d05c6236496071916e19012cda7149465f15e66e

The series is looking good although I now have a nitpick about patch
organization since it is acknowledged that BootROM does not setup or
access DRAM. BootROM may load code that does not setup or access DRAM.
At the moment the patches are strictly split on "K1 SoC" and "Per-board"
while the one stated intention is DRAM initialization after some of the
peripherals BootROM may have configured also; that makes sense not
knowing the split between BootROM and other things and so I ask to
change this.

Split the patches in this series so we have a clearly defined initial
changeset that does "Extend the BootROM configured peripherals to device
tree bootph-pre-ram hints for any SPL loaded by that BootROM in SD,
eMMC, and SPI NOR boot modes". Capture all the BootROM SPL loader flows
that we can understand (USB missing currently? please add this) from
documentation, and with active participation from the vendor for any
questions. If that is an excessive burden then please let me know I will
look more closely at and give specific suggestions to be more helpful.

If you choose to keep patches for anything else that you want to add
(e.g. DRAM setup) extra beyond the basis of "BootROM" extension, defer
to the maintainer preference if they want it or not. I'm okay with "DRAM
setup" being an add-on with this series, but just as well for my
interest it certainly belongs in U-Boot if not in Linux. There may be
different requirements for linuxboot, oreboot, etc.

Aside, if the add-on patch is rejected by the maintainer here, it will
be then the basis for import to U-Boot (this is a different discussion)
and we can refer to the mailing list archive link; for the accepted
patches anyways these can be imported early to U-Boot and dropped there
when devicetree-rebasing will receive the changes.

I do not wish to delay anything but it seems to me to be important that
there is a distinction between describing the environment in which we
find ourselves subsequent to hardware BootROM, and any other extra
additions that we have for the most likely use (U-Boot SPL, linuxboot,
oreboot, whatever it is that wants DRAM initialized).

-E