[PATCH v3 0/7] riscv: add initial support for Canaan Kendryte K230

[PATCH v3 0/7] riscv: add initial support for Canaan Kendryte K230

[Yangyu Chen]

K230 is an ideal chip for RISC-V Vector 1.0 evaluation now. Add initial
support for it to allow more people to participate in building drivers
to mainline for it.

This kernel has been tested upon factory SDK [1] with
k230_evb_only_linux_defconfig and patched mainline opensbi [2] to skip
locked pmp and successfully booted to busybox on initrd with this log [3].

[1] https://github.com/kendryte/k230_sdk
[2] https://github.com/cyyself/opensbi/tree/k230
[3] https://gist.github.com/cyyself/b9445f38cc3ba1094924bd41c9086176

Changes since v2:
- Add MIT License to dts file
- Sort dt-binding stings in alphanumerical order
- Sort filename in dts Makefile in alphanumerical order
- Rename canmv-k230.dts to k230-canmv.dts

v2: https://lore.kernel.org/linux-riscv/tencent_64A9B4B31C2D70D5633042461AC9F80C0509@qq.com/

Changes since v1:
- Patch dt-bindings in clint and plic
- Use enum in K230 compatible dt bindings
- Fix dts to pass `make dtbs_check`
- Add more details in commit message

v1: https://lore.kernel.org/linux-riscv/tencent_E15F8FE0B6769E6338AE690C7F4844A31706@qq.com/

Yangyu Chen (7):
  dt-bindings: riscv: Add T-HEAD C908 compatible
  dt-bindings: add Canaan K230 boards compatible strings
  dt-bindings: timer: Add Canaan K230 CLINT
  dt-bindings: interrupt-controller: Add Canaan K230 PLIC
  riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230
  riscv: dts: add initial canmv-k230 and k230-evb dts
  riscv: config: enable SOC_CANAAN in defconfig

 .../sifive,plic-1.0.0.yaml                    |   1 +
 .../devicetree/bindings/riscv/canaan.yaml     |   8 +-
 .../devicetree/bindings/riscv/cpus.yaml       |   1 +
 .../bindings/timer/sifive,clint.yaml          |   1 +
 arch/riscv/Kconfig.socs                       |   5 +-
 arch/riscv/boot/dts/canaan/Makefile           |   2 +
 arch/riscv/boot/dts/canaan/k230-canmv.dts     |  24 +++
 arch/riscv/boot/dts/canaan/k230-evb.dts       |  24 +++
 arch/riscv/boot/dts/canaan/k230.dtsi          | 140 ++++++++++++++++++
 arch/riscv/configs/defconfig                  |   1 +
 10 files changed, 203 insertions(+), 4 deletions(-)
 create mode 100644 arch/riscv/boot/dts/canaan/k230-canmv.dts
 create mode 100644 arch/riscv/boot/dts/canaan/k230-evb.dts
 create mode 100644 arch/riscv/boot/dts/canaan/k230.dtsi

base-commit: 45e0b0fd6dc574101825ac2738b890da024e4cda
prerequisite-patch-id: 2374c56c0032e616e45854d2bc2bb1073996313d

Dependencies: https://lore.kernel.org/linux-riscv/tencent_88FEE0A2C5E0852436A2F1A1087E6803380A@qq.com/
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 1/7] dt-bindings: riscv: Add T-HEAD C908 compatible

[Yangyu Chen]

The thead,c908 is a RISC-V CPU core from T-HEAD Semiconductor which used
in Canaan Kendryte K230 SoC.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index 9d8670c00e3b..e853a7fcee8a 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -47,6 +47,7 @@ properties:
               - sifive,u74
               - sifive,u74-mc
               - thead,c906
+              - thead,c908
               - thead,c910
               - thead,c920
           - const: riscv
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 2/7] dt-bindings: add Canaan K230 boards compatible strings

[Yangyu Chen]

Since K230 was released, K210 is no longer the only SoC in the Kendryte
series, so remove the K210 string from the description. Also, add two
boards based on k230 to compatible strings to allow them to be used in the
dt.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 Documentation/devicetree/bindings/riscv/canaan.yaml | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Documentation/devicetree/bindings/riscv/canaan.yaml
index 41fd11f70a49..12a78bc95992 100644
--- a/Documentation/devicetree/bindings/riscv/canaan.yaml
+++ b/Documentation/devicetree/bindings/riscv/canaan.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Damien Le Moal <dlemoal@kernel.org>
 
 description:
-  Canaan Kendryte K210 SoC-based boards
+  Canaan Kendryte SoC-based boards
 
 properties:
   $nodename:
@@ -42,6 +42,12 @@ properties:
       - items:
           - const: canaan,kendryte-k210
 
+      - items:
+          - enum:
+              - canaan,k230-usip-lp3-evb
+              - canaan,canmv-k230
+          - const: canaan,kendryte-k230
+
 additionalProperties: true
 
 ...
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 2/7] dt-bindings: add Canaan K230 boards compatible strings

[Damien Le Moal]

On 3/5/24 06:05, Yangyu Chen wrote:
> Since K230 was released, K210 is no longer the only SoC in the Kendryte
> series, so remove the K210 string from the description. Also, add two
> boards based on k230 to compatible strings to allow them to be used in the
> dt.
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>

-- 
Damien Le Moal
Western Digital Research


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 3/7] dt-bindings: timer: Add Canaan K230 CLINT

[Yangyu Chen]

Add compatible string for Canaan K230 CLINT.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index fced6f2d8ecb..06c67f20ad3c 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -38,6 +38,7 @@ properties:
       - items:
           - enum:
               - allwinner,sun20i-d1-clint
+              - canaan,k230-clint
               - sophgo,cv1800b-clint
               - sophgo,cv1812h-clint
               - thead,th1520-clint
-- 
2.43.0



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 3/7] dt-bindings: timer: Add Canaan K230 CLINT

[Rob Herring]

On Tue, 05 Mar 2024 05:05:57 +0800, Yangyu Chen wrote:
> Add compatible string for Canaan K230 CLINT.
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 4/7] dt-bindings: interrupt-controller: Add Canaan K230 PLIC

[Yangyu Chen]

Add compatible string for Canaan K230 PLIC.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml         | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index 709b2211276b..122f9b7b3f52 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -65,6 +65,7 @@ properties:
       - items:
           - enum:
               - allwinner,sun20i-d1-plic
+              - canaan,k230-plic
               - sophgo,cv1800b-plic
               - sophgo,cv1812h-plic
               - sophgo,sg2042-plic
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 4/7] dt-bindings: interrupt-controller: Add Canaan K230 PLIC

[Rob Herring]

On Tue, 05 Mar 2024 05:05:58 +0800, Yangyu Chen wrote:
> Add compatible string for Canaan K230 PLIC.
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml         | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Yangyu Chen]

Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
Remove it depends on !MMU will allow building dts for K230 and remove the
K210 string from the help message.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/Kconfig.socs | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 623de5f8a208..b4e9b7f75510 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -75,13 +75,12 @@ config ARCH_CANAAN
 	def_bool SOC_CANAAN
 
 config SOC_CANAAN
-	bool "Canaan Kendryte K210 SoC"
-	depends on !MMU
+	bool "Canaan Kendryte SoC"
 	select CLINT_TIMER if RISCV_M_MODE
 	select ARCH_HAS_RESET_CONTROLLER
 	select PINCTRL
 	select COMMON_CLK
 	help
-	  This enables support for Canaan Kendryte K210 SoC platform hardware.
+	  This enables support for Canaan Kendryte SoC platform hardware.
 
 endmenu # "SoC selection"
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Damien Le Moal]

On 3/5/24 06:05, Yangyu Chen wrote:
> Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
> Remove it depends on !MMU will allow building dts for K230 and remove the
> K210 string from the help message.
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  arch/riscv/Kconfig.socs | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index 623de5f8a208..b4e9b7f75510 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>  	def_bool SOC_CANAAN
>  
>  config SOC_CANAAN
> -	bool "Canaan Kendryte K210 SoC"
> -	depends on !MMU

This seems wrong to me. The k210 support does require no-mmu. So why remove
this ? Does the k230 have MMU support ? If yes, then I do not think these 2 can
fall under the same SOC_CANAAN.

> +	bool "Canaan Kendryte SoC"
>  	select CLINT_TIMER if RISCV_M_MODE
>  	select ARCH_HAS_RESET_CONTROLLER
>  	select PINCTRL
>  	select COMMON_CLK
>  	help
> -	  This enables support for Canaan Kendryte K210 SoC platform hardware.
> +	  This enables support for Canaan Kendryte SoC platform hardware.
>  
>  endmenu # "SoC selection"

-- 
Damien Le Moal
Western Digital Research


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Yangyu Chen]

On 2024/3/5 07:46, Damien Le Moal wrote:
> On 3/5/24 06:05, Yangyu Chen wrote:
>> Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
>> Remove it depends on !MMU will allow building dts for K230 and remove the
>> K210 string from the help message.
>>
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>> ---
>>   arch/riscv/Kconfig.socs | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>> index 623de5f8a208..b4e9b7f75510 100644
>> --- a/arch/riscv/Kconfig.socs
>> +++ b/arch/riscv/Kconfig.socs
>> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>>   	def_bool SOC_CANAAN
>>   
>>   config SOC_CANAAN
>> -	bool "Canaan Kendryte K210 SoC"
>> -	depends on !MMU
> 
> This seems wrong to me. The k210 support does require no-mmu. So why remove
> this ?

It just allows SOC_CANAAN to be selected when MMU=y. With this patch, 
nommu_k210_defconfig still works.

> Does the k230 have MMU support ? If yes, then I do not think these 2 can
> fall under the same SOC_CANAAN.
> 

Yes, K230 has MMU, you can see the bootlog from the cover letter and the 
dts patch [6/7]. Could you provide some reasons why it can fall? I 
didn't see any differences in .config after this change after executing 
'make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- nommu_k210_defconfig'.

>> +	bool "Canaan Kendryte SoC"
>>   	select CLINT_TIMER if RISCV_M_MODE
>>   	select ARCH_HAS_RESET_CONTROLLER
>>   	select PINCTRL
>>   	select COMMON_CLK
>>   	help
>> -	  This enables support for Canaan Kendryte K210 SoC platform hardware.
>> +	  This enables support for Canaan Kendryte SoC platform hardware.
>>   
>>   endmenu # "SoC selection"
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2315 bytes --]

On Tue, Mar 05, 2024 at 03:47:15PM +0800, Yangyu Chen wrote:
> On 2024/3/5 07:46, Damien Le Moal wrote:
> > On 3/5/24 06:05, Yangyu Chen wrote:
> > > Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
> > > Remove it depends on !MMU will allow building dts for K230 and remove the
> > > K210 string from the help message.
> > > 
> > > Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > ---
> > >   arch/riscv/Kconfig.socs | 5 ++---
> > >   1 file changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> > > index 623de5f8a208..b4e9b7f75510 100644
> > > --- a/arch/riscv/Kconfig.socs
> > > +++ b/arch/riscv/Kconfig.socs
> > > @@ -75,13 +75,12 @@ config ARCH_CANAAN
> > >   	def_bool SOC_CANAAN
> > >   config SOC_CANAAN
> > > -	bool "Canaan Kendryte K210 SoC"
> > > -	depends on !MMU
> > 
> > This seems wrong to me. The k210 support does require no-mmu. So why remove
> > this ?
> 
> It just allows SOC_CANAAN to be selected when MMU=y. With this patch,
> nommu_k210_defconfig still works.

