Hi Junhui,
On 11/7/26 01:06, Junhui Liu wrote:
> Hi Yixun,
>
> On Fri Nov 6, 2026 at 2:59 PM CST, Yixun Lan wrote:
>> Hi Junhui,
>>
>> On 00:40 Fri 06 Nov , Junhui Liu wrote:
>>> Add the DDR controller node and mark the UART, I2C EEPROM and required
>>> clock and reset providers for use before DRAM initialization.
>>>
>>> Add a binman description for spl/u-boot-spl-mkimage.bin, combining SPL
>>> with the external LPDDR5 PMU IMEM firmware and wrapping the payload in
>>> a SpacemiT K3 boot image header.
>>>
>>> Signed-off-by: Junhui Liu <[email protected]>
>>> ---
>>> arch/riscv/dts/spacemit-k3-binman.dtsi | 24 +++++++++++++++
>>> arch/riscv/dts/spacemit-k3-u-boot.dtsi | 54
>>> ++++++++++++++++++++++++++++++++++
>>> 2 files changed, 78 insertions(+)
>>>
>> ..
>>> diff --git a/arch/riscv/dts/spacemit-k3-u-boot.dtsi
>>> b/arch/riscv/dts/spacemit-k3-u-boot.dtsi
>>> index 352e85e7de8..0976b2647b5 100644
>>> --- a/arch/riscv/dts/spacemit-k3-u-boot.dtsi
>>> +++ b/arch/riscv/dts/spacemit-k3-u-boot.dtsi
>>> @@ -4,3 +4,57 @@
>>> */
>>>
>>> #include "spacemit-k3-binman.dtsi"
>>> +
>>> +&{/soc} {
>>> + ddrc@cb000000 {
>>> + compatible = "spacemit,k3-ddrc";
>>> + reg = <0x0 0xcb000000 0x0 0x01000000>,
>>> + <0x0 0xcc000000 0x0 0x01000000>;
>>> + spacemit,apmu = <&syscon_apmu 0x4e8>;
>>> + bootph-pre-ram;
>>> + };
>>> +};
>>> +
>> I'm not sure if it's a good idea to also move "ddrc" to mainline kernel
>> dts, at least to reach a consensus about stable compatible name..
>
> I see. I can try submitting a DT binding patch to the Linux kernel
> mailing list later to get the DT node design reviewed and reach
> consensus on the compatible string.
I think it is "memory-controller@cb000000" and then whatever compatible
is decided; for starfive JH7110 it is memory-controller@15700000 and
compatible "starfive,jh7110-dmc". Compatible "spacemit,k3-ddrc" is
equally likely to be accepted as anything else.
Send it upstream and insist on either a bootph-pre-ram hint for the
memory controller node or adding a label and see what happens with the
discussion. I don't think BootROM touches the memory controller, so it's
a weak justification but it may be less objectionable to seat a
bootph-pre-ram hint there than adding a label to reference it later on
as something that Linux will never see a driver for or reference in any
other way. I wouldn't complain if someone objected that had a clever
enough SPL they could argue that this was wasting valuable SRAM for, and
wanted to reverse that as not a strictly necessary or correct hardware
description; just flip it for a label upstream and whack it into U-Boot
&label { bootph-pre-ram; };. The label just seems like it will annoy
Linux maintainers more than sticking bootph-pre-ram in there directly.
Usually in Linux device tree, nodes are rejected unless there is an
driver in-tree that consumes the compatible. The notable situation of a
memory controller which does not, and logically will never have, any
driver in Linux because any driver necessarily is at a phase before
Linux is possible to have running; this is allowable to upstream that
node to Linux device tree on discretion of the maintainer.
>
>>
>>> +&i2c2 {
>>> + bootph-pre-ram;
>>> +
>>> + eeprom@50 {
>>> + bootph-pre-ram;
>>> + };
>>> +};
>>> +
>> For adding all "bootph-pre-ram" properties, I'd like to see patch
>> submission to mainline kernel tree, see similar thread for K1 SoC[1]
>> so eventually it will get synced to a proper directory under dts/upstream/..
I'd suggest just the BootROM SPL loader modes -adjacent nodes first...
that is going to be the bulk of it and the most effort but also does not
depend on what you do in SPL here now. Thankfully there is vendor
participation to answer questions about BootROM internals.
>>
>> But, I know it would take long time for the upstream dts hit into U-Boot
>> tree, so a compromised solution is that we temporarily accept this patch
>> before the sync, then fix it up later accordingly..
>>
>> Link:
>> https://lore.kernel.org/r/[email protected] [1]
>
> I agree. However, since our SPL support is still incomplete, we may need
> to add more nodes for pre-DRAM initialization. I'd prefer to wait until
> the bring-up is complete and submit all the required DTS changes
> together, rather than sending multiple incremental patches.
>
Device tree upstream is a hardware description for reference by software
and not the other way around. BootROM is hardware; what the possible
state of peripherals is as configured by BootROM SPL loader modes should
be described in devicetree for any SPL consumer loaded by the BootROM,
and bootph-pre-ram hints are a reasonable mechanism of filtering just
this for SRAM-constrained environment.
The additional bootph-pre-ram hints, not described by covering what
BootROM touches, might also be allowable but that is not guaranteed.
Start with sending a series to LKML with bootph-pre-ram hints for what
all BootROM SPL loader modes might configure.
-E
