linux-kernel - Re: [PATCH v3 6/7] riscv: dts: starfive: Add initial StarFive JH7110 device tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+yQ3+0lyo5OQr2z@spud>
Date:   Wed, 15 Feb 2023 07:59:27 +0000
From:   Conor Dooley <conor@...nel.org>
To:     Hal Feng <hal.feng@...rfivetech.com>
Cc:     Conor Dooley <conor.dooley@...rochip.com>,
        linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
        Palmer Dabbelt <palmer@...belt.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Ben Dooks <ben.dooks@...ive.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        Emil Renner Berthing <emil.renner.berthing@...onical.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 6/7] riscv: dts: starfive: Add initial StarFive JH7110
 device tree

On Wed, Feb 15, 2023 at 07:42:32AM +0000, Conor Dooley wrote:
> Hey Hal!
> 
> On Wed, Feb 15, 2023 at 11:07:15AM +0800, Hal Feng wrote:
> > On Thu, 2 Feb 2023 19:41:33 +0000, Conor Dooley wrote:
> > > On Fri, Feb 03, 2023 at 02:56:41AM +0800, Hal Feng wrote:
> > >> On Wed, 1 Feb 2023 08:21:05 +0000, Conor Dooley wrote:
> > >> > On Wed, Feb 01, 2023 at 03:21:48PM +0800, Hal Feng wrote:
> > >> >> On Wed, 28 Dec 2022 22:48:43 +0000, Conor Dooley wrote:
> > >> >> > On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote:
> > >> > 
> > >> >> >> +/ {
> > >> >> >> +	compatible = "starfive,jh7110";
> > >> >> >> +	#address-cells = <2>;
> > >> >> >> +	#size-cells = <2>;
> > >> >> >> +
> > >> >> >> +	cpus {
> > >> >> >> +		#address-cells = <1>;
> > >> >> >> +		#size-cells = <0>;
> > >> >> >> +
> > >> >> >> +		S76_0: cpu@0 {
> > >> >> >> +			compatible = "sifive,u74-mc", "riscv";
> > >> >> > 
> > >> >> > The label here says S76 but the compatible says u74-mc.
> > >> >> 
> > >> >> U74-MC has 5 cores including 1 * S7 core and 4 * U74 cores.
> > >> >> 
> > >> >> > Which is correct? Your docs say S7 and S76, so I would imagine that it
> > >> >> > is actually an S76?
> > >> >> 
> > >> >> I found SiFive website [1] call it S76, but call it S7 in other places.
> > >> >> So I misunderstood this. Considering the ISA difference you described
> > >> >> as below, I think it's proper to change the label to "S7_0".
> > >> > 
> > >> > I'm less worried about the label & more interested in the compatible.
> > >> > hart0 is, as you say, not a u74. Should we not be adding a "sifive,s7"
> > >> > compatible string to Documentation/devicetree/bindings/riscv/cpus.yaml
> > >> > and using that here instead?
> > >> 
> > >> First of all, it's my fault that I didn't check the revision of U74-MC
> > >> manual, so most of my previous replies might not make sense.
> > > 
> > > No that's fine. The manual stuff confused me too when I went looking
> > > initially, and I still get get mixed up by the fact that there are
> > > core-complex manuals but not core manuals.
> > > 
> > >> If we add a new compatible string for S7, should we change the compatibles
> > >> of hart1~3 to "sifive,u74" also? And then, there may be no point keeping some
> > >> compatible strings of core complex like "sifive,u74-mc" and "sifive,u54-mc".
> > >> I'm not sure about this.
> > > 
> > > [...]
> > > 
> > >> >> Yes, "RV64IMAC" is correct. The monitor core in U74-MC is a
> > >> >> S7-series core, not S76.
> > >> > 
> > >> > Cool, thanks.
> > >> 
> > >> Now I think it might be another version of S76.
> > > 
> > > The SiFive docs describe the u74-mc core complex, which AFAIU you have,
> > > as being 1x S7 & 4x U7.
> > > 
> > > I'd be happy with new binding for "sifive,s7" & then we use that here.
> > > If you're sure it's S76, we can also use that. S76 is described, in what
> > > docs I can see, as a core complex containing an S7, so S7 seems likely
> > > to be correct?
> > 
> > I will add a new binding for "sifive,s7" and modify the code as follows.
> > 
> > 	S7_0: cpu@0 {
> > 		compatible = "sifive,s7", "riscv";
> > 		...
> > 		riscv,isa = "rv64imac_zicsr_zba_zbb";
> 
> I'm not sure that I'd bother with the zicsr, it gets added automagically
> by the Makefile if needed:

Meh, I probably shouldn't have replied to this first thing in the
morning as this comment of mine doesn't really make sense.
I skipped the middle part of my point here...
What I meant was that you can avoid zicsr & zifencei because when the
binding was defined they were included in i. I meant to use the
following as a kinda explanation of it depending on the version of the
ISA spec & that we just assume that zicsr & zifencei are present.
I suppose you can add them to the isa string if you like, dtbs_check
shouldn't complain!

> | # Newer binutils versions default to ISA spec version 20191213 which moves some
> | # instructions from the I extension to the Zicsr and Zifencei extensions.
> | toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei)
> | riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei
> 
> Otherwise, thanks for the actual confirmation of zba/zbb!
> 
> Thanks,
> Conor.
> 



Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)