I think the concern here is that this would allow people to build a
kernel for the k120 with the MMU enabled, not that the existing nommu
build will be affected.

Maybe you could squash in something like the following?

diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index b4e9b7f75510..75d55059163f 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -72,15 +72,19 @@ config SOC_VIRT
 	  This enables support for QEMU Virt Machine.
 
 config ARCH_CANAAN
-	def_bool SOC_CANAAN
+	bool "Canaan Kendryte SoCs"
+	help
+	  This enables support for Canaan Kendryte SoC platform hardware.
 
 config SOC_CANAAN
-	bool "Canaan Kendryte SoC"
+	bool "Canaan Kendryte K210 SoC"
+	depends on !MMU
+	depends on ARCH_CANAAN
 	select CLINT_TIMER if RISCV_M_MODE
 	select ARCH_HAS_RESET_CONTROLLER
 	select PINCTRL
 	select COMMON_CLK
 	help
-	  This enables support for Canaan Kendryte SoC platform hardware.
+	  This enables support for Canaan Kendryte K210 SoC platform hardware.
 
 endmenu # "SoC selection"

(Which reminds me, I really need to go and finish sorting out the ARCH_
stuff)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Resend: Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Yangyu Chen]

The last email was not received in the list due to I didn’t change the mode
to plaintext. Sorry for that. This is a resend email.

> On Mar 6, 2024, at 01:20, Conor Dooley <conor@kernel.org> wrote:
> 
> On Tue, Mar 05, 2024 at 03:47:15PM +0800, Yangyu Chen wrote:
>> On 2024/3/5 07:46, Damien Le Moal wrote:
>>> On 3/5/24 06:05, Yangyu Chen wrote:
>>>> Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
>>>> Remove it depends on !MMU will allow building dts for K230 and remove the
>>>> K210 string from the help message.
>>>> 
>>>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>>>> ---
>>>>  arch/riscv/Kconfig.socs | 5 ++---
>>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>> 
>>>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>>>> index 623de5f8a208..b4e9b7f75510 100644
>>>> --- a/arch/riscv/Kconfig.socs
>>>> +++ b/arch/riscv/Kconfig.socs
>>>> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>>>>   def_bool SOC_CANAAN
>>>>  config SOC_CANAAN
>>>> - bool "Canaan Kendryte K210 SoC"
>>>> - depends on !MMU
>>> 
>>> This seems wrong to me. The k210 support does require no-mmu. So why remove
>>> this ?
>> 
>> It just allows SOC_CANAAN to be selected when MMU=y. With this patch,
>> nommu_k210_defconfig still works.
> 
> I think the concern here is that this would allow people to build a
> kernel for the k120 with the MMU enabled, not that the existing nommu
> build will be affected.
> 

Aha. I don't think is there anyone will try a build with MMU on
K210. It only has 6MB of memory available to the CPU. For rv64 if
the S-Mode software starts at 2MB, it will only have 4MB for S-Mode
Linux. It's hard to trim the kernel and fit in 4MB and even preserve
some memory for userspace.

I also tried to make nommu_k210_defconfig on gcc 13.2.0, it produced a
1.6M kernel in arch/riscv/boot/Image. But if I use nconfig to set
CONFIG_MMU=y and rebuild, the kernel file will increase to 11M.

> Maybe you could squash in something like the following?
> 
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index b4e9b7f75510..75d55059163f 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -72,15 +72,19 @@ config SOC_VIRT
>   This enables support for QEMU Virt Machine.
> 
> config ARCH_CANAAN
> - def_bool SOC_CANAAN
> + bool "Canaan Kendryte SoCs"
> + help
> +   This enables support for Canaan Kendryte SoC platform hardware.
> 
> config SOC_CANAAN
> - bool "Canaan Kendryte SoC"
> + bool "Canaan Kendryte K210 SoC"
> + depends on !MMU
> + depends on ARCH_CANAAN
> select CLINT_TIMER if RISCV_M_MODE
> select ARCH_HAS_RESET_CONTROLLER
> select PINCTRL
> select COMMON_CLK
> help
> -   This enables support for Canaan Kendryte SoC platform hardware.
> +   This enables support for Canaan Kendryte K210 SoC platform hardware.
> 
> endmenu # "SoC selection"
> 
> (Which reminds me, I really need to go and finish sorting out the ARCH_
> stuff)

Seems like an idea if we want this consideration. But I don't think we need
this as the opinions shown above.

If it should be, I think SOC_CANAAN should be renamed to SOC_K210 or
SOC_CANAAN_K210.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Resend: Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Yangyu Chen]

> On Mar 6, 2024, at 01:50, Yangyu Chen <cyy@cyyself.name> wrote:
> 
> The last email was not received in the list due to I didn’t change the mode
> to plaintext. Sorry for that. This is a resend email.
> 
>> On Mar 6, 2024, at 01:20, Conor Dooley <conor@kernel.org> wrote:
>> 
>> On Tue, Mar 05, 2024 at 03:47:15PM +0800, Yangyu Chen wrote:
>>> On 2024/3/5 07:46, Damien Le Moal wrote:
>>>> On 3/5/24 06:05, Yangyu Chen wrote:
>>>>> Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
>>>>> Remove it depends on !MMU will allow building dts for K230 and remove the
>>>>> K210 string from the help message.
>>>>> 
>>>>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>>>>> ---
>>>>> arch/riscv/Kconfig.socs | 5 ++---
>>>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>>> 
>>>>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>>>>> index 623de5f8a208..b4e9b7f75510 100644
>>>>> --- a/arch/riscv/Kconfig.socs
>>>>> +++ b/arch/riscv/Kconfig.socs
>>>>> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>>>>>  def_bool SOC_CANAAN
>>>>> config SOC_CANAAN
>>>>> - bool "Canaan Kendryte K210 SoC"
>>>>> - depends on !MMU
>>>> 
>>>> This seems wrong to me. The k210 support does require no-mmu. So why remove
>>>> this ?
>>> 
>>> It just allows SOC_CANAAN to be selected when MMU=y. With this patch,
>>> nommu_k210_defconfig still works.
>> 
>> I think the concern here is that this would allow people to build a
>> kernel for the k120 with the MMU enabled, not that the existing nommu
>> build will be affected.
>> 
> 
> Aha. I don't think is there anyone will try a build with MMU on
> K210. It only has 6MB of memory available to the CPU. For rv64 if
> the S-Mode software starts at 2MB, it will only have 4MB for S-Mode
> Linux. It's hard to trim the kernel and fit in 4MB and even preserve
> some memory for userspace.
> 
> I also tried to make nommu_k210_defconfig on gcc 13.2.0, it produced a
> 1.6M kernel in arch/riscv/boot/Image. But if I use nconfig to set
> CONFIG_MMU=y and rebuild, the kernel file will increase to 11M.
> 

Another interesting finding is that the root cause of the huge kernel is
because CONFIG_STRICT_KERNEL_RWX. If we turn it off, the size will
reduced to 1.9M. Not so much for userspace but seems ok to boot.

That is because we defined SECTION_ALIGN to 2MB to fit with one PMD on
rv64 to reduce the miss of TLB. However, it increased the kernel size.

Link: https://lore.kernel.org/linux-riscv/d78c601d553dde791057b54252064221f960546e.1586332296.git.zong.li@sifive.com/

I know MMU on K210 is not standard as now. 

Maybe I should care about that. I will fix this for patch v4.

>> Maybe you could squash in something like the following?
>> 
>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>> index b4e9b7f75510..75d55059163f 100644
>> --- a/arch/riscv/Kconfig.socs
>> +++ b/arch/riscv/Kconfig.socs
>> @@ -72,15 +72,19 @@ config SOC_VIRT
>>  This enables support for QEMU Virt Machine.
>> 
>> config ARCH_CANAAN
>> - def_bool SOC_CANAAN
>> + bool "Canaan Kendryte SoCs"
>> + help
>> +   This enables support for Canaan Kendryte SoC platform hardware.
>> 
>> config SOC_CANAAN
>> - bool "Canaan Kendryte SoC"
>> + bool "Canaan Kendryte K210 SoC"
>> + depends on !MMU
>> + depends on ARCH_CANAAN
>> select CLINT_TIMER if RISCV_M_MODE
>> select ARCH_HAS_RESET_CONTROLLER
>> select PINCTRL
>> select COMMON_CLK
>> help
>> -   This enables support for Canaan Kendryte SoC platform hardware.
>> +   This enables support for Canaan Kendryte K210 SoC platform hardware.
>> 
>> endmenu # "SoC selection"
>> 
>> (Which reminds me, I really need to go and finish sorting out the ARCH_
>> stuff)
> 
> Seems like an idea if we want this consideration. But I don't think we need
> this as the opinions shown above.
> 
> If it should be, I think SOC_CANAAN should be renamed to SOC_K210 or
> SOC_CANAAN_K210.
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Damien Le Moal]

On 3/6/24 02:20, Conor Dooley wrote:
> On Tue, Mar 05, 2024 at 03:47:15PM +0800, Yangyu Chen wrote:
>> On 2024/3/5 07:46, Damien Le Moal wrote:
>>> On 3/5/24 06:05, Yangyu Chen wrote:
>>>> Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
>>>> Remove it depends on !MMU will allow building dts for K230 and remove the
>>>> K210 string from the help message.
>>>>
>>>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>>>> ---
>>>>   arch/riscv/Kconfig.socs | 5 ++---
>>>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>>>> index 623de5f8a208..b4e9b7f75510 100644
>>>> --- a/arch/riscv/Kconfig.socs
>>>> +++ b/arch/riscv/Kconfig.socs
>>>> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>>>>   	def_bool SOC_CANAAN
>>>>   config SOC_CANAAN
>>>> -	bool "Canaan Kendryte K210 SoC"
>>>> -	depends on !MMU
>>>
>>> This seems wrong to me. The k210 support does require no-mmu. So why remove
>>> this ?
>>
>> It just allows SOC_CANAAN to be selected when MMU=y. With this patch,
>> nommu_k210_defconfig still works.
> 
> I think the concern here is that this would allow people to build a
> kernel for the k120 with the MMU enabled, not that the existing nommu
> build will be affected.

Yes, this is my concern. Apologies for the lack of clarity.

> 
> Maybe you could squash in something like the following?
> 
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index b4e9b7f75510..75d55059163f 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -72,15 +72,19 @@ config SOC_VIRT
>  	  This enables support for QEMU Virt Machine.
>  
>  config ARCH_CANAAN
> -	def_bool SOC_CANAAN
> +	bool "Canaan Kendryte SoCs"
> +	help
> +	  This enables support for Canaan Kendryte SoC platform hardware.
>  
>  config SOC_CANAAN
> -	bool "Canaan Kendryte SoC"
> +	bool "Canaan Kendryte K210 SoC"
> +	depends on !MMU
> +	depends on ARCH_CANAAN
>  	select CLINT_TIMER if RISCV_M_MODE
>  	select ARCH_HAS_RESET_CONTROLLER
>  	select PINCTRL
>  	select COMMON_CLK
>  	help
> -	  This enables support for Canaan Kendryte SoC platform hardware.
> +	  This enables support for Canaan Kendryte K210 SoC platform hardware.
>  
>  endmenu # "SoC selection"
> 
> (Which reminds me, I really need to go and finish sorting out the ARCH_
> stuff)

-- 
Damien Le Moal
Western Digital Research


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Yangyu Chen]

