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

[E Shattow <e@freeshell.de>]

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