Re: [PATCH v2 0/8] Add support for StarFive VisionFive 2 Lite board

[Heinrich Schuchardt]

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.

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.

A bootph-pre-ram property for booting from SD-card that was already 
missing before the series can be added via a separate patch.

I think we should go ahead as is.

Best regards

Heinrich