> On Mar 6, 2024, at 07:58, Damien Le Moal <dlemoal@kernel.org> wrote:
> 
> On 3/6/24 02:20, Conor Dooley wrote:
>> On Tue, Mar 05, 2024 at 03:47:15PM +0800, Yangyu Chen wrote:
>>> On 2024/3/5 07:46, Damien Le Moal wrote:
>>>> On 3/5/24 06:05, Yangyu Chen wrote:
>>>>> Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
>>>>> Remove it depends on !MMU will allow building dts for K230 and remove the
>>>>> K210 string from the help message.
>>>>> 
>>>>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>>>>> ---
>>>>>  arch/riscv/Kconfig.socs | 5 ++---
>>>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>>> 
>>>>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>>>>> index 623de5f8a208..b4e9b7f75510 100644
>>>>> --- a/arch/riscv/Kconfig.socs
>>>>> +++ b/arch/riscv/Kconfig.socs
>>>>> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>>>>>   def_bool SOC_CANAAN
>>>>>  config SOC_CANAAN
>>>>> - bool "Canaan Kendryte K210 SoC"
>>>>> - depends on !MMU
>>>> 
>>>> This seems wrong to me. The k210 support does require no-mmu. So why remove
>>>> this ?
>>> 
>>> It just allows SOC_CANAAN to be selected when MMU=y. With this patch,
>>> nommu_k210_defconfig still works.
>> 
>> I think the concern here is that this would allow people to build a
>> kernel for the k120 with the MMU enabled, not that the existing nommu
>> build will be affected.
> 
> Yes, this is my concern. Apologies for the lack of clarity.
> 

Hi,

Thanks for the review comments. After thinking about it for a while,
I think we don't need to change it as we have changed the help
message which deleted the "K210". And the dts on k210.dtsi shows
mmu-type is riscv.none, I think if someone noticed this would know
why it fails to boot on the S-Mode MMU Kernel on K210. The only
special thing for ARCH_CANAAN is that a loader.bin will be built
when M-Mode is on arch/riscv/Makefile. However, Canaan has no other
M-Mode chips except for K210. So I think we don't need to change
it.

Another reason is that SOC_CANAAN for K210 is somehow hard to change.
If we continue using SOC_CANAAN for K210 but not for other Canaan
SoCs such as K230, it will cause some confusion to users. If we
rename SOC_CANAAN to SOC_CANAAN_K210, it will change many drivers
in many subsystems like my patch v5 [1]. So I don't think we need
to fix it.


If we don't change it, A concern for this is that some drivers for
K210 will be built when SOC_CANAAN=y and if we add this to defconfig,
all riscv builds will also build some K210 drivers even on MMU. But
I think this will not be a problem just need some memory/storage
for a slightly bigger kernel. Also, we will enable some new configs
in defconfig when a new soc gets supported, it's normal for K210
SoC drivers.

Thus, I think we don't need to change it. If you have some other
opinions, please let me know.

[1] https://lore.kernel.org/linux-riscv/tencent_6F35FEF31908DE6AEB385AE30AC658863C0A@qq.com/

Thanks,
Yangyu Chen

>> 
>> Maybe you could squash in something like the following?
>> 
>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>> index b4e9b7f75510..75d55059163f 100644
>> --- a/arch/riscv/Kconfig.socs
>> +++ b/arch/riscv/Kconfig.socs
>> @@ -72,15 +72,19 @@ config SOC_VIRT
>>   This enables support for QEMU Virt Machine.
>> 
>> config ARCH_CANAAN
>> - def_bool SOC_CANAAN
>> + bool "Canaan Kendryte SoCs"
>> + help
>> +   This enables support for Canaan Kendryte SoC platform hardware.
>> 
>> config SOC_CANAAN
>> - bool "Canaan Kendryte SoC"
>> + bool "Canaan Kendryte K210 SoC"
>> + depends on !MMU
>> + depends on ARCH_CANAAN
>> select CLINT_TIMER if RISCV_M_MODE
>> select ARCH_HAS_RESET_CONTROLLER
>> select PINCTRL
>> select COMMON_CLK
>> help
>> -   This enables support for Canaan Kendryte SoC platform hardware.
>> +   This enables support for Canaan Kendryte K210 SoC platform hardware.
>> 
>> endmenu # "SoC selection"
>> 
>> (Which reminds me, I really need to go and finish sorting out the ARCH_
>> stuff)
> 
> -- 
> Damien Le Moal
> Western Digital Research



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Yangyu Chen]

On 2024/3/8 05:03, Yangyu Chen wrote:
> 
> 
>> On Mar 6, 2024, at 07:58, Damien Le Moal <dlemoal@kernel.org> wrote:
>>
>> On 3/6/24 02:20, Conor Dooley wrote:
>>> On Tue, Mar 05, 2024 at 03:47:15PM +0800, Yangyu Chen wrote:
>>>> On 2024/3/5 07:46, Damien Le Moal wrote:
>>>>> On 3/5/24 06:05, Yangyu Chen wrote:
>>>>>> Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
>>>>>> Remove it depends on !MMU will allow building dts for K230 and remove the
>>>>>> K210 string from the help message.
>>>>>>
>>>>>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>>>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>>>>>> ---
>>>>>>   arch/riscv/Kconfig.socs | 5 ++---
>>>>>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>>>>>> index 623de5f8a208..b4e9b7f75510 100644
>>>>>> --- a/arch/riscv/Kconfig.socs
>>>>>> +++ b/arch/riscv/Kconfig.socs
>>>>>> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>>>>>>    def_bool SOC_CANAAN
>>>>>>   config SOC_CANAAN
>>>>>> - bool "Canaan Kendryte K210 SoC"
>>>>>> - depends on !MMU
>>>>>
>>>>> This seems wrong to me. The k210 support does require no-mmu. So why remove
>>>>> this ?
>>>>
>>>> It just allows SOC_CANAAN to be selected when MMU=y. With this patch,
>>>> nommu_k210_defconfig still works.
>>>
>>> I think the concern here is that this would allow people to build a
>>> kernel for the k120 with the MMU enabled, not that the existing nommu
>>> build will be affected.
>>
>> Yes, this is my concern. Apologies for the lack of clarity.
>>
> 
> Hi,
> 
> Thanks for the review comments. After thinking about it for a while,
> I think we don't need to change it as we have changed the help
> message which deleted the "K210". And the dts on k210.dtsi shows
> mmu-type is riscv.none, I think if someone noticed this would know
> why it fails to boot on the S-Mode MMU Kernel on K210. The only
> special thing for ARCH_CANAAN is that a loader.bin will be built
> when M-Mode is on arch/riscv/Makefile. However, Canaan has no other
> M-Mode chips except for K210. So I think we don't need to change
> it.
> 
> Another reason is that SOC_CANAAN for K210 is somehow hard to change.
> If we continue using SOC_CANAAN for K210 but not for other Canaan
> SoCs such as K230, it will cause some confusion to users. If we
> rename SOC_CANAAN to SOC_CANAAN_K210, it will change many drivers
> in many subsystems like my patch v5 [1]. So I don't think we need
> to fix it.
> 
> 
> If we don't change it, A concern for this is that some drivers for
> K210 will be built when SOC_CANAAN=y and if we add this to defconfig,
> all riscv builds will also build some K210 drivers even on MMU. But
> I think this will not be a problem just need some memory/storage
> for a slightly bigger kernel. Also, we will enable some new configs
> in defconfig when a new soc gets supported, it's normal for K210
> SoC drivers.
> 
> Thus, I think we don't need to change it. If you have some other
> opinions, please let me know.
> 
> [1] https://lore.kernel.org/linux-riscv/tencent_6F35FEF31908DE6AEB385AE30AC658863C0A@qq.com/
> 
> Thanks,
> Yangyu Chen
> 

Hi Damien,

I'm waiting for your decision before sending the next patch revision.
Please reply to this when you are free.

Thanks,
Yangyu Chen

>>>
>>> Maybe you could squash in something like the following?
>>>
>>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>>> index b4e9b7f75510..75d55059163f 100644
>>> --- a/arch/riscv/Kconfig.socs
>>> +++ b/arch/riscv/Kconfig.socs
>>> @@ -72,15 +72,19 @@ config SOC_VIRT
>>>    This enables support for QEMU Virt Machine.
>>>
>>> config ARCH_CANAAN
>>> - def_bool SOC_CANAAN
>>> + bool "Canaan Kendryte SoCs"
>>> + help
>>> +   This enables support for Canaan Kendryte SoC platform hardware.
>>>
>>> config SOC_CANAAN
>>> - bool "Canaan Kendryte SoC"
>>> + bool "Canaan Kendryte K210 SoC"
>>> + depends on !MMU
>>> + depends on ARCH_CANAAN
>>> select CLINT_TIMER if RISCV_M_MODE
>>> select ARCH_HAS_RESET_CONTROLLER
>>> select PINCTRL
>>> select COMMON_CLK
>>> help
>>> -   This enables support for Canaan Kendryte SoC platform hardware.
>>> +   This enables support for Canaan Kendryte K210 SoC platform hardware.
>>>
>>> endmenu # "SoC selection"
>>>
>>> (Which reminds me, I really need to go and finish sorting out the ARCH_
>>> stuff)
>>
>> -- 
>> Damien Le Moal
>> Western Digital Research
> 
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with MMU for K230

[Damien Le Moal]

On 3/14/24 01:56, Yangyu Chen wrote:
>> Hi,
>>
>> Thanks for the review comments. After thinking about it for a while,
>> I think we don't need to change it as we have changed the help
>> message which deleted the "K210". And the dts on k210.dtsi shows
>> mmu-type is riscv.none, I think if someone noticed this would know
>> why it fails to boot on the S-Mode MMU Kernel on K210. The only
>> special thing for ARCH_CANAAN is that a loader.bin will be built
>> when M-Mode is on arch/riscv/Makefile. However, Canaan has no other
>> M-Mode chips except for K210. So I think we don't need to change
>> it.

You completely lost me here. I do not understand what you are trying to say.

>> Another reason is that SOC_CANAAN for K210 is somehow hard to change.
>> If we continue using SOC_CANAAN for K210 but not for other Canaan
>> SoCs such as K230, it will cause some confusion to users. If we
>> rename SOC_CANAAN to SOC_CANAAN_K210, it will change many drivers
>> in many subsystems like my patch v5 [1]. So I don't think we need
>> to fix it.
>>
>>
>> If we don't change it, A concern for this is that some drivers for
>> K210 will be built when SOC_CANAAN=y and if we add this to defconfig,
>> all riscv builds will also build some K210 drivers even on MMU. But
>> I think this will not be a problem just need some memory/storage
>> for a slightly bigger kernel. Also, we will enable some new configs
>> in defconfig when a new soc gets supported, it's normal for K210
>> SoC drivers.
>>
>> Thus, I think we don't need to change it. If you have some other
>> opinions, please let me know.

1) Rename SOC_CANAAN to SOC_CANAAN_K210 and use that for any conditional code or
driver selection that is specific to the K210, which is what's done now.
2) Create a "new" SOC_CANAAN config and make SOC_CANAAN_K210 depend on it and on
!MMU

You could also add SOC_CANAAN_K230 if needed and make it depend on SOC_CANAAN &&
MMU.

With that, dirvers common to both the K210 and K230 can easilly be selected and
selecting SOC_CANAAN will end up either building for the K230 or the K210,
depending on MMU being set or not.

That's my 2 cents. Feel free to ignore. I am not involved that much with riscv
these days and I am far too busy with other kernel areas to be of any help. But
I really think that allowing building the K210 when MMU is enabled and "hoping
that the user understand his mistake" is not a great approach.

-- 
Damien Le Moal
Western Digital Research


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 6/7] riscv: dts: add initial canmv-k230 and k230-evb dts

[Yangyu Chen]

Add initial dts for CanMV-K230 and K230-EVB powered by Canaan Kendryte
K230 SoC [1].

Some key consideration:
- Only place BigCore which is 1.6GHz RV64GCBV

The existence of cache coherence between the two cores remains unknown
since they have dedicated L2 caches. And the factory SDK uses it for
other OS by default. I don't know whether the two CPUs on K230 SoC
can be used in one system. So only place BigCore here.

Meanwhile, although docs from Canaan said 1.6GHz Core with Vector is
CPU1, the csr.mhartid of this core is 0.

- Support for "zba" "zbb" "zbc" "zbs" are tested by hand

The user manual of C908 from T-Head does not document it specifically.
It just said it supports B extension V1.0-rc1. [2]

I have tested it by using this [3] which attempts to execute "add.uw",
"andn", "clmulr", "bclr" and they doesn't traps on K230. But on JH7110,
"clmulr" and "bclr" will trap.

- Support for "zicbom" is tested by hand

Have tested with some out-of-tree drivers from [4] that need DMA and they
do not come to the dts currently.

- Cache parameters are inferred from T-Head docs [2] and Canaan docs [1]

L1i: 32KB, VIPT 4-Way set-associative, 64B Cacheline
L1d: 32KB, VIPT 4-Way set-associative, 64B Cacheline
L2: 256KB, PIPT 16-way set-associative, 64B Cacheline

The numbers of cache sets are calculated from these parameters.

- MMU only supports Sv39

Since T-Head docs [2] say C908 should support Sv48. However, it will fail
during the kernel probe when running Linux on K230. I also tested it by
hand on M-Mode software, writing Sv48 to satp.mode will not trap but will
leave the csr unchanged. While writing Sv39 it will take effect. It shows
that this CPU does not support Sv48.

- Svpbmt and T-Head MAEE both supported

T-Head C908 does support both Svpbmt and T-Head MAEE for page-based memory
attributes and is controlled by csr.mxstatus. If the kernel wants to use
svpbmt, the m-mode software should set BIT(21) of csr.mxstatus to zero
before entering the s-mode kernel. Otherwise, the kernel will not boot as 0
on T-Head MAEE represent to NonCachable Memory and it will lose dirty cache
lines modification that haven't been written back to the memory.

[1] https://developer.canaan-creative.com/k230/dev/zh/00_hardware/K230_datasheet.html#chapter-1-introduction
[2] https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resource//1699268369347/XuanTie-C908-UserManual.pdf
[3] https://github.com/cyyself/rvb_test
[4] https://github.com/cyyself/linux/tree/k230-mainline

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 arch/riscv/boot/dts/canaan/Makefile       |   2 +
 arch/riscv/boot/dts/canaan/k230-canmv.dts |  24 ++++
 arch/riscv/boot/dts/canaan/k230-evb.dts   |  24 ++++
 arch/riscv/boot/dts/canaan/k230.dtsi      | 140 ++++++++++++++++++++++
 4 files changed, 190 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/k230-canmv.dts
 create mode 100644 arch/riscv/boot/dts/canaan/k230-evb.dts
 create mode 100644 arch/riscv/boot/dts/canaan/k230.dtsi

diff --git a/arch/riscv/boot/dts/canaan/Makefile b/arch/riscv/boot/dts/canaan/Makefile
index 987d1f0c41f0..7d54ea5c6f3d 100644
--- a/arch/riscv/boot/dts/canaan/Makefile
+++ b/arch/riscv/boot/dts/canaan/Makefile
@@ -1,6 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_CANAAN) += canaan_kd233.dtb
 dtb-$(CONFIG_ARCH_CANAAN) += k210_generic.dtb
+dtb-$(CONFIG_ARCH_CANAAN) += k230-canmv.dtb
+dtb-$(CONFIG_ARCH_CANAAN) += k230-evb.dtb
 dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_bit.dtb
 dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_dock.dtb
 dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_go.dtb
diff --git a/arch/riscv/boot/dts/canaan/k230-canmv.dts b/arch/riscv/boot/dts/canaan/k230-canmv.dts
new file mode 100644
index 000000000000..3ab5c8de11a8
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/k230-canmv.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
+ */
+
+#include "k230.dtsi"
+
+/ {
+	model = "Canaan CanMV-K230";
+	compatible = "canaan,canmv-k230", "canaan,kendryte-k230";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	ddr: memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x1fdff000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/riscv/boot/dts/canaan/k230-evb.dts b/arch/riscv/boot/dts/canaan/k230-evb.dts
new file mode 100644
index 000000000000..42720113c566
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/k230-evb.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
+ */
+
+#include "k230.dtsi"
+
+/ {
+	model = "Kendryte K230 EVB";
+	compatible = "canaan,k230-usip-lp3-evb", "canaan,kendryte-k230";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	ddr: memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x1fdff000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/riscv/boot/dts/canaan/k230.dtsi b/arch/riscv/boot/dts/canaan/k230.dtsi
new file mode 100644
index 000000000000..0bcff67b78a8
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/k230.dtsi
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/dts-v1/;
+/ {
+	#address-cells = <2>;
+	#size-cells = <2>;
+	compatible = "canaan,kendryte-k230";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		timebase-frequency = <27000000>;
+
+		cpu@0 {
+			compatible = "thead,c908", "riscv";
+			device_type = "cpu";
+			reg = <0>;
+			riscv,isa = "rv64imafdcv_zba_zbb_zbc_zbs_zicbom_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zba", "zbb",
+					       "zbc", "zbs", "zicbom", "zicntr", "zicsr",
+					       "zifencei", "zihpm", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <128>;
+			d-cache-size = <32768>;
+			i-cache-block-size = <64>;
+			i-cache-sets = <128>;
+			i-cache-size = <32768>;
+			next-level-cache = <&l2_cache>;
+			mmu-type = "riscv,sv39";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+		l2_cache: l2-cache {
+			compatible = "cache";
+			cache-block-size = <64>;
+			cache-level = <2>;
+			cache-size = <262144>;
+			cache-sets = <256>;
+			cache-unified;
+		};
+	};
+
+	apb_clk: apb-clk-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <50000000>;
+		clock-output-names = "apb_clk";
+		#clock-cells = <0>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		interrupt-parent = <&plic>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		dma-noncoherent;
+		ranges;
+
+		plic: interrupt-controller@f00000000 {
+			compatible = "canaan,k230-plic" ,"thead,c900-plic";
+			reg = <0xf 0x00000000 0x0 0x04000000>;
+			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <2>;
+			riscv,ndev = <208>;
+		};
+
+		clint: timer@f04000000 {
+			compatible = "canaan,k230-clint", "thead,c900-clint";
+			reg = <0xf 0x04000000 0x0 0x04000000>;
+			interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>;
+		};
+
+		uart0: serial@91400000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x0 0x91400000 0x0 0x1000>;
+			clocks = <&apb_clk>;
+			interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
+			reg-io-width = <4>;
+			reg-shift = <2>;
+			status = "disabled";
+		};
+
+		uart1: serial@91401000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x0 0x91401000 0x0 0x1000>;
+			clocks = <&apb_clk>;
+			interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
+			reg-io-width = <4>;
+			reg-shift = <2>;
+			status = "disabled";
+		};
+
+		uart2: serial@91402000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x0 0x91402000 0x0 0x1000>;
+			clocks = <&apb_clk>;
+			interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
+			reg-io-width = <4>;
+			reg-shift = <2>;
+			status = "disabled";
+		};
+
+		uart3: serial@91403000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x0 0x91403000 0x0 0x1000>;
+			clocks = <&apb_clk>;
+			interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
+			reg-io-width = <4>;
+			reg-shift = <2>;
+			status = "disabled";
+		};
+
+		uart4: serial@91404000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x0 0x91404000 0x0 0x1000>;
+			clocks = <&apb_clk>;
+			interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+			reg-io-width = <4>;
+			reg-shift = <2>;
+			status = "disabled";
+		};
+	};
+};
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 6/7] riscv: dts: add initial canmv-k230 and k230-evb dts

[Palmer Dabbelt]

On Mon, 04 Mar 2024 13:06:00 PST (-0800), cyy@cyyself.name wrote:
> Add initial dts for CanMV-K230 and K230-EVB powered by Canaan Kendryte
> K230 SoC [1].
>
> Some key consideration:
> - Only place BigCore which is 1.6GHz RV64GCBV
>
> The existence of cache coherence between the two cores remains unknown
> since they have dedicated L2 caches. And the factory SDK uses it for
> other OS by default. I don't know whether the two CPUs on K230 SoC
> can be used in one system. So only place BigCore here.
>
> Meanwhile, although docs from Canaan said 1.6GHz Core with Vector is
> CPU1, the csr.mhartid of this core is 0.
>
> - Support for "zba" "zbb" "zbc" "zbs" are tested by hand
>
> The user manual of C908 from T-Head does not document it specifically.
> It just said it supports B extension V1.0-rc1. [2]

I'm seeing

    3.1.6 Vector instruction set (RVV)
    For more information, see RISC-V “V”Vector Extension, Version 
    1.0-rc1-20210608
    URL：https://github.com/riscv/riscv-v-spec/releases/download/v1.0-rc1/riscv-v-spec-1.0-rc1.pdf

    3.1.7 Bit operation instruction set (RV64B)
    For more information, see ：RISC-V Bit-Manipulation ISA-extensions, 
    Version 1.0.0, 2021-06-12: public review
    URL：https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0.pdf

so I think maybe that's vector 1.0-rc1 and the final bitmanip?

> I have tested it by using this [3] which attempts to execute "add.uw",
> "andn", "clmulr", "bclr" and they doesn't traps on K230. But on JH7110,
> "clmulr" and "bclr" will trap.
>
> - Support for "zicbom" is tested by hand
>
> Have tested with some out-of-tree drivers from [4] that need DMA and they
> do not come to the dts currently.
>
> - Cache parameters are inferred from T-Head docs [2] and Canaan docs [1]
>
> L1i: 32KB, VIPT 4-Way set-associative, 64B Cacheline
> L1d: 32KB, VIPT 4-Way set-associative, 64B Cacheline
> L2: 256KB, PIPT 16-way set-associative, 64B Cacheline
>
> The numbers of cache sets are calculated from these parameters.
>
> - MMU only supports Sv39
>
> Since T-Head docs [2] say C908 should support Sv48. However, it will fail
> during the kernel probe when running Linux on K230. I also tested it by
> hand on M-Mode software, writing Sv48 to satp.mode will not trap but will
> leave the csr unchanged. While writing Sv39 it will take effect. It shows
> that this CPU does not support Sv48.

I think that only works due to a bug in our sv48 probing routines -- 
unless I'm missing something, we mixed up the sv57 and sv48 probing and 
if sv57 fails to probe then we disable sv48 as well.  So I think we 
probably need some cleanup in there.

> - Svpbmt and T-Head MAEE both supported
>
> T-Head C908 does support both Svpbmt and T-Head MAEE for page-based memory
> attributes and is controlled by csr.mxstatus. If the kernel wants to use
> svpbmt, the m-mode software should set BIT(21) of csr.mxstatus to zero
> before entering the s-mode kernel. Otherwise, the kernel will not boot as 0
> on T-Head MAEE represent to NonCachable Memory and it will lose dirty cache
> lines modification that haven't been written back to the memory.

So I guess we need the bootloader to just be accurate here?  ie: 
whatever extension it tells S-mode kernels is enabled is how S-mode 
behaves, and then this should just work itself out.

> [1] https://developer.canaan-creative.com/k230/dev/zh/00_hardware/K230_datasheet.html#chapter-1-introduction
> [2] https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resource//1699268369347/XuanTie-C908-UserManual.pdf
> [3] https://github.com/cyyself/rvb_test
> [4] https://github.com/cyyself/linux/tree/k230-mainline
>
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  arch/riscv/boot/dts/canaan/Makefile       |   2 +
>  arch/riscv/boot/dts/canaan/k230-canmv.dts |  24 ++++
>  arch/riscv/boot/dts/canaan/k230-evb.dts   |  24 ++++
>  arch/riscv/boot/dts/canaan/k230.dtsi      | 140 ++++++++++++++++++++++
>  4 files changed, 190 insertions(+)
>  create mode 100644 arch/riscv/boot/dts/canaan/k230-canmv.dts
>  create mode 100644 arch/riscv/boot/dts/canaan/k230-evb.dts
>  create mode 100644 arch/riscv/boot/dts/canaan/k230.dtsi
>
> diff --git a/arch/riscv/boot/dts/canaan/Makefile b/arch/riscv/boot/dts/canaan/Makefile
> index 987d1f0c41f0..7d54ea5c6f3d 100644
> --- a/arch/riscv/boot/dts/canaan/Makefile
> +++ b/arch/riscv/boot/dts/canaan/Makefile
> @@ -1,6 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0
>  dtb-$(CONFIG_ARCH_CANAAN) += canaan_kd233.dtb
>  dtb-$(CONFIG_ARCH_CANAAN) += k210_generic.dtb
> +dtb-$(CONFIG_ARCH_CANAAN) += k230-canmv.dtb
> +dtb-$(CONFIG_ARCH_CANAAN) += k230-evb.dtb
>  dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_bit.dtb
>  dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_dock.dtb
>  dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_go.dtb
> diff --git a/arch/riscv/boot/dts/canaan/k230-canmv.dts b/arch/riscv/boot/dts/canaan/k230-canmv.dts
> new file mode 100644
> index 000000000000..3ab5c8de11a8
> --- /dev/null
> +++ b/arch/riscv/boot/dts/canaan/k230-canmv.dts
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
> + */
> +
> +#include "k230.dtsi"
> +
> +/ {
> +	model = "Canaan CanMV-K230";
> +	compatible = "canaan,canmv-k230", "canaan,kendryte-k230";
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	ddr: memory@0 {
> +		device_type = "memory";
> +		reg = <0x0 0x0 0x0 0x1fdff000>;
> +	};
> +};
> +
> +&uart0 {
> +	status = "okay";
> +};
> diff --git a/arch/riscv/boot/dts/canaan/k230-evb.dts b/arch/riscv/boot/dts/canaan/k230-evb.dts
> new file mode 100644
> index 000000000000..42720113c566
> --- /dev/null
> +++ b/arch/riscv/boot/dts/canaan/k230-evb.dts
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
> + */
> +
> +#include "k230.dtsi"
> +
> +/ {
> +	model = "Kendryte K230 EVB";
> +	compatible = "canaan,k230-usip-lp3-evb", "canaan,kendryte-k230";
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	ddr: memory@0 {
> +		device_type = "memory";
> +		reg = <0x0 0x0 0x0 0x1fdff000>;
> +	};
> +};
> +
> +&uart0 {
> +	status = "okay";
> +};
> diff --git a/arch/riscv/boot/dts/canaan/k230.dtsi b/arch/riscv/boot/dts/canaan/k230.dtsi
> new file mode 100644
> index 000000000000..0bcff67b78a8
> --- /dev/null
> +++ b/arch/riscv/boot/dts/canaan/k230.dtsi
> @@ -0,0 +1,140 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/dts-v1/;
> +/ {
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +	compatible = "canaan,kendryte-k230";
> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		timebase-frequency = <27000000>;
> +
> +		cpu@0 {
> +			compatible = "thead,c908", "riscv";
> +			device_type = "cpu";
> +			reg = <0>;
> +			riscv,isa = "rv64imafdcv_zba_zbb_zbc_zbs_zicbom_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zba", "zbb",
> +					       "zbc", "zbs", "zicbom", "zicntr", "zicsr",
> +					       "zifencei", "zihpm", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			d-cache-block-size = <64>;
> +			d-cache-sets = <128>;
> +			d-cache-size = <32768>;
> +			i-cache-block-size = <64>;
> +			i-cache-sets = <128>;
> +			i-cache-size = <32768>;
> +			next-level-cache = <&l2_cache>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu0_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +
> +		l2_cache: l2-cache {
> +			compatible = "cache";
> +			cache-block-size = <64>;
> +			cache-level = <2>;
> +			cache-size = <262144>;
> +			cache-sets = <256>;
> +			cache-unified;
> +		};
> +	};
> +
> +	apb_clk: apb-clk-clock {
> +		compatible = "fixed-clock";
> +		clock-frequency = <50000000>;
> +		clock-output-names = "apb_clk";
> +		#clock-cells = <0>;
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		interrupt-parent = <&plic>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		dma-noncoherent;
> +		ranges;
> +
> +		plic: interrupt-controller@f00000000 {
> +			compatible = "canaan,k230-plic" ,"thead,c900-plic";
> +			reg = <0xf 0x00000000 0x0 0x04000000>;
> +			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
> +			interrupt-controller;
> +			#address-cells = <0>;
> +			#interrupt-cells = <2>;
> +			riscv,ndev = <208>;
> +		};
> +
> +		clint: timer@f04000000 {
> +			compatible = "canaan,k230-clint", "thead,c900-clint";
> +			reg = <0xf 0x04000000 0x0 0x04000000>;
> +			interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>;
> +		};
> +
> +		uart0: serial@91400000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x0 0x91400000 0x0 0x1000>;
> +			clocks = <&apb_clk>;
> +			interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-io-width = <4>;
> +			reg-shift = <2>;
> +			status = "disabled";
> +		};
> +
> +		uart1: serial@91401000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x0 0x91401000 0x0 0x1000>;
> +			clocks = <&apb_clk>;
> +			interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-io-width = <4>;
> +			reg-shift = <2>;
> +			status = "disabled";
> +		};
> +
> +		uart2: serial@91402000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x0 0x91402000 0x0 0x1000>;
> +			clocks = <&apb_clk>;
> +			interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-io-width = <4>;
> +			reg-shift = <2>;
> +			status = "disabled";
> +		};
> +
> +		uart3: serial@91403000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x0 0x91403000 0x0 0x1000>;
> +			clocks = <&apb_clk>;
> +			interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-io-width = <4>;
> +			reg-shift = <2>;
> +			status = "disabled";
> +		};
> +
> +		uart4: serial@91404000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x0 0x91404000 0x0 0x1000>;
> +			clocks = <&apb_clk>;
> +			interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-io-width = <4>;
> +			reg-shift = <2>;
> +			status = "disabled";
> +		};
> +	};
> +};

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 6/7] riscv: dts: add initial canmv-k230 and k230-evb dts

[Yangyu Chen]

> On Mar 5, 2024, at 23:54, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> 
> On Mon, 04 Mar 2024 13:06:00 PST (-0800), cyy@cyyself.name wrote:
>> Add initial dts for CanMV-K230 and K230-EVB powered by Canaan Kendryte
>> K230 SoC [1].
>> 
>> Some key consideration:
>> - Only place BigCore which is 1.6GHz RV64GCBV
>> 
>> The existence of cache coherence between the two cores remains unknown
>> since they have dedicated L2 caches. And the factory SDK uses it for
>> other OS by default. I don't know whether the two CPUs on K230 SoC
>> can be used in one system. So only place BigCore here.
>> 
>> Meanwhile, although docs from Canaan said 1.6GHz Core with Vector is
>> CPU1, the csr.mhartid of this core is 0.
>> 
>> - Support for "zba" "zbb" "zbc" "zbs" are tested by hand
>> 
>> The user manual of C908 from T-Head does not document it specifically.
>> It just said it supports B extension V1.0-rc1. [2]
> 
> I'm seeing
> 
>   3.1.6 Vector instruction set (RVV)
>   For more information, see RISC-V “V”Vector Extension, Version    1.0-rc1-20210608
>   URL：https://github.com/riscv/riscv-v-spec/releases/download/v1.0-rc1/riscv-v-spec-1.0-rc1.pdf
> 
>   3.1.7 Bit operation instruction set (RV64B)
>   For more information, see ：RISC-V Bit-Manipulation ISA-extensions,    Version 1.0.0, 2021-06-12: public review
>   URL：https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0.pdf
> 
> so I think maybe that's vector 1.0-rc1 and the final bitmanip?
> 

Yeah. I just want to say what subset of the B extension is supported by
C908.

>> I have tested it by using this [3] which attempts to execute "add.uw",
>> "andn", "clmulr", "bclr" and they doesn't traps on K230. But on JH7110,
>> "clmulr" and "bclr" will trap.
>> 
>> - Support for "zicbom" is tested by hand
>> 
>> Have tested with some out-of-tree drivers from [4] that need DMA and they
>> do not come to the dts currently.
>> 
>> - Cache parameters are inferred from T-Head docs [2] and Canaan docs [1]
>> 
>> L1i: 32KB, VIPT 4-Way set-associative, 64B Cacheline
>> L1d: 32KB, VIPT 4-Way set-associative, 64B Cacheline
>> L2: 256KB, PIPT 16-way set-associative, 64B Cacheline
>> 
>> The numbers of cache sets are calculated from these parameters.
>> 
>> - MMU only supports Sv39
>> 
>> Since T-Head docs [2] say C908 should support Sv48. However, it will fail
>> during the kernel probe when running Linux on K230. I also tested it by
>> hand on M-Mode software, writing Sv48 to satp.mode will not trap but will
>> leave the csr unchanged. While writing Sv39 it will take effect. It shows
>> that this CPU does not support Sv48.
> 
> I think that only works due to a bug in our sv48 probing routines -- unless I'm missing something, we mixed up the sv57 and sv48 probing and if sv57 fails to probe then we disable sv48 as well.  So I think we probably need some cleanup in there.
> 

However, the sv48 probing routines work on some other chips with sv48. At
least I have tested mainline kernel v6.8-rc2. And the attempt to write sv48
to satp by hand tells me it does not support sv48. I think it might be
configurable from CPU RTL, and the K230 taped out with no sv48 support.

>> - Svpbmt and T-Head MAEE both supported
>> 
>> T-Head C908 does support both Svpbmt and T-Head MAEE for page-based memory
>> attributes and is controlled by csr.mxstatus. If the kernel wants to use
>> svpbmt, the m-mode software should set BIT(21) of csr.mxstatus to zero
>> before entering the s-mode kernel. Otherwise, the kernel will not boot as 0
>> on T-Head MAEE represent to NonCachable Memory and it will lose dirty cache
>> lines modification that haven't been written back to the memory.
> 
> So I guess we need the bootloader to just be accurate here?  ie: whatever extension it tells S-mode kernels is enabled is how S-mode behaves, and then this should just work itself out.
> 

Yes. Currently, I have patched OpenSBI to disable MAEE. Conor Dooley said
from a public irc group that he wants to control the enable of T-Head
variation of zicbom and svpbmt from dts, in addition to mimplid or
something now. I think that will be a better way for the bootloader to tell
the kernel whether the T-Head MAEE should be enabled.

Link: https://github.com/cyyself/opensbi/commit/b113c1c01d700314a4a696297ec09031a9399354

Furthermore, I wonder whether a CPU node like this would be acceptable.
I don't have any other details of how another CPU from K230 SoC works on
Linux.

>> [1] https://developer.canaan-creative.com/k230/dev/zh/00_hardware/K230_datasheet.html#chapter-1-introduction
>> [2] https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resource//1699268369347/XuanTie-C908-UserManual.pdf
>> [3] https://github.com/cyyself/rvb_test
>> [4] https://github.com/cyyself/linux/tree/k230-mainline
>> 
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>> ---
>> arch/riscv/boot/dts/canaan/Makefile       |   2 +
>> arch/riscv/boot/dts/canaan/k230-canmv.dts |  24 ++++
>> arch/riscv/boot/dts/canaan/k230-evb.dts   |  24 ++++
>> arch/riscv/boot/dts/canaan/k230.dtsi      | 140 ++++++++++++++++++++++
>> 4 files changed, 190 insertions(+)
>> create mode 100644 arch/riscv/boot/dts/canaan/k230-canmv.dts
>> create mode 100644 arch/riscv/boot/dts/canaan/k230-evb.dts
>> create mode 100644 arch/riscv/boot/dts/canaan/k230.dtsi
>> 
>> diff --git a/arch/riscv/boot/dts/canaan/Makefile b/arch/riscv/boot/dts/canaan/Makefile
>> index 987d1f0c41f0..7d54ea5c6f3d 100644
>> --- a/arch/riscv/boot/dts/canaan/Makefile
>> +++ b/arch/riscv/boot/dts/canaan/Makefile
>> @@ -1,6 +1,8 @@
>> # SPDX-License-Identifier: GPL-2.0
>> dtb-$(CONFIG_ARCH_CANAAN) += canaan_kd233.dtb
>> dtb-$(CONFIG_ARCH_CANAAN) += k210_generic.dtb
>> +dtb-$(CONFIG_ARCH_CANAAN) += k230-canmv.dtb
>> +dtb-$(CONFIG_ARCH_CANAAN) += k230-evb.dtb
>> dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_bit.dtb
>> dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_dock.dtb
>> dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_go.dtb
>> diff --git a/arch/riscv/boot/dts/canaan/k230-canmv.dts b/arch/riscv/boot/dts/canaan/k230-canmv.dts
>> new file mode 100644
>> index 000000000000..3ab5c8de11a8
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/canaan/k230-canmv.dts
>> @@ -0,0 +1,24 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +/*
>> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
>> + */
>> +
>> +#include "k230.dtsi"
>> +
>> +/ {
>> + model = "Canaan CanMV-K230";
>> + compatible = "canaan,canmv-k230", "canaan,kendryte-k230";
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + ddr: memory@0 {
>> + device_type = "memory";
>> + reg = <0x0 0x0 0x0 0x1fdff000>;
>> + };
>> +};
>> +
>> +&uart0 {
>> + status = "okay";
>> +};
>> diff --git a/arch/riscv/boot/dts/canaan/k230-evb.dts b/arch/riscv/boot/dts/canaan/k230-evb.dts
>> new file mode 100644
>> index 000000000000..42720113c566
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/canaan/k230-evb.dts
>> @@ -0,0 +1,24 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +/*
>> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
>> + */
>> +
>> +#include "k230.dtsi"
>> +
>> +/ {
>> + model = "Kendryte K230 EVB";
>> + compatible = "canaan,k230-usip-lp3-evb", "canaan,kendryte-k230";
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + ddr: memory@0 {
>> + device_type = "memory";
>> + reg = <0x0 0x0 0x0 0x1fdff000>;
>> + };
>> +};
>> +
>> +&uart0 {
>> + status = "okay";
>> +};
>> diff --git a/arch/riscv/boot/dts/canaan/k230.dtsi b/arch/riscv/boot/dts/canaan/k230.dtsi
>> new file mode 100644
>> index 000000000000..0bcff67b78a8
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/canaan/k230.dtsi
>> @@ -0,0 +1,140 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +/*
>> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
>> + */
>> +
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +
>> +/dts-v1/;
>> +/ {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + compatible = "canaan,kendryte-k230";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + timebase-frequency = <27000000>;
>> +
>> + cpu@0 {
>> + compatible = "thead,c908", "riscv";
>> + device_type = "cpu";
>> + reg = <0>;
>> + riscv,isa = "rv64imafdcv_zba_zbb_zbc_zbs_zicbom_svpbmt";
>> + riscv,isa-base = "rv64i";
>> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zba", "zbb",
>> +        "zbc", "zbs", "zicbom", "zicntr", "zicsr",
>> +        "zifencei", "zihpm", "svpbmt";
>> + riscv,cbom-block-size = <64>;
>> + d-cache-block-size = <64>;
>> + d-cache-sets = <128>;
>> + d-cache-size = <32768>;
>> + i-cache-block-size = <64>;
>> + i-cache-sets = <128>;
>> + i-cache-size = <32768>;
>> + next-level-cache = <&l2_cache>;
>> + mmu-type = "riscv,sv39";
>> +
>> + cpu0_intc: interrupt-controller {
>> + compatible = "riscv,cpu-intc";
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> + };
>> + };
>> +
>> + l2_cache: l2-cache {
>> + compatible = "cache";
>> + cache-block-size = <64>;
>> + cache-level = <2>;
>> + cache-size = <262144>;
>> + cache-sets = <256>;
>> + cache-unified;
>> + };
>> + };
>> +
>> + apb_clk: apb-clk-clock {
>> + compatible = "fixed-clock";
>> + clock-frequency = <50000000>;
>> + clock-output-names = "apb_clk";
>> + #clock-cells = <0>;
>> + };
>> +
>> + soc {
>> + compatible = "simple-bus";
>> + interrupt-parent = <&plic>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + dma-noncoherent;
>> + ranges;
>> +
>> + plic: interrupt-controller@f00000000 {
>> + compatible = "canaan,k230-plic" ,"thead,c900-plic";
>> + reg = <0xf 0x00000000 0x0 0x04000000>;
>> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
>> + interrupt-controller;
>> + #address-cells = <0>;
>> + #interrupt-cells = <2>;
>> + riscv,ndev = <208>;
>> + };
>> +
>> + clint: timer@f04000000 {
>> + compatible = "canaan,k230-clint", "thead,c900-clint";
>> + reg = <0xf 0x04000000 0x0 0x04000000>;
>> + interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>;
>> + };
>> +
>> + uart0: serial@91400000 {
>> + compatible = "snps,dw-apb-uart";
>> + reg = <0x0 0x91400000 0x0 0x1000>;
>> + clocks = <&apb_clk>;
>> + interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
>> + reg-io-width = <4>;
>> + reg-shift = <2>;
>> + status = "disabled";
>> + };
>> +
>> + uart1: serial@91401000 {
>> + compatible = "snps,dw-apb-uart";
>> + reg = <0x0 0x91401000 0x0 0x1000>;
>> + clocks = <&apb_clk>;
>> + interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
>> + reg-io-width = <4>;
>> + reg-shift = <2>;
>> + status = "disabled";
>> + };
>> +
>> + uart2: serial@91402000 {
>> + compatible = "snps,dw-apb-uart";
>> + reg = <0x0 0x91402000 0x0 0x1000>;
>> + clocks = <&apb_clk>;
>> + interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
>> + reg-io-width = <4>;
>> + reg-shift = <2>;
>> + status = "disabled";
>> + };
>> +
>> + uart3: serial@91403000 {
>> + compatible = "snps,dw-apb-uart";
>> + reg = <0x0 0x91403000 0x0 0x1000>;
>> + clocks = <&apb_clk>;
>> + interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
>> + reg-io-width = <4>;
>> + reg-shift = <2>;
>> + status = "disabled";
>> + };
>> +
>> + uart4: serial@91404000 {
>> + compatible = "snps,dw-apb-uart";
>> + reg = <0x0 0x91404000 0x0 0x1000>;
>> + clocks = <&apb_clk>;
>> + interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
>> + reg-io-width = <4>;
>> + reg-shift = <2>;
>> + status = "disabled";
>> + };
>> + };
>> +};



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 6/7] riscv: dts: add initial canmv-k230 and k230-evb dts

[Yangyu Chen]

> On Mar 6, 2024, at 00:22, Yangyu Chen <cyy@cyyself.name> wrote:
> 
>> 
>> On Mar 5, 2024, at 23:54, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> 
>> On Mon, 04 Mar 2024 13:06:00 PST (-0800), cyy@cyyself.name wrote:
>>> Add initial dts for CanMV-K230 and K230-EVB powered by Canaan Kendryte
>>> K230 SoC [1].
>>> 
>>> Some key consideration:
>>> - Only place BigCore which is 1.6GHz RV64GCBV
>>> 
>>> The existence of cache coherence between the two cores remains unknown
>>> since they have dedicated L2 caches. And the factory SDK uses it for
>>> other OS by default. I don't know whether the two CPUs on K230 SoC
>>> can be used in one system. So only place BigCore here.
>>> 
>>> Meanwhile, although docs from Canaan said 1.6GHz Core with Vector is
>>> CPU1, the csr.mhartid of this core is 0.
>>> 
>>> - Support for "zba" "zbb" "zbc" "zbs" are tested by hand
>>> 
>>> The user manual of C908 from T-Head does not document it specifically.
>>> It just said it supports B extension V1.0-rc1. [2]
>> 
>> I'm seeing
>> 
>>  3.1.6 Vector instruction set (RVV)
>>  For more information, see RISC-V “V”Vector Extension, Version    1.0-rc1-20210608
>>  URL：https://github.com/riscv/riscv-v-spec/releases/download/v1.0-rc1/riscv-v-spec-1.0-rc1.pdf
>> 
>>  3.1.7 Bit operation instruction set (RV64B)
>>  For more information, see ：RISC-V Bit-Manipulation ISA-extensions,    Version 1.0.0, 2021-06-12: public review
>>  URL：https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0.pdf
>> 
>> so I think maybe that's vector 1.0-rc1 and the final bitmanip?
>> 
> 
> Yeah. I just want to say what subset of the B extension is supported by
> C908.
> 

Oh. I misunderstand it. The version of bitmanip is 1.0 rather than 1.0-rc1
I said before. The version of the vector is 1.0-rc1. I will change that in
the next revision.

>>> I have tested it by using this [3] which attempts to execute "add.uw",
>>> "andn", "clmulr", "bclr" and they doesn't traps on K230. But on JH7110,
>>> "clmulr" and "bclr" will trap.
>>> 
>>> - Support for "zicbom" is tested by hand
>>> 
>>> Have tested with some out-of-tree drivers from [4] that need DMA and they
>>> do not come to the dts currently.
>>> 
>>> - Cache parameters are inferred from T-Head docs [2] and Canaan docs [1]
>>> 
>>> L1i: 32KB, VIPT 4-Way set-associative, 64B Cacheline
>>> L1d: 32KB, VIPT 4-Way set-associative, 64B Cacheline
>>> L2: 256KB, PIPT 16-way set-associative, 64B Cacheline
>>> 
>>> The numbers of cache sets are calculated from these parameters.
>>> 
>>> - MMU only supports Sv39
>>> 
>>> Since T-Head docs [2] say C908 should support Sv48. However, it will fail
>>> during the kernel probe when running Linux on K230. I also tested it by
>>> hand on M-Mode software, writing Sv48 to satp.mode will not trap but will
>>> leave the csr unchanged. While writing Sv39 it will take effect. It shows
>>> that this CPU does not support Sv48.
>> 
>> I think that only works due to a bug in our sv48 probing routines -- unless I'm missing something, we mixed up the sv57 and sv48 probing and if sv57 fails to probe then we disable sv48 as well.  So I think we probably need some cleanup in there.
>> 
> 
> However, the sv48 probing routines work on some other chips with sv48. At
> least I have tested mainline kernel v6.8-rc2. And the attempt to write sv48
> to satp by hand tells me it does not support sv48. I think it might be
> configurable from CPU RTL, and the K230 taped out with no sv48 support.
> 
>>> - Svpbmt and T-Head MAEE both supported
>>> 
>>> T-Head C908 does support both Svpbmt and T-Head MAEE for page-based memory
>>> attributes and is controlled by csr.mxstatus. If the kernel wants to use
>>> svpbmt, the m-mode software should set BIT(21) of csr.mxstatus to zero
>>> before entering the s-mode kernel. Otherwise, the kernel will not boot as 0
>>> on T-Head MAEE represent to NonCachable Memory and it will lose dirty cache
>>> lines modification that haven't been written back to the memory.
>> 
>> So I guess we need the bootloader to just be accurate here?  ie: whatever extension it tells S-mode kernels is enabled is how S-mode behaves, and then this should just work itself out.
>> 
> 
> Yes. Currently, I have patched OpenSBI to disable MAEE. Conor Dooley said
> from a public irc group that he wants to control the enable of T-Head
> variation of zicbom and svpbmt from dts, in addition to mimplid or
> something now. I think that will be a better way for the bootloader to tell
> the kernel whether the T-Head MAEE should be enabled.
> 
> Link: https://github.com/cyyself/opensbi/commit/b113c1c01d700314a4a696297ec09031a9399354
> 
> Furthermore, I wonder whether a CPU node like this would be acceptable.
> I don't have any other details of how another CPU from K230 SoC works on
> Linux.
> 
>>> [1] https://developer.canaan-creative.com/k230/dev/zh/00_hardware/K230_datasheet.html#chapter-1-introduction
>>> [2] https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resource//1699268369347/XuanTie-C908-UserManual.pdf
>>> [3] https://github.com/cyyself/rvb_test
>>> [4] https://github.com/cyyself/linux/tree/k230-mainline
>>> 
>>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>>> ---
>>> arch/riscv/boot/dts/canaan/Makefile       |   2 +
>>> arch/riscv/boot/dts/canaan/k230-canmv.dts |  24 ++++
>>> arch/riscv/boot/dts/canaan/k230-evb.dts   |  24 ++++
>>> arch/riscv/boot/dts/canaan/k230.dtsi      | 140 ++++++++++++++++++++++
>>> 4 files changed, 190 insertions(+)
>>> create mode 100644 arch/riscv/boot/dts/canaan/k230-canmv.dts
>>> create mode 100644 arch/riscv/boot/dts/canaan/k230-evb.dts
>>> create mode 100644 arch/riscv/boot/dts/canaan/k230.dtsi
>>> 
>>> diff --git a/arch/riscv/boot/dts/canaan/Makefile b/arch/riscv/boot/dts/canaan/Makefile
>>> index 987d1f0c41f0..7d54ea5c6f3d 100644
>>> --- a/arch/riscv/boot/dts/canaan/Makefile
>>> +++ b/arch/riscv/boot/dts/canaan/Makefile
>>> @@ -1,6 +1,8 @@
>>> # SPDX-License-Identifier: GPL-2.0
>>> dtb-$(CONFIG_ARCH_CANAAN) += canaan_kd233.dtb
>>> dtb-$(CONFIG_ARCH_CANAAN) += k210_generic.dtb
>>> +dtb-$(CONFIG_ARCH_CANAAN) += k230-canmv.dtb
>>> +dtb-$(CONFIG_ARCH_CANAAN) += k230-evb.dtb
>>> dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_bit.dtb
>>> dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_dock.dtb
>>> dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_go.dtb
>>> diff --git a/arch/riscv/boot/dts/canaan/k230-canmv.dts b/arch/riscv/boot/dts/canaan/k230-canmv.dts
>>> new file mode 100644
>>> index 000000000000..3ab5c8de11a8
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/canaan/k230-canmv.dts
>>> @@ -0,0 +1,24 @@
>>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>>> +/*
>>> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
>>> + */
>>> +
>>> +#include "k230.dtsi"
>>> +
>>> +/ {
>>> + model = "Canaan CanMV-K230";
>>> + compatible = "canaan,canmv-k230", "canaan,kendryte-k230";
>>> +
>>> + chosen {
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + ddr: memory@0 {
>>> + device_type = "memory";
>>> + reg = <0x0 0x0 0x0 0x1fdff000>;
>>> + };
>>> +};
>>> +
>>> +&uart0 {
>>> + status = "okay";
>>> +};
>>> diff --git a/arch/riscv/boot/dts/canaan/k230-evb.dts b/arch/riscv/boot/dts/canaan/k230-evb.dts
>>> new file mode 100644
>>> index 000000000000..42720113c566
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/canaan/k230-evb.dts
>>> @@ -0,0 +1,24 @@
>>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>>> +/*
>>> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
>>> + */
>>> +
>>> +#include "k230.dtsi"
>>> +
>>> +/ {
>>> + model = "Kendryte K230 EVB";
>>> + compatible = "canaan,k230-usip-lp3-evb", "canaan,kendryte-k230";
>>> +
>>> + chosen {
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + ddr: memory@0 {
>>> + device_type = "memory";
>>> + reg = <0x0 0x0 0x0 0x1fdff000>;
>>> + };
>>> +};
>>> +
>>> +&uart0 {
>>> + status = "okay";
>>> +};
>>> diff --git a/arch/riscv/boot/dts/canaan/k230.dtsi b/arch/riscv/boot/dts/canaan/k230.dtsi
>>> new file mode 100644
>>> index 000000000000..0bcff67b78a8
>>> --- /dev/null
>>> +++ b/arch/riscv/boot/dts/canaan/k230.dtsi
>>> @@ -0,0 +1,140 @@
>>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>>> +/*
>>> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
>>> + */
>>> +
>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>> +
>>> +/dts-v1/;
>>> +/ {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + compatible = "canaan,kendryte-k230";
>>> +
>>> + aliases {
>>> + serial0 = &uart0;
>>> + };
>>> +
>>> + cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + timebase-frequency = <27000000>;
>>> +
>>> + cpu@0 {
>>> + compatible = "thead,c908", "riscv";
>>> + device_type = "cpu";
>>> + reg = <0>;
>>> + riscv,isa = "rv64imafdcv_zba_zbb_zbc_zbs_zicbom_svpbmt";
>>> + riscv,isa-base = "rv64i";
>>> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zba", "zbb",
>>> +        "zbc", "zbs", "zicbom", "zicntr", "zicsr",
>>> +        "zifencei", "zihpm", "svpbmt";
>>> + riscv,cbom-block-size = <64>;
>>> + d-cache-block-size = <64>;
>>> + d-cache-sets = <128>;
>>> + d-cache-size = <32768>;
>>> + i-cache-block-size = <64>;
>>> + i-cache-sets = <128>;
>>> + i-cache-size = <32768>;
>>> + next-level-cache = <&l2_cache>;
>>> + mmu-type = "riscv,sv39";
>>> +
>>> + cpu0_intc: interrupt-controller {
>>> + compatible = "riscv,cpu-intc";
>>> + interrupt-controller;
>>> + #interrupt-cells = <1>;
>>> + };
>>> + };
>>> +
>>> + l2_cache: l2-cache {
>>> + compatible = "cache";
>>> + cache-block-size = <64>;
>>> + cache-level = <2>;
>>> + cache-size = <262144>;
>>> + cache-sets = <256>;
>>> + cache-unified;
>>> + };
>>> + };
>>> +
>>> + apb_clk: apb-clk-clock {
>>> + compatible = "fixed-clock";
>>> + clock-frequency = <50000000>;
>>> + clock-output-names = "apb_clk";
>>> + #clock-cells = <0>;
>>> + };
>>> +
>>> + soc {
>>> + compatible = "simple-bus";
>>> + interrupt-parent = <&plic>;
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + dma-noncoherent;
>>> + ranges;
>>> +
>>> + plic: interrupt-controller@f00000000 {
>>> + compatible = "canaan,k230-plic" ,"thead,c900-plic";
>>> + reg = <0xf 0x00000000 0x0 0x04000000>;
>>> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
>>> + interrupt-controller;
>>> + #address-cells = <0>;
>>> + #interrupt-cells = <2>;
>>> + riscv,ndev = <208>;
>>> + };
>>> +
>>> + clint: timer@f04000000 {
>>> + compatible = "canaan,k230-clint", "thead,c900-clint";
>>> + reg = <0xf 0x04000000 0x0 0x04000000>;
>>> + interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>;
>>> + };
>>> +
>>> + uart0: serial@91400000 {
>>> + compatible = "snps,dw-apb-uart";
>>> + reg = <0x0 0x91400000 0x0 0x1000>;
>>> + clocks = <&apb_clk>;
>>> + interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
>>> + reg-io-width = <4>;
>>> + reg-shift = <2>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + uart1: serial@91401000 {
>>> + compatible = "snps,dw-apb-uart";
>>> + reg = <0x0 0x91401000 0x0 0x1000>;
>>> + clocks = <&apb_clk>;
>>> + interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
>>> + reg-io-width = <4>;
>>> + reg-shift = <2>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + uart2: serial@91402000 {
>>> + compatible = "snps,dw-apb-uart";
>>> + reg = <0x0 0x91402000 0x0 0x1000>;
>>> + clocks = <&apb_clk>;
>>> + interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
>>> + reg-io-width = <4>;
>>> + reg-shift = <2>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + uart3: serial@91403000 {
>>> + compatible = "snps,dw-apb-uart";
>>> + reg = <0x0 0x91403000 0x0 0x1000>;
>>> + clocks = <&apb_clk>;
>>> + interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
>>> + reg-io-width = <4>;
>>> + reg-shift = <2>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + uart4: serial@91404000 {
>>> + compatible = "snps,dw-apb-uart";
>>> + reg = <0x0 0x91404000 0x0 0x1000>;
>>> + clocks = <&apb_clk>;
>>> + interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
>>> + reg-io-width = <4>;
>>> + reg-shift = <2>;
>>> + status = "disabled";
>>> + };
>>> + };
>>> +};



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 6/7] riscv: dts: add initial canmv-k230 and k230-evb dts

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2738 bytes --]

Hey,

Just chiming so that things don't get misinterpreted.

On Wed, Mar 06, 2024 at 12:37:16AM +0800, Yangyu Chen wrote:
> > On Mar 6, 2024, at 00:22, Yangyu Chen <cyy@cyyself.name> wrote:
> >> On Mar 5, 2024, at 23:54, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >> On Mon, 04 Mar 2024 13:06:00 PST (-0800), cyy@cyyself.name wrote:
> >>> - Svpbmt and T-Head MAEE both supported
> >>> 
> >>> T-Head C908 does support both Svpbmt and T-Head MAEE for page-based memory
> >>> attributes and is controlled by csr.mxstatus. If the kernel wants to use
> >>> svpbmt, the m-mode software should set BIT(21) of csr.mxstatus to zero
> >>> before entering the s-mode kernel. Otherwise, the kernel will not boot as 0
> >>> on T-Head MAEE represent to NonCachable Memory and it will lose dirty cache
> >>> lines modification that haven't been written back to the memory.
> >> 
> >> So I guess we need the bootloader to just be accurate here?  ie: whatever
> >> extension it tells S-mode kernels is enabled is how S-mode behaves, and
> >> then this should just work itself out.

Correct, the bootloader/firmware "just" needs to write this bit to match
what it passes to onwards in the devicetree.

> > Yes. Currently, I have patched OpenSBI to disable MAEE. Conor Dooley said
> > from a public irc group that he wants to control the enable of T-Head

(#riscv on libera, the usual location)

I also suggested that that, given we can use the standard extensions,
we should use them instead of the custom extensions/errata.

> > variation of zicbom and svpbmt from dts, in addition to mimplid or
> > something now.

Correct. I'm find with the impid == archid == 0 condition, given that's
what we need to keep to avoid regressions, but if any future T-Head CPUs
want to enable MAEE (ERRATA_THEAD_PBMT) or the custom CMOs
(ERRATA_THEAD_CMO) these should be enabled from DT. Particularly when
these CPUs can be configured to either use the T-Head versions or the
standard extensions.

> > I think that will be a better way for the bootloader to tell
> > the kernel whether the T-Head MAEE should be enabled.

You've got three options I guess. You could patch the DT in the bootloader,
or use a fixed DT that matches the bootloader, or you could use the DT
passed to the bootloader and parse the extensions to decide whether or not
to enable MAEE or Svpbmt. Seems you're going for option 2.

> > Link: https://github.com/cyyself/opensbi/commit/b113c1c01d700314a4a696297ec09031a9399354
> > 
> > Furthermore, I wonder whether a CPU node like this would be acceptable.
> > I don't have any other details of how another CPU from K230 SoC works on
> > Linux.

A CPU node like what? It is not clear to me.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 6/7] riscv: dts: add initial canmv-k230 and k230-evb dts

[Yangyu Chen]

> On Mar 6, 2024, at 01:01, Conor Dooley <conor@kernel.org> wrote:
> 
> Hey,
> 
> Just chiming so that things don't get misinterpreted.
> 
> On Wed, Mar 06, 2024 at 12:37:16AM +0800, Yangyu Chen wrote:
>>> On Mar 6, 2024, at 00:22, Yangyu Chen <cyy@cyyself.name> wrote:
>>>> On Mar 5, 2024, at 23:54, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>> On Mon, 04 Mar 2024 13:06:00 PST (-0800), cyy@cyyself.name wrote:
>>>>> - Svpbmt and T-Head MAEE both supported
>>>>> 
>>>>> T-Head C908 does support both Svpbmt and T-Head MAEE for page-based memory
>>>>> attributes and is controlled by csr.mxstatus. If the kernel wants to use
>>>>> svpbmt, the m-mode software should set BIT(21) of csr.mxstatus to zero
>>>>> before entering the s-mode kernel. Otherwise, the kernel will not boot as 0
>>>>> on T-Head MAEE represent to NonCachable Memory and it will lose dirty cache
>>>>> lines modification that haven't been written back to the memory.
>>>> 
>>>> So I guess we need the bootloader to just be accurate here?  ie: whatever
>>>> extension it tells S-mode kernels is enabled is how S-mode behaves, and
>>>> then this should just work itself out.
> 
> Correct, the bootloader/firmware "just" needs to write this bit to match
> what it passes to onwards in the devicetree.
> 
>>> Yes. Currently, I have patched OpenSBI to disable MAEE. Conor Dooley said
>>> from a public irc group that he wants to control the enable of T-Head
> 
> (#riscv on libera, the usual location)
> 
> I also suggested that that, given we can use the standard extensions,
> we should use them instead of the custom extensions/errata.
> 
>>> variation of zicbom and svpbmt from dts, in addition to mimplid or
>>> something now.
> 
> Correct. I'm find with the impid == archid == 0 condition, given that's
> what we need to keep to avoid regressions, but if any future T-Head CPUs
> want to enable MAEE (ERRATA_THEAD_PBMT) or the custom CMOs
> (ERRATA_THEAD_CMO) these should be enabled from DT. Particularly when
> these CPUs can be configured to either use the T-Head versions or the
> standard extensions.
> 
>>> I think that will be a better way for the bootloader to tell
>>> the kernel whether the T-Head MAEE should be enabled.
> 
> You've got three options I guess. You could patch the DT in the bootloader,
> or use a fixed DT that matches the bootloader, or you could use the DT
> passed to the bootloader and parse the extensions to decide whether or not
> to enable MAEE or Svpbmt. Seems you're going for option 2.
> 

The patched opensbi is only for work around now as the factory-provided
M-Mode uboot will enable MAEE. I would like option 1 to let the bootloader
choose what to use and patch the DT to tell the linux whether should use
T-Head MAEE as T-Head is likely to use this feature on TEE
(Trusted Execution Environment), so it might never be removed.

>>> Link: https://github.com/cyyself/opensbi/commit/b113c1c01d700314a4a696297ec09031a9399354
>>> 
>>> Furthermore, I wonder whether a CPU node like this would be acceptable.
>>> I don't have any other details of how another CPU from K230 SoC works on
>>> Linux.
> 
> A CPU node like what? It is not clear to me.

It in the k230.dtsi file. Only has big core there.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 6/7] riscv: dts: add initial canmv-k230 and k230-evb dts

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 645 bytes --]

On Wed, Mar 06, 2024 at 01:17:29AM +0800, Yangyu Chen wrote:
> > On Mar 6, 2024, at 01:01, Conor Dooley <conor@kernel.org> wrote:
> > On Wed, Mar 06, 2024 at 12:37:16AM +0800, Yangyu Chen wrote:

> >>> Link: https://github.com/cyyself/opensbi/commit/b113c1c01d700314a4a696297ec09031a9399354
> >>> 
> >>> Furthermore, I wonder whether a CPU node like this would be acceptable.
> >>> I don't have any other details of how another CPU from K230 SoC works on
> >>> Linux.
> > 
> > A CPU node like what? It is not clear to me.
> 
> It in the k230.dtsi file. Only has big core there.

The node that is currently there looks fine to me.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 7/7] riscv: config: enable SOC_CANAAN in defconfig

[Yangyu Chen]

Since K230 has been supported, allow SOC_CANAAN to be selected to build dt
and drivers for it in defconfig.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 89a009a580fe..20b557ec28df 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -33,6 +33,7 @@ CONFIG_SOC_STARFIVE=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_THEAD=y
 CONFIG_SOC_VIRT=y
+CONFIG_SOC_CANAAN=y
 CONFIG_SMP=y
 CONFIG_HOTPLUG_CPU=y
 CONFIG_PM=y
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 7/7] riscv: config: enable SOC_CANAAN in defconfig

[Damien Le Moal]

On 3/5/24 06:06, Yangyu Chen wrote:
> Since K230 has been supported, allow SOC_CANAAN to be selected to build dt
> and drivers for it in defconfig.
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  arch/riscv/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index 89a009a580fe..20b557ec28df 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -33,6 +33,7 @@ CONFIG_SOC_STARFIVE=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_ARCH_THEAD=y
>  CONFIG_SOC_VIRT=y
> +CONFIG_SOC_CANAAN=y

Given that the k210 need !MMU, including it like this in the defconfig is
odd... I do not even see how that could work. But that depends on patch 5,
which does not seem OK to me.

>  CONFIG_SMP=y
>  CONFIG_HOTPLUG_CPU=y
>  CONFIG_PM=y

-- 
Damien Le Moal
Western Digital Research


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 7/7] riscv: config: enable SOC_CANAAN in defconfig

[Yangyu Chen]

> On Mar 5, 2024, at 07:50, Damien Le Moal <dlemoal@kernel.org> wrote:
> 
> On 3/5/24 06:06, Yangyu Chen wrote:
>> Since K230 has been supported, allow SOC_CANAAN to be selected to build dt
>> and drivers for it in defconfig.
>> 
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>> ---
>> arch/riscv/configs/defconfig | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
>> index 89a009a580fe..20b557ec28df 100644
>> --- a/arch/riscv/configs/defconfig
>> +++ b/arch/riscv/configs/defconfig
>> @@ -33,6 +33,7 @@ CONFIG_SOC_STARFIVE=y
>> CONFIG_ARCH_SUNXI=y
>> CONFIG_ARCH_THEAD=y
>> CONFIG_SOC_VIRT=y
>> +CONFIG_SOC_CANAAN=y
> 
> Given that the k210 need !MMU, including it like this in the defconfig is
> odd... I do not even see how that could work. But that depends on patch 5,
> which does not seem OK to me.
> 

I don’t know why “not seem OK” here.

I will show the console to tell you what changes in defconfig:

```console
$  linux git:(rv_builtin_dtb_v3) make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig
*** Default configuration is based on 'defconfig'
#
# configuration written to .config
#
$  linux git:(rv_builtin_dtb_v3) cp .config .config.bak
$  linux git:(rv_builtin_dtb_v3) git checkout k230_dt_initial_v3
Switched to branch 'k230_dt_initial_v3'
$  linux git:(k230_dt_initial_v3) make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig
*** Default configuration is based on 'defconfig'
#
# configuration written to .config
#
$  linux git:(k230_dt_initial_v3) diff .config .config.bak
301,302d300
< CONFIG_ARCH_CANAAN=y
< CONFIG_SOC_CANAAN=y
2678d2675
< CONFIG_PINCTRL_K210=y
4621d4617
< CONFIG_COMMON_CLK_K210=y
4<
706,4707d4701
< CONFIG_SOC_K210_SYSCTL=y
5334d5327
< CONFIG_ARCH_HAS_RESET_CONTROLLER=y
5336d5328
< CONFIG_RESET_K210=y
$  linux git:(k230_dt_initial_v3) grep -r "CONFIG_ARCH_HAS_RESET_CONTROLLER"
kernel/config_data:CONFIG_ARCH_HAS_RESET_CONTROLLER=y
include/config/auto.conf:CONFIG_ARCH_HAS_RESET_CONTROLLER=y
include/generated/autoconf.h:#define CONFIG_ARCH_HAS_RESET_CONTROLLER 1
include/generated/rustc_cfg:--cfg=CONFIG_ARCH_HAS_RESET_CONTROLLER
include/generated/rustc_cfg:--cfg=CONFIG_ARCH_HAS_RESET_CONTROLLER="y"
.config:CONFIG_ARCH_HAS_RESET_CONTROLLER=y
$  linux git:(k230_dt_initial_v3)
```

As you can see, we only have some drivers enabled for K210 and
CONFIG_ARCH_HAS_RESET_CONTROLLER being enabled. The next grep -r shows it
does not change the kernel behavior.

>> CONFIG_SMP=y
>> CONFIG_HOTPLUG_CPU=y
>> CONFIG_PM=y
> 
> -- 
> Damien Le Moal
> Western Digital Research



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv