From: E Shattow <e@freeshell.de>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
Conor Dooley <conor@kernel.org>,
Hal Feng <hal.feng@starfivetech.com>
Cc: "Emil Renner Berthing" <emil.renner.berthing@canonical.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Conor Dooley" <conor+dt@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Paul Walmsley" <pjw@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/8] Add support for StarFive VisionFive 2 Lite board
Date: Wed, 19 Nov 2025 00:26:16 -0800 [thread overview]
Message-ID: <841b4250-0ac6-4b49-8c8e-a6d6bc675a1f@freeshell.de> (raw)
In-Reply-To: <1f96a267-f5c6-498e-a2c4-7a47a73ea7e7@canonical.com>
On 11/18/25 23:04, Heinrich Schuchardt wrote:
> On 11/19/25 00:10, Conor Dooley wrote:
>> On Tue, Nov 18, 2025 at 02:12:58AM +0000, Hal Feng wrote:
>>>> All,
>>>>
>>>> I repeat that the suggestion was made months ago (by Hal) to split
>>>> out the
>>>> OPP tables per-board from the period of time when I was complaining
>>>> about
>>>> 1.5GHz JH-7110 operation pushing TDP into over-temperature thermal
>>>> limit
>>>> on Milk-V Mars CM SoM.
>>>>
>>>> Whether or not JH7110S is a new compatible should follow precedence in
>>>> Linux development. JH-7110S is evidently the same tape-out as
>>>> JH-7110 and
>>>> however you deal with that in Linux is the appropriate way to deal
>>>> with that
>>>> here. Selection of OPP table for correct operation will be
>>>> determined by
>>>> bootloader, where, it is demonstrated by patch series sent to U-Boot
>>>> upstream to be selected ** per-board ** based on EEPROM content as
>>>> if it
>>>> was any other JH-7110 board deciding dts based on EEPROM content. Given
>>>> that it is the same tape-out I do not find a valid justification for
>>>> a new
>>>> compatible in the stack of adjacent software besides going along
>>>> with some
>>>> kind of marketing-driven answer about whether or not this is a new SoC.
>>>>
>>>> What I care about now is that the VisionFive 2 Lite series is in
>>>> good enough
>>>> shape and there's a possibility to act on this months-old suggestion
>>>> to split out
>>>> the OPP tables which as we have confirmed the JH7110S is the same
>>>> SoC as
>>>> JH7110 it makes a lot of sense to do.
>>>>
>>>> How is it supposed to work for binned silicon in Linux?
>>>
>>> Hi, Conor, Emil,
>>>
>>> What do you think about this? Hope to hear from you.
>>
>> Can someone just give me a yes/no question out of this thread? I'm not
>> really immediately sure what's being asked of me. What exactly do you
>> want to do with the opp-tables? "Split out" isn't super clear. Does that
>> mean into board files? I am guessing it does, since you're saying that a
>> particular board cannot support the 1.5 GHz mode. It's not unusual
>> though to use delete node for unsupported opp-table entries, could that
>> be done instead?
>>
>> FWIW, this weekend is -rc7, so I won't be applying any new material
>> after that.
>>
>
> There was agreement that the JH7110 and JH7110S need different operating
> points. This is realized via the different includes for the VisionFive 2
> Lite boards and the other boards.
>
> Support for the new compatible string "starfive,jh7110s" used by the
> VisionFive 2 Lite is already implemented in OpenSBI where it is needed
> for platform support (specifically reboot). It is also used in tag
> next-20251119 in drivers/cpufreq/cpufreq-dt-platdev.c. There is no
> technical need to role this back.
>
> The changes in OpenSBI and the cpu frequency driver could have been
> avoided by using
>
> compatible = "starfive,visionfive-2-lite-emmc", "starfive,jh7110s",
> "starfive,jh7110"
>
> to indicate that JH7110s is just a variety of JH7110. This also would
> match the best practice example in Documentation/devicetree/usage-
> model.rst:
>
> compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
>
> I guess we could add that third compatible value in a later patch.
No, how about doing that now instead of pushing out the wrong result?
>
> As U-Boot uses the Linux device-trees too, I have built U-Boot with the
> updated device-trees and had no problem to boot all supported JH7110 and
> JH7110S devices including the StarFive VisionFive 2 Lite.
>
Yes that is clear when reading the documentation, sounds good to me if
following the docs.
> A bootph-pre-ram property for booting from SD-card that was already
> missing before the series can be added via a separate patch.
You are referring to booting U-Boot SPL from SD-card. The supported
method for new designs (StarFive VisionFive 2 Lite is a new design) is
to boot U-Boot SPL from UART serial or SPI Flash. U-Boot Main has the
full unfiltered devicetree available and does in fact boot Linux from
SD-card as-is without what you refer to.
How then is U-Boot SPL boot from SD-card possible on StarFive VisionFive
2 Lite? There is only a boot button (serial or spi flash select). Is
this for a developer board with MSEL DIP, or some other boot selection
in hardware not mentioned?
>
> I think we should go ahead as is.
This is the review feedback I wish we'd had for Hal with the RFC and v1
of this series. I would now like the identified changes to be applied to
the devicetree. It says right there in the documentation how to do it,
thank you.
>
> Best regards
>
> Heinrich
B.R.,
-E
next prev parent reply other threads:[~2025-11-19 8:27 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 9:55 [PATCH v2 0/8] Add support for StarFive VisionFive 2 Lite board Hal Feng
2025-11-07 9:55 ` [PATCH v2 1/8] dt-bindings: PCI: starfive,jh7110-pcie: Add enable-gpios property Hal Feng
2025-11-07 9:55 ` [PATCH v2 2/8] dt-bindings: riscv: Add StarFive JH7110S SoC and VisionFive 2 Lite board Hal Feng
2025-11-07 9:55 ` [PATCH v2 3/8] riscv: dts: starfive: Rename jh7110.dtsi to jh711x.dtsi Hal Feng
2025-11-07 11:18 ` E Shattow
2025-11-07 9:55 ` [PATCH v2 4/8] riscv: dts: starfive: Split jh7110-common.dtsi and move opp table to it Hal Feng
2025-11-07 11:20 ` E Shattow
2025-11-18 15:12 ` Heinrich Schuchardt
2025-11-07 9:55 ` [PATCH v2 5/8] riscv: dts: starfive: jh711x-common: Move out some nodes to jh7110 common dtsi Hal Feng
2025-11-07 11:24 ` E Shattow
2025-11-07 9:55 ` [PATCH v2 6/8] riscv: dts: starfive: Add common board dtsi for JH7110s and VisionFive 2 Lite variants Hal Feng
2025-11-07 9:55 ` [PATCH v2 7/8] riscv: dts: starfive: Add VisionFive 2 Lite board device tree Hal Feng
2025-11-07 9:55 ` [PATCH v2 8/8] riscv: dts: starfive: Add VisionFive 2 Lite eMMC " Hal Feng
2025-11-07 11:11 ` [PATCH v2 0/8] Add support for StarFive VisionFive 2 Lite board E Shattow
2025-11-07 11:21 ` Heinrich Schuchardt
2025-11-07 12:01 ` E Shattow
2025-11-12 7:24 ` Hal Feng
2025-11-12 13:29 ` E Shattow
2025-11-07 17:20 ` Conor Dooley
2025-11-12 7:47 ` Hal Feng
2025-11-12 13:54 ` Emil Renner Berthing
2025-11-12 14:36 ` Conor Dooley
2025-11-13 3:42 ` Hal Feng
2025-11-13 10:42 ` Emil Renner Berthing
2025-11-13 15:16 ` E Shattow
2025-11-15 16:28 ` Emil Renner Berthing
2025-11-17 6:54 ` Hal Feng
2025-11-17 21:54 ` E Shattow
2025-11-18 2:12 ` Hal Feng
2025-11-18 23:10 ` Conor Dooley
2025-11-19 7:04 ` Heinrich Schuchardt
2025-11-19 8:26 ` E Shattow [this message]
2025-11-19 13:27 ` Emil Renner Berthing
2025-11-20 0:47 ` Conor Dooley
2025-11-20 2:47 ` Hal Feng
2025-11-20 2:38 ` Hal Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=841b4250-0ac6-4b49-8c8e-a6d6bc675a1f@freeshell.de \
--to=e@freeshell.de \
--cc=aou@eecs.berkeley.edu \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=emil.renner.berthing@canonical.com \
--cc=hal.feng@starfivetech.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).