[PATCH v3 14/17] riscv: dts: jh7110: Add initial StarFive JH7110 device tree

[Conor Dooley]

On Tue, Mar 07, 2023 at 06:30:19AM +0000, Conor Dooley wrote:
> 
> 
> On 7 March 2023 01:59:31 GMT, yanhong wang <yanhong.wang at starfivetech.com> wrote:
> >
> >
> >On 2023/3/4 5:16, Conor Dooley wrote:
> >> On Fri, Mar 03, 2023 at 11:24:29AM +0800, Yanhong Wang wrote:
> >>> Add initial device tree for the JH7110 RISC-V SoC.
> >>> 
> >>> Signed-off-by: Yanhong Wang <yanhong.wang at starfivetech.com>
> >>> ---
> >>>  arch/riscv/dts/jh7110.dtsi | 582 +++++++++++++++++++++++++++++++++++++
> >>>  1 file changed, 582 insertions(+)
> >>>  create mode 100644 arch/riscv/dts/jh7110.dtsi
> >>> 
> >>> diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
> >>> new file mode 100644
> >>> index 0000000000..d3e9f92987
> >>> --- /dev/null
> >>> +++ b/arch/riscv/dts/jh7110.dtsi
> >>> @@ -0,0 +1,582 @@
> >>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> >>> +/*
> >>> + * Copyright (C) 2022 StarFive Technology Co., Ltd.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +#include <dt-bindings/clock/starfive,jh7110-crg.h>
> >>> +#include <dt-bindings/reset/starfive,jh7110-crg.h>
> >>> +
> >>> +/ {
> >>> +	compatible = "starfive,jh7110";
> >>> +	#address-cells = <2>;
> >>> +	#size-cells = <2>;
> >>> +
> >>> +	cpus {
> >>> +		#address-cells = <1>;
> >>> +		#size-cells = <0>;
> >>> +
> >>> +		S7_0: cpu at 0 {
> >>> +			compatible = "sifive,s7", "riscv";
> >>> +			reg = <0>;
> >>> +			d-cache-block-size = <64>;
> >>> +			d-cache-sets = <64>;
> >>> +			d-cache-size = <8192>;
> >>> +			d-tlb-sets = <1>;
> >>> +			d-tlb-size = <40>;
> >>> +			device_type = "cpu";
> >>> +			i-cache-block-size = <64>;
> >>> +			i-cache-sets = <64>;
> >>> +			i-cache-size = <16384>;
> >>> +			i-tlb-sets = <1>;
> >>> +			i-tlb-size = <40>;
> >>> +			mmu-type = "riscv,sv39";
> >>> +			next-level-cache = <&ccache>;
> >>> +			riscv,isa = "rv64imac_zba_zbb";
> >> 
> >> Hmm, based on what Sean said on the previous version, "We use strchr on
> >> it; so something like Zicsr is parsed as 5 extensions", are you sure that
> >> adding this here behaves correctly?
> >> 
> >
> > As you said, u-boot does not parse the content after '_', zba/zbb has
> > no practical meaning in u-boot. 
> 
> That's not what Sean's comment on the previous version said.
> If it is actually ignored, this is fine, but Sean's comment read like
> it would be misinterpreted by U-Boot.
> I'll have to go read the code.

Having gone and found the code in question, it does indeed look like it
stops at an _, supports_extension() in arch/riscv/cpu/cpu.c, so having
Zba and Zbb in the riscv,isa string is fine.
Apologies for the noise here, I must've misunderstood the comments on
the previous version.

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230307/c8389ebe/attachment.sig>