Message-ID: <841b4250-0ac6-4b49-8c8e-a6d6bc675a1f@freeshell.de>
Date: Wed, 19 Nov 2025 00:26:16 -0800
From: E Shattow <e@...eshell.de>
To: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
 Conor Dooley <conor@...nel.org>, Hal Feng <hal.feng@...rfivetech.com>
Cc: Emil Renner Berthing <emil.renner.berthing@...onical.com>,
 Albert Ou <aou@...s.berkeley.edu>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Krzysztof Wilczyński
 <kwilczynski@...nel.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Manivannan Sadhasivam <mani@...nel.org>, Palmer Dabbelt
 <palmer@...belt.com>, Paul Walmsley <pjw@...nel.org>,
 "Rafael J . Wysocki" <rafael@...nel.org>, Rob Herring <robh@...nel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/8] Add support for StarFive VisionFive 2 Lite board


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

Powered by blists - more mailing lists