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

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

[Hung-Chun Tseng]

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
-- 
2.43.0

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

[E Shattow]

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

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

[Hung-Chun Tseng]

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
-- 
2.43.0

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

[Hung-Chun Tseng]

Hi E,

On 10/24/26 07:45, E Shattow wrote:
> 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".

Thanks, that makes sense. For v4 I plan this split:

1. BootROM: the fixed clocks, the clock and reset controllers, uart0,
   sdhci0, emmc and qspi in k1.dtsi, and the SPI NOR flash@0 in the
   board files.

2. DRAM setup, as an add-on for Yixun to take or leave: i2c2 and i2c8
   in k1.dtsi, and the EEPROM, the PMIC and its buck1, buck3 and aldo1
   in the board files.

> Capture all the BootROM SPL loader flows
> that we can understand (USB missing currently? please add this)

USB download mode goes through the OTG port (FDL button, then
"fastboot stage"), but mainline has no node for the USB2 OTG
controller behind it yet. The DWC3 is a different controller. So there
is nothing to tag for USB today, and I'd add it once that node lands.

Yixun, could you confirm that the BootROM uses that OTG controller for
USB download, and that it does not touch the DWC3?

Does this split look right to you? I'll send v4 after the merge window.

Thanks,
Hung-Chun

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

[E Shattow]

On 10/25/26 20:38, Hung-Chun Tseng wrote:
> Hi E,
> 
> On 10/24/26 07:45, E Shattow wrote:
>> 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".
> 
> Thanks, that makes sense. For v4 I plan this split:
> 
> 1. BootROM: the fixed clocks, the clock and reset controllers, uart0,
>    sdhci0, emmc and qspi in k1.dtsi, and the SPI NOR flash@0 in the
>    board files.
> 
> 2. DRAM setup, as an add-on for Yixun to take or leave: i2c2 and i2c8
>    in k1.dtsi, and the EEPROM, the PMIC and its buck1, buck3 and aldo1
>    in the board files.
> 
>> Capture all the BootROM SPL loader flows
>> that we can understand (USB missing currently? please add this)
> 
> USB download mode goes through the OTG port (FDL button, then
> "fastboot stage"), but mainline has no node for the USB2 OTG
> controller behind it yet. The DWC3 is a different controller. So there
> is nothing to tag for USB today, and I'd add it once that node lands.

Is "[PATCH v4 0/8] Add SpacemiT K1 USB2.0 controllers support" what you
refer to?:

https://lore.kernel.org/lkml/20261009-b4-spacemit-k1-usb2-v4-0-2d98e5324d9a@linux.spacemit.com/

"The SpacemiT K1 SoC has two USB2.0 controllers, one has Dual-Role
support, but the hardware has no internal OTG registers, the other is
Host only. These controllers are compatible with Chipidea USB2 driver
with some flags set and reset control support."

Looking briefly at the design guide section 1.4.1 "USB 2.0"

https://cdn-resource.spacemit.com/file/chip/K1/K1_Hardware_Design_Guide_en.pdf

quote "USB2.0-0 serves as the Download interface." and "A self-powered
USB device/hub is needed to test the host function of the dual-role
controller on Banana Pi F3, a MINI-PCIe USB2.0 module (a cellular module
e.g.) is needed to test the host only controller."

That looks to me like the target to hint. You could ask for the hints to
be added on that (USB 2.0) series, or note as a dependency for this
series and do so here.

Note also "[PATCH] riscv: dts: spacemit: enable USB2.0 controllers on
Milk-V Jupiter"
https://lore.kernel.org/all/20261009-jupiter-usb2-v1-1-ab84a00d3b64@redhat.com/

"On Milk-V Jupiter boards, usb2_0 is connected to a Type-C connector
which cannot act as a power source."

More of the same, I think, adding bootph-pre-ram hints to phy@c0940000
and usb@c0900000 or by label references per-board whatever shape of that
is best. Per-board is more useful to potential users of this at SPL
phase but may introduce inaccuracies (as it pertains to describing
hardware) as the decisions to default to "host" mode and not "otg" are
common sense things that are (looking at history of these decisions)
permissible to be different than default hardware state after possible
BootROM configuration. I do wonder if the SPL environment directly
following BootROM is something we should perhaps be describing in Linux
devicetree as its own distinct thing. Well, don't forget about USB
anyway I think there's an actionable there and it's just a coordination
issue which series should take that change.

> 
> Yixun, could you confirm that the BootROM uses that OTG controller for
> USB download, and that it does not touch the DWC3?
> 

...

> Does this split look right to you? I'll send v4 after the merge window.>
> Thanks,
> Hung-Chun

Yes, thank you -E