riscv: add Bouffalolab bl808 support

[1]:
https://github.com/bouffalolab/bl808_linux/blob/main/linux-5.10.4-808/drivers/tty/serial/bflb_uart.c#L700

---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0

index 82d39ab0231b..3566346f2f9e 100644
@@ -200,6 +200,8 @@ patternProperties:
     description: BOE Technology Group Co., Ltd.
   "^bosch,.*":
     description: Bosch Sensortec GmbH
+  "^bouffalolab,.*":
+    description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
   "^boundary,.*":
     description: Boundary Devices Inc.
   "^brcm,.*":

Signature · 1 line

2.40.0

Samuel Holland

2023-05-19 02:53 UTC #2 lore raw

Re: [PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

Hi Jisheng,

Thanks for updating this series!

Quoted 18 lines · Jisheng Zhang

In the following commits, we will support bl808 SoC which is from Bouffalo Lab Technology (Nanjing) Co., Ltd.
Add bouffalolab vendor prefix binding.
Link https://en.bouffalolab.com/
Signed-off-by Jisheng Zhang <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/vendor-prefixes.yaml +0 -0
index 82d39ab0231b..3566346f2f9e 100644

Documentation/devicetree/bindings/vendor-prefixes.yaml patternProperties: · line 204

Quoted 5 lines

Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0

@@ -200,6 +200,8 @@ patternProperties:
     description: BOE Technology Group Co., Ltd.
   "^bosch,.*":
     description: Bosch Sensortec GmbH
+  "^bouffalolab,.*":
+    description: Bouffalo Lab Technology (Nanjing) Co., Ltd.

Have you thought about using the "bflb" abbreviation as the vendor prefix, like you use throughout the driver code? This would save quite some space in the DTB, and seems to be the most common variant seen in the vendor SDK:

bouffalo_sdk$ git grep -i bflb | wc -l
14364
bouffalo_sdk$ git grep -i bouffalo | wc -l
1042
bouffalo_sdk$ git grep -i bouffalolab | wc -l
179

So that is what we were using for bringing up Linux and U-Boot over at
https://github.com/openbouffalo.

On the other hand, "bouffalolab" is certainly accurate as well, so I understand if you prefer it. And we will of course adapt to whatever gets merged, since our goal is upstreaming.

The vendor code drop[1] provided only one example, "bflb-uart,uart0", which is not very helpful. Maybe you have received further information from them?

What do you think?

Regards,
Samuel

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Jisheng Zhang

author

2023-05-21 09:13 UTC #3 lore raw

Re: [PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

Quoted 18 lines · Samuel Holland

Hi Jisheng,
Thanks for updating this series!
Quoted 13 lines · Jisheng Zhang
In the following commits, we will support bl808 SoC which is from Bouffalo Lab Technology (Nanjing) Co., Ltd.
Add bouffalolab vendor prefix binding.
Link https://en.bouffalolab.com/
Signed-off-by Jisheng Zhang <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

Quoted 12 lines

Documentation/devicetree/bindings/vendor-prefixes.yaml patternProperties: · line 204
Quoted 10 lines
Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0
index 82d39ab0231b..3566346f2f9e 100644
@@ -200,6 +200,8 @@ patternProperties:
     description: BOE Technology Group Co., Ltd.
   "^bosch,.*":
     description: Bosch Sensortec GmbH
+  "^bouffalolab,.*":
+    description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
Have you thought about using the "bflb" abbreviation as the vendor

I did think about bflb vs bouffalolab. Here is what I thought: I came across "marvell" vs "mrvl" sevral years ago, I got an impression "marvell" vendor prefix is preferred if I read the discussions correctly.

As for Bouffalolab vendor prefix, I have no preference, maybe DT maintainers can provide inputs here.
Rob, Conor, Krzysztof, what's your opinion?

Thanks

Quoted 30 lines

prefix, like you use throughout the driver code? This would save quite some space in the DTB, and seems to be the most common variant seen in the vendor SDK:
bouffalo_sdk$ git grep -i bflb | wc -l
14364
bouffalo_sdk$ git grep -i bouffalo | wc -l
1042
bouffalo_sdk$ git grep -i bouffalolab | wc -l
179
So that is what we were using for bringing up Linux and U-Boot over at
https://github.com/openbouffalo.
On the other hand, "bouffalolab" is certainly accurate as well, so I understand if you prefer it. And we will of course adapt to whatever gets merged, since our goal is upstreaming.
The vendor code drop[1] provided only one example, "bflb-uart,uart0", which is not very helpful. Maybe you have received further information from them?
What do you think?
Regards,
Samuel
[1]:
https://github.com/bouffalolab/bl808_linux/blob/main/linux-5.10.4-808/drivers/tty/serial/bflb_uart.c#L700

Conor Dooley

2023-05-21 13:55 UTC #4 lore raw

Re: [PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

Quoted 32 lines · Jisheng Zhang

Quoted 18 lines · Samuel Holland
Hi Jisheng,
Thanks for updating this series!
Quoted 13 lines · Jisheng Zhang
In the following commits, we will support bl808 SoC which is from Bouffalo Lab Technology (Nanjing) Co., Ltd.
Add bouffalolab vendor prefix binding.
Link https://en.bouffalolab.com/
Signed-off-by Jisheng Zhang <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)
Quoted 12 lines
Documentation/devicetree/bindings/vendor-prefixes.yaml patternProperties: · line 204
Quoted 10 lines
Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0
index 82d39ab0231b..3566346f2f9e 100644
@@ -200,6 +200,8 @@ patternProperties:
     description: BOE Technology Group Co., Ltd.
   "^bosch,.*":
     description: Bosch Sensortec GmbH
+  "^bouffalolab,.*":
+    description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
Have you thought about using the "bflb" abbreviation as the vendor

Quoted 8 lines

I did think about bflb vs bouffalolab. Here is what I thought: I came across "marvell" vs "mrvl" sevral years ago, I got an impression "marvell" vendor prefix is preferred if I read the discussions correctly.
As for Bouffalolab vendor prefix, I have no preference, maybe DT maintainers can provide inputs here.
Rob, Conor, Krzysztof, what's your opinion?

I had a look through the blame for vendor-prefixes.yaml since I had no clue how easy it would be to find the marvell discussion - the commit for gateworks' deprecated entry (done by Krzysztof says "Favor the longer one (more descriptive)" & I think the same point is valid here. I would have no idea what "bflb" was if I came across it in isolation!

Cheers,
Conor.

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Rob Herring

maintainer Acked-by

2023-06-07 19:50 UTC #5 lore raw

Re: [PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

Quoted 32 lines · Jisheng Zhang

Quoted 18 lines · Samuel Holland
Hi Jisheng,
Thanks for updating this series!
Quoted 13 lines · Jisheng Zhang
In the following commits, we will support bl808 SoC which is from Bouffalo Lab Technology (Nanjing) Co., Ltd.
Add bouffalolab vendor prefix binding.
Link https://en.bouffalolab.com/
Signed-off-by Jisheng Zhang <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)
Quoted 12 lines
Documentation/devicetree/bindings/vendor-prefixes.yaml patternProperties: · line 204
Quoted 10 lines
Documentation/devicetree/bindings/vendor-prefixes.yaml +2 -0
index 82d39ab0231b..3566346f2f9e 100644
@@ -200,6 +200,8 @@ patternProperties:
     description: BOE Technology Group Co., Ltd.
   "^bosch,.*":
     description: Bosch Sensortec GmbH
+  "^bouffalolab,.*":
+    description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
Have you thought about using the "bflb" abbreviation as the vendor

Quoted 8 lines

I did think about bflb vs bouffalolab. Here is what I thought: I came across "marvell" vs "mrvl" sevral years ago, I got an impression "marvell" vendor prefix is preferred if I read the discussions correctly.
As for Bouffalolab vendor prefix, I have no preference, maybe DT maintainers can provide inputs here.
Rob, Conor, Krzysztof, what's your opinion?

The general preference is to match the vendor's domain name (minus the .com, etc.). Originally, the preference was stock ticker symbol, but we've pretty much moved away from that.

So that's 'bouffalolab'.

Acked-by Rob Herring <[email protected]>

Rob

Jisheng Zhang

author

2023-05-18 15:34 UTC #6 lore raw

PATCH v4 2/10 dt-bindings: interrupt-controller: Add bouffalolab bl808 plic

Add compatible string for bouffalolab bl808 plic.

---
 .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml         | 1 +
 1 file changed, 1 insertion(+)

Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +1 -0

index f75736a061af..3f9439b0c163 100644
@@ -65,6 +65,7 @@ properties:
       - items:
           - enum:
               - allwinner,sun20i-d1-plic
+              - bouffalolab,bl808-plic
           - const: thead,c900-plic
       - items:
           - const: sifive,plic-1.0.0

Signature · 1 line

2.40.0

Samuel Holland

Reviewed-by on v4 2/10

2023-05-19 03:36 UTC #7 lore raw

Re: [PATCH v4 02/10] dt-bindings: interrupt-controller: Add bouffalolab bl808 plic

Quoted 7 lines · Jisheng Zhang

Add compatible string for bouffalolab bl808 plic.
Signed-off-by Jisheng Zhang <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
---
 .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml         | 1 +
 1 file changed, 1 insertion(+)

Indeed, this is a T-HEAD C906. So ignoring the question I raised about the vendor prefix:

Reviewed-by Samuel Holland <[email protected]>

Quoted 12 lines

Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +1 -0

index f75736a061af..3f9439b0c163 100644
@@ -65,6 +65,7 @@ properties:
       - items:
           - enum:
               - allwinner,sun20i-d1-plic
+              - bouffalolab,bl808-plic
           - const: thead,c900-plic
       - items:
           - const: sifive,plic-1.0.0

Jisheng Zhang

author

2023-05-18 15:34 UTC #8 lore raw

PATCH v4 3/10 dt-bindings: serial: add documentation for Bouffalolab UART Driver

Add bindings doc for Bouffalolab UART Driver

---
 .../serial/bouffalolab,bl808-uart.yaml        | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml

Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml new file +47 -0

new file mode 100644
index 000000000000..0ef858e50efb
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Jisheng Zhang <[email protected]>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/bouffalolab,bl808-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalolab UART Controller
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+allOf:
+  - $ref: serial.yaml#
+
+properties:
+  compatible:
+    const: bouffalolab,bl808-uart
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    uart0: serial@30002000 {
+        compatible = "bouffalolab,bl808-uart";
+        reg = <0x30002000 0x1000>;
+        interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&xtal>;
+    };
+...

Signature · 7 lines

2.40.0


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Conor Dooley

Reviewed-by on v4 3/10

2023-05-18 19:35 UTC #9 lore raw

Re: [PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

Quoted 4 lines · Jisheng Zhang

Add bindings doc for Bouffalolab UART Driver
Signed-off-by Jisheng Zhang <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>

As I said previously, happy to grab the non-serial parts of the series once Greg (or Jiri?) pick the serial bits.

Cheers,
Conor.

Quoted 61 lines

---
 .../serial/bouffalolab,bl808-uart.yaml        | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml

Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml new file +47 -0

new file mode 100644
index 000000000000..0ef858e50efb
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Jisheng Zhang <[email protected]>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/bouffalolab,bl808-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalolab UART Controller
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+allOf:
+  - $ref: serial.yaml#
+
+properties:
+  compatible:
+    const: bouffalolab,bl808-uart
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    uart0: serial@30002000 {
+        compatible = "bouffalolab,bl808-uart";
+        reg = <0x30002000 0x1000>;
+        interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&xtal>;
+    };
+...

Signature · 1 line

2.40.0

Samuel Holland

2023-05-19 03:00 UTC #10 lore raw

Re: [PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

Hi Jisheng,

Quoted 32 lines · Jisheng Zhang

Add bindings doc for Bouffalolab UART Driver

---
 .../serial/bouffalolab,bl808-uart.yaml        | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml

Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml new file +17 -0

new file mode 100644
index 000000000000..0ef858e50efb
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Jisheng Zhang <[email protected]>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/bouffalolab,bl808-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalolab UART Controller
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+allOf:
+  - $ref: serial.yaml#
+
+properties:
+  compatible:

Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml line 27

Quoted 10 lines

Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml new file +10 -0
+    const: bouffalolab,bl808-uart
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1

This is not complete. There are separate APB and module (baud) clocks, as well as a peripheral reset line. If we are going to keep the binding stable, these need to be described up front.

(I still don't fully understand the clock tree, and so far that has been the main blocker for me sending a follow-up series with additional bindings for hardware that's otherwise already supported, like the Ethernet MAC.)

Regards,
Samuel

Quoted 20 lines

Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml new file +20 -0

+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    uart0: serial@30002000 {
+        compatible = "bouffalolab,bl808-uart";
+        reg = <0x30002000 0x1000>;
+        interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&xtal>;
+    };
+...

Jisheng Zhang

author

2023-05-21 09:24 UTC #11 lore raw

Re: [PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

Quoted 1 line · Samuel Holland

Hi Jisheng,

Hi Samuel,

Quoted 40 lines · Jisheng Zhang

Quoted 38 lines

Add bindings doc for Bouffalolab UART Driver

---
 .../serial/bouffalolab,bl808-uart.yaml        | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml

Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml new file +23 -0

new file mode 100644
index 000000000000..0ef858e50efb
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Jisheng Zhang <[email protected]>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/bouffalolab,bl808-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalolab UART Controller
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+allOf:
+  - $ref: serial.yaml#
+
+properties:
+  compatible:
+    const: bouffalolab,bl808-uart
+
+  reg:
+    maxItems: 1
+
+  interrupts:

Quoted 8 lines

Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml line 27
Quoted 4 lines
Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml new file +4 -0
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
This is not complete. There are separate APB and module (baud) clocks, as well as a peripheral reset line. If we are going to keep the binding stable, these need to be described up front.

IIUC, the only requirement is to keep the driver compatible with both new dts and old dts. clk tree and reset can be added latter. I have seen sevral such examples from other SoCs' mainline progress.

Quoted 30 lines

(I still don't fully understand the clock tree, and so far that has been the main blocker for me sending a follow-up series with additional bindings for hardware that's otherwise already supported, like the Ethernet MAC.)
Regards,
Samuel
Quoted 20 lines
Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml new file +20 -0
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    uart0: serial@30002000 {
+        compatible = "bouffalolab,bl808-uart";
+        reg = <0x30002000 0x1000>;
+        interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&xtal>;
+    };
+...

Conor Dooley

2023-05-22 07:13 UTC #12 lore raw

Re: [PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

Quoted 10 lines · Jisheng Zhang

Quoted 5 lines · Samuel Holland
On 5/18/23 10:22, Jisheng Zhang wrote:
This is not complete. There are separate APB and module (baud) clocks, as well as a peripheral reset line. If we are going to keep the binding stable, these need to be described up front.
IIUC, the only requirement is to keep the driver compatible with both new dts and old dts. clk tree and reset can be added latter. I have seen sevral such examples from other SoCs' mainline progress.

It is generally preferred to add bindings in as complete a state as possible. The driver doesn't need to actually make use of all of the properties though, and can add the other bits as if/when they are required.

Cheers,
Conor.

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Jisheng Zhang

author

2023-05-18 15:34 UTC #13 lore raw

PATCH v4 4/10 serial: bflb_uart: add Bouffalolab UART Driver

Add the driver for Bouffalolab UART IP which is found in Bouffalolab SoCs such as bl808.

UART driver probe will create path named "/dev/ttySx".

---
 drivers/tty/serial/Kconfig       |  18 +
 drivers/tty/serial/Makefile      |   1 +
 drivers/tty/serial/bflb_uart.c   | 586 +++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |   3 +
 4 files changed, 608 insertions(+)
 create mode 100644 drivers/tty/serial/bflb_uart.c

drivers/tty/serial/Kconfig +18 -0

index 398e5aac2e77..abc30a0713f5 100644
@@ -179,6 +179,24 @@ config SERIAL_ATMEL_TTYAT
 
 	  Say Y if you have an external 8250/16C550 UART.  If unsure, say N.
 
+config SERIAL_BFLB
+	tristate "Bouffalolab serial port support"
+	select SERIAL_CORE
+	depends on COMMON_CLK
+	help
+	  This enables the driver for the Bouffalolab's serial.
+
+config SERIAL_BFLB_CONSOLE
+	bool "Support for console on Bouffalolab serial port"
+	depends on SERIAL_BFLB=y
+	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
+	help
+	  Say Y here if you wish to use a Bouffalolab UART as the
+	  system console (the system console is the device which
+	  receives all kernel messages and warnings and which allows
+	  logins in single user mode) as /dev/ttySn.
+
 config SERIAL_KGDB_NMI
 	bool "Serial console over KGDB NMI debugger port"
 	depends on KGDB_SERIAL_CONSOLE

drivers/tty/serial/Makefile +1 -0

index cd9afd9e3018..5788a708d327 100644
@@ -25,6 +25,7 @@ obj-$(CONFIG_SERIAL_8250) += 8250/
 
 obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
 obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
+obj-$(CONFIG_SERIAL_BFLB) += bflb_uart.o
 obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
 obj-$(CONFIG_SERIAL_PXA_NON8250) += pxa.o
 obj-$(CONFIG_SERIAL_SA1100) += sa1100.o

drivers/tty/serial/bflb_uart.c new file +586 -0

586 lines not on this page · raw message

include/uapi/linux/serial_core.h +3 -0

index 281fa286555c..0651fcc8734f 100644
@@ -279,4 +279,7 @@
 /* Sunplus UART */
 #define PORT_SUNPLUS	123
 
+/* Bouffalolab UART */
+#define PORT_BFLB	124
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */

Signature · 7 lines

2.40.0


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Greg Kroah-Hartman

maintainer

2023-05-30 10:36 UTC #14 lore raw

Re: [PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

Quoted 2 lines · Jisheng Zhang

Add the driver for Bouffalolab UART IP which is found in Bouffalolab SoCs such as bl808.

New uarts are being created that are NOT 8250-like? Why????

Quoted 59 lines

UART driver probe will create path named "/dev/ttySx".

---
 drivers/tty/serial/Kconfig       |  18 +
 drivers/tty/serial/Makefile      |   1 +
 drivers/tty/serial/bflb_uart.c   | 586 +++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |   3 +
 4 files changed, 608 insertions(+)
 create mode 100644 drivers/tty/serial/bflb_uart.c

drivers/tty/serial/Kconfig +18 -0

index 398e5aac2e77..abc30a0713f5 100644
@@ -179,6 +179,24 @@ config SERIAL_ATMEL_TTYAT
 
 	  Say Y if you have an external 8250/16C550 UART.  If unsure, say N.
 
+config SERIAL_BFLB
+	tristate "Bouffalolab serial port support"
+	select SERIAL_CORE
+	depends on COMMON_CLK
+	help
+	  This enables the driver for the Bouffalolab's serial.
+
+config SERIAL_BFLB_CONSOLE
+	bool "Support for console on Bouffalolab serial port"
+	depends on SERIAL_BFLB=y
+	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
+	help
+	  Say Y here if you wish to use a Bouffalolab UART as the
+	  system console (the system console is the device which
+	  receives all kernel messages and warnings and which allows
+	  logins in single user mode) as /dev/ttySn.
+
 config SERIAL_KGDB_NMI
 	bool "Serial console over KGDB NMI debugger port"
 	depends on KGDB_SERIAL_CONSOLE

drivers/tty/serial/Makefile +1 -0

index cd9afd9e3018..5788a708d327 100644
@@ -25,6 +25,7 @@ obj-$(CONFIG_SERIAL_8250) += 8250/
 
 obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
 obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
+obj-$(CONFIG_SERIAL_BFLB) += bflb_uart.o
 obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
 obj-$(CONFIG_SERIAL_PXA_NON8250) += pxa.o
 obj-$(CONFIG_SERIAL_SA1100) += sa1100.o

drivers/tty/serial/bflb_uart.c new file +0 -0

new file mode 100644
index 000000000000..3f80bba8599a

drivers/tty/serial/bflb_uart.c line 5

Quoted 5 lines

drivers/tty/serial/bflb_uart.c new file +5 -0

@@ -0,0 +1,586 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Based on bflb_uart.c, by Bouffalolab team
+ *
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>

It is 2023 :)

Quoted 102 lines

drivers/tty/serial/bflb_uart.c new file +102 -0

+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+
+#define UART_UTX_CONFIG			0x00
+#define  UART_CR_UTX_EN			BIT(0)
+#define  UART_CR_UTX_CTS_EN		BIT(1)
+#define  UART_CR_UTX_FRM_EN		BIT(2)
+#define  UART_CR_UTX_PRT_EN		BIT(4)
+#define  UART_CR_UTX_PRT_SEL		BIT(5)
+#define  UART_CR_UTX_BIT_CNT_D_MSK	GENMASK(10, 8)
+#define  UART_CR_UTX_BIT_CNT_P_MSK	GENMASK(12, 11)
+#define UART_URX_CONFIG			0x04
+#define  UART_CR_URX_EN			BIT(0)
+#define  UART_CR_URX_PRT_EN		BIT(4)
+#define  UART_CR_URX_PRT_SEL		BIT(5)
+#define  UART_CR_URX_BIT_CNT_D_MSK	GENMASK(10, 8)
+#define UART_BIT_PRD			0x08
+#define  UART_CR_UTX_BIT_PRD_MSK	GENMASK(15, 0)
+#define  UART_CR_URX_BIT_PRD_MSK	GENMASK(31, 16)
+#define UART_DATA_CONFIG		0x0c
+#define  UART_CR_UART_BIT_INV		BIT(0)
+#define UART_URX_RTO_TIMER		0x18
+#define  UART_CR_URX_RTO_VALUE_MSK	GENMASK(7, 0)
+#define UART_SW_MODE			0x1c
+#define UART_INT_STS			0x20
+#define  UART_UTX_END_INT		BIT(0)
+#define  UART_URX_END_INT		BIT(1)
+#define  UART_UTX_FIFO_INT		BIT(2)
+#define  UART_URX_FIFO_INT		BIT(3)
+#define  UART_URX_RTO_INT		BIT(4)
+#define  UART_URX_PCE_INT		BIT(5)
+#define  UART_UTX_FER_INT		BIT(6)
+#define  UART_URX_FER_INT		BIT(7)
+#define  UART_URX_LSE_INT		BIT(8)
+#define UART_INT_MASK			0x24
+#define UART_INT_CLEAR			0x28
+#define UART_INT_EN			0x2c
+#define UART_STATUS			0x30
+#define  UART_STS_UTX_BUS_BUSY		BIT(0)
+#define UART_FIFO_CONFIG_0		0x80
+#define  UART_DMA_TX_EN			BIT(0)
+#define  UART_DMA_RX_EN			BIT(1)
+#define  UART_TX_FIFO_CLR		BIT(2)
+#define  UART_RX_FIFO_CLR		BIT(3)
+#define  UART_TX_FIFO_OVERFLOW		BIT(4)
+#define  UART_TX_FIFO_UNDERFLOW		BIT(5)
+#define  UART_RX_FIFO_OVERFLOW		BIT(6)
+#define  UART_RX_FIFO_UNDERFLOW		BIT(7)
+#define UART_FIFO_CONFIG_1		0x84
+#define  UART_TX_FIFO_CNT_MSK		GENMASK(5, 0)
+#define  UART_RX_FIFO_CNT_MSK		GENMASK(13, 8)
+#define  UART_TX_FIFO_TH_MSK		GENMASK(20, 16)
+#define  UART_RX_FIFO_TH_MSK		GENMASK(28, 24)
+#define UART_FIFO_WDATA			0x88
+#define UART_FIFO_RDATA			0x8c
+#define  UART_FIFO_RDATA_MSK		GENMASK(7, 0)
+
+#define BFLB_UART_MAXPORTS		8
+#define BFLB_UART_BAUD			2000000
+#define BFLB_UART_RX_FIFO_TH		7
+#define BFLB_UART_TX_FIFO_TH		15
+#define BFLB_UART_URX_RTO_TIME		0x4f
+
+struct bflb_uart_port {
+	struct uart_port port;
+	struct clk *clk;
+};
+
+static struct bflb_uart_port *bflb_uart_ports[BFLB_UART_MAXPORTS];
+
+static inline u32 rdl(struct uart_port *port, u32 reg)
+{
+	return readl_relaxed(port->membase + reg);
+}
+
+static inline void wrl(struct uart_port *port, u32 reg, u32 value)
+{
+	writel_relaxed(value, port->membase + reg);
+}
+
+static inline void wrb(struct uart_port *port, u32 reg, u8 value)
+{
+	writeb_relaxed(value, port->membase + reg);
+}
+
+static unsigned int bflb_uart_tx_empty(struct uart_port *port)
+{
+	return (rdl(port, UART_FIFO_CONFIG_1) & UART_TX_FIFO_CNT_MSK) ? TIOCSER_TEMT : 0;

drivers/tty/serial/bflb_uart.c line 117

Quoted 10 lines

drivers/tty/serial/bflb_uart.c new file +10 -0

+}
+
+static unsigned int bflb_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+}
+
+static void bflb_uart_set_mctrl(struct uart_port *port, unsigned int sigs)
+{
+}

Why is a blank function required here?

include/uapi/linux/serial_core.h line 283

Quoted 8 lines

include/uapi/linux/serial_core.h +2 -0

@@ -279,4 +279,7 @@
 /* Sunplus UART */
 #define PORT_SUNPLUS	123
 
+/* Bouffalolab UART */
+#define PORT_BFLB	124

Why is this required? What userspace code is going to need this?

thanks,

greg k-h

Jisheng Zhang

author

2023-05-31 14:21 UTC #15 lore raw

Re: [PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

Quoted 5 lines · Greg Kroah-Hartman

Quoted 2 lines · Jisheng Zhang
Add the driver for Bouffalolab UART IP which is found in Bouffalolab SoCs such as bl808.
New uarts are being created that are NOT 8250-like? Why????

Hi,

I'm not sure I understand your meaning. I guess you mean writing the new uart driver following 8250 style. And the latest example is sunplus-uart.c, it can be used as an example how to write a 8250 style driver for new non-8250 uart IP.

If the above guesses are wrong, could you please provide more details?

Thanks

Quoted 191 lines

Quoted 61 lines

UART driver probe will create path named "/dev/ttySx".

---
 drivers/tty/serial/Kconfig       |  18 +
 drivers/tty/serial/Makefile      |   1 +
 drivers/tty/serial/bflb_uart.c   | 586 +++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |   3 +
 4 files changed, 608 insertions(+)
 create mode 100644 drivers/tty/serial/bflb_uart.c

drivers/tty/serial/Kconfig +18 -0

index 398e5aac2e77..abc30a0713f5 100644
@@ -179,6 +179,24 @@ config SERIAL_ATMEL_TTYAT
 
 	  Say Y if you have an external 8250/16C550 UART.  If unsure, say N.
 
+config SERIAL_BFLB
+	tristate "Bouffalolab serial port support"
+	select SERIAL_CORE
+	depends on COMMON_CLK
+	help
+	  This enables the driver for the Bouffalolab's serial.
+
+config SERIAL_BFLB_CONSOLE
+	bool "Support for console on Bouffalolab serial port"
+	depends on SERIAL_BFLB=y
+	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
+	help
+	  Say Y here if you wish to use a Bouffalolab UART as the
+	  system console (the system console is the device which
+	  receives all kernel messages and warnings and which allows
+	  logins in single user mode) as /dev/ttySn.
+
 config SERIAL_KGDB_NMI
 	bool "Serial console over KGDB NMI debugger port"
 	depends on KGDB_SERIAL_CONSOLE

drivers/tty/serial/Makefile +1 -0

index cd9afd9e3018..5788a708d327 100644
@@ -25,6 +25,7 @@ obj-$(CONFIG_SERIAL_8250) += 8250/
 
 obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
 obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
+obj-$(CONFIG_SERIAL_BFLB) += bflb_uart.o
 obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
 obj-$(CONFIG_SERIAL_PXA_NON8250) += pxa.o
 obj-$(CONFIG_SERIAL_SA1100) += sa1100.o

drivers/tty/serial/bflb_uart.c new file +0 -0

new file mode 100644
index 000000000000..3f80bba8599a

drivers/tty/serial/bflb_uart.c line 5

Quoted 5 lines

drivers/tty/serial/bflb_uart.c new file +5 -0

@@ -0,0 +1,586 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Based on bflb_uart.c, by Bouffalolab team
+ *
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>

It is 2023 :)

Quoted 102 lines

drivers/tty/serial/bflb_uart.c new file +102 -0

+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+
+#define UART_UTX_CONFIG			0x00
+#define  UART_CR_UTX_EN			BIT(0)
+#define  UART_CR_UTX_CTS_EN		BIT(1)
+#define  UART_CR_UTX_FRM_EN		BIT(2)
+#define  UART_CR_UTX_PRT_EN		BIT(4)
+#define  UART_CR_UTX_PRT_SEL		BIT(5)
+#define  UART_CR_UTX_BIT_CNT_D_MSK	GENMASK(10, 8)
+#define  UART_CR_UTX_BIT_CNT_P_MSK	GENMASK(12, 11)
+#define UART_URX_CONFIG			0x04
+#define  UART_CR_URX_EN			BIT(0)
+#define  UART_CR_URX_PRT_EN		BIT(4)
+#define  UART_CR_URX_PRT_SEL		BIT(5)
+#define  UART_CR_URX_BIT_CNT_D_MSK	GENMASK(10, 8)
+#define UART_BIT_PRD			0x08
+#define  UART_CR_UTX_BIT_PRD_MSK	GENMASK(15, 0)
+#define  UART_CR_URX_BIT_PRD_MSK	GENMASK(31, 16)
+#define UART_DATA_CONFIG		0x0c
+#define  UART_CR_UART_BIT_INV		BIT(0)
+#define UART_URX_RTO_TIMER		0x18
+#define  UART_CR_URX_RTO_VALUE_MSK	GENMASK(7, 0)
+#define UART_SW_MODE			0x1c
+#define UART_INT_STS			0x20
+#define  UART_UTX_END_INT		BIT(0)
+#define  UART_URX_END_INT		BIT(1)
+#define  UART_UTX_FIFO_INT		BIT(2)
+#define  UART_URX_FIFO_INT		BIT(3)
+#define  UART_URX_RTO_INT		BIT(4)
+#define  UART_URX_PCE_INT		BIT(5)
+#define  UART_UTX_FER_INT		BIT(6)
+#define  UART_URX_FER_INT		BIT(7)
+#define  UART_URX_LSE_INT		BIT(8)
+#define UART_INT_MASK			0x24
+#define UART_INT_CLEAR			0x28
+#define UART_INT_EN			0x2c
+#define UART_STATUS			0x30
+#define  UART_STS_UTX_BUS_BUSY		BIT(0)
+#define UART_FIFO_CONFIG_0		0x80
+#define  UART_DMA_TX_EN			BIT(0)
+#define  UART_DMA_RX_EN			BIT(1)
+#define  UART_TX_FIFO_CLR		BIT(2)
+#define  UART_RX_FIFO_CLR		BIT(3)
+#define  UART_TX_FIFO_OVERFLOW		BIT(4)
+#define  UART_TX_FIFO_UNDERFLOW		BIT(5)
+#define  UART_RX_FIFO_OVERFLOW		BIT(6)
+#define  UART_RX_FIFO_UNDERFLOW		BIT(7)
+#define UART_FIFO_CONFIG_1		0x84
+#define  UART_TX_FIFO_CNT_MSK		GENMASK(5, 0)
+#define  UART_RX_FIFO_CNT_MSK		GENMASK(13, 8)
+#define  UART_TX_FIFO_TH_MSK		GENMASK(20, 16)
+#define  UART_RX_FIFO_TH_MSK		GENMASK(28, 24)
+#define UART_FIFO_WDATA			0x88
+#define UART_FIFO_RDATA			0x8c
+#define  UART_FIFO_RDATA_MSK		GENMASK(7, 0)
+
+#define BFLB_UART_MAXPORTS		8
+#define BFLB_UART_BAUD			2000000
+#define BFLB_UART_RX_FIFO_TH		7
+#define BFLB_UART_TX_FIFO_TH		15
+#define BFLB_UART_URX_RTO_TIME		0x4f
+
+struct bflb_uart_port {
+	struct uart_port port;
+	struct clk *clk;
+};
+
+static struct bflb_uart_port *bflb_uart_ports[BFLB_UART_MAXPORTS];
+
+static inline u32 rdl(struct uart_port *port, u32 reg)
+{
+	return readl_relaxed(port->membase + reg);
+}
+
+static inline void wrl(struct uart_port *port, u32 reg, u32 value)
+{
+	writel_relaxed(value, port->membase + reg);
+}
+
+static inline void wrb(struct uart_port *port, u32 reg, u8 value)
+{
+	writeb_relaxed(value, port->membase + reg);
+}
+
+static unsigned int bflb_uart_tx_empty(struct uart_port *port)
+{
+	return (rdl(port, UART_FIFO_CONFIG_1) & UART_TX_FIFO_CNT_MSK) ? TIOCSER_TEMT : 0;

drivers/tty/serial/bflb_uart.c line 117

Quoted 10 lines

drivers/tty/serial/bflb_uart.c new file +10 -0

+}
+
+static unsigned int bflb_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+}
+
+static void bflb_uart_set_mctrl(struct uart_port *port, unsigned int sigs)
+{
+}

Why is a blank function required here?

Quoted 6 lines

include/uapi/linux/serial_core.h +0 -0

@@ -279,4 +279,7 @@
 /* Sunplus UART */
 #define PORT_SUNPLUS	123

Quoted 8 lines

include/uapi/linux/serial_core.h line 283
Quoted 2 lines
include/uapi/linux/serial_core.h +2 -0
+/* Bouffalolab UART */
+#define PORT_BFLB	124
Why is this required? What userspace code is going to need this?
thanks,
greg k-h

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Greg Kroah-Hartman

maintainer

2023-05-31 14:34 UTC #16 lore raw

Re: [PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

Quoted 5 lines · Jisheng Zhang

Quoted 4 lines · Greg Kroah-Hartman
Quoted 2 lines · Jisheng Zhang
Add the driver for Bouffalolab UART IP which is found in Bouffalolab SoCs such as bl808.

Quoted 8 lines

Quoted 1 line
New uarts are being created that are NOT 8250-like? Why????
Hi,
I'm not sure I understand your meaning. I guess you mean writing the new uart driver following 8250 style. And the latest example is sunplus-uart.c, it can be used as an example how to write a 8250 style driver for new non-8250 uart IP.

No, I mean, "why are hardware designers creating new UARTs in 2023 that are NOT 8250-based"? Why do they want to constantly reinvent the wheel?

thanks,

greg k-h

Jisheng Zhang

author

2023-05-31 15:17 UTC #17 lore raw

Re: [PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

Quoted 10 lines · Greg Kroah-Hartman

Quoted 9 lines · Jisheng Zhang
Quoted 5 lines · Greg Kroah-Hartman
Quoted 2 lines · Jisheng Zhang
Add the driver for Bouffalolab UART IP which is found in Bouffalolab SoCs such as bl808.
New uarts are being created that are NOT 8250-like? Why????
Hi,

Quoted 7 lines

Quoted 4 lines
I'm not sure I understand your meaning. I guess you mean writing the new uart driver following 8250 style. And the latest example is sunplus-uart.c, it can be used as an example how to write a 8250 style driver for new non-8250 uart IP.
No, I mean, "why are hardware designers creating new UARTs in 2023 that are NOT 8250-based"? Why do they want to constantly reinvent the wheel?

haha, to be honest, I dunno the reason either. For me, the HW has been there and is linux capable, I want to mainline its support.

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Jisheng Zhang

author

2023-05-18 15:34 UTC #18 lore raw

PATCH v4 5/10 riscv: add the Bouffalolab SoC family Kconfig option

The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V GC compatible, so can run linux.

---
 arch/riscv/Kconfig.socs | 5 +++++
 1 file changed, 5 insertions(+)

arch/riscv/Kconfig.socs +5 -0

index 1cf69f958f10..33220b5144bb 100644
@@ -1,5 +1,10 @@
 menu "SoC selection"
 
+config ARCH_BOUFFALOLAB
+	bool "Bouffalolab SoCs"
+	help
+	  This enables support for Bouffalolab SoC platforms.
+
 config ARCH_MICROCHIP_POLARFIRE
 	def_bool SOC_MICROCHIP_POLARFIRE

Signature · 7 lines

2.40.0


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Jisheng Zhang

author

2023-05-18 15:34 UTC #19 lore raw

PATCH v4 6/10 dt-bindings: riscv: Add bouffalolab bl808 board compatibles

Several SoMs and boards are available that feature the Bouffalolab bl808 SoC. Document the compatible strings.

[1]: https://github.com/openbouffalo/u-boot/commit/3ca800850f30

---
 .../bindings/riscv/bouffalolab.yaml           | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml

Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +29 -0

new file mode 100644
index 000000000000..3b25d1a5d04a
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalo Lab Technology SoC-based boards
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+description:
+  Bouffalo Lab Technology SoC-based boards
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Carrier boards for the Sipeed M1s SoM
+        items:
+          - enum:
+              - sipeed,m1s-dock
+          - const: sipeed,m1s
+          - const: bouffalolab,bl808
+
+additionalProperties: true
+
+...

Signature · 7 lines

2.40.0


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Samuel Holland

2023-05-19 03:31 UTC #20 lore raw

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

Hi Jisheng, DT maintainers,

Quoted 32 lines · Jisheng Zhang

Several SoMs and boards are available that feature the Bouffalolab bl808 SoC. Document the compatible strings.
Signed-off-by Jisheng Zhang <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
---
 .../bindings/riscv/bouffalolab.yaml           | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +15 -0
new file mode 100644
index 000000000000..3b25d1a5d04a
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalo Lab Technology SoC-based boards
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+description:
+  Bouffalo Lab Technology SoC-based boards
+
+properties:

Documentation/devicetree/bindings/riscv/bouffalolab.yaml line 25

Quoted 10 lines

Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +10 -0

+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Carrier boards for the Sipeed M1s SoM
+        items:
+          - enum:
+              - sipeed,m1s-dock
+          - const: sipeed,m1s
+          - const: bouffalolab,bl808

As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V GC compatible, so can run linux."

I have also been running U-Boot and NOMMU Linux on the less powerful, but still quite fast, "M0" core. However, this core needs a different DTB because:
1) The CPU is different (T-HEAD E907 instead of C906).
2) The interrupt routing is completely different.
a. The M0 core contains a CLIC instead of a PLIC.
b. The peripherals in the SoC are split between two buses. Those
on one bus have their IRQs directly connected to M0, and share a multiplexed IRQ connection to D0; and vice versa for the other bus. So each bus's interrupt-parent needs to be swapped.

Using some preprocessor magic like we did for Allwinner and Renesas, I was able to share most of the SoC and board DTs between the cores[1]. However, this still ends up with two DTs for each board. So here are my questions:
- Is this acceptable?
- Is there precedent for how we should name the two board DTs?
- How does this affect the board and SoC compatible strings?
- Should there be a separate "bouffalolab,bl808-d0" in addition to

     "bouffalolab,bl808"?

- Is it acceptable to use the same board compatible string for both, since the _board_ part of the DT does not change, only things inside the SoC?

It would be possible to avoid having two DTs per board by guarding all of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong because you would end up with two totally incompatible DTBs named the same thing, depending on how the DTB was built.

Thoughts?

Regards,
Samuel

Conor Dooley

2023-05-19 11:55 UTC #21 lore raw

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

Quoted 1 line · Samuel Holland

Hi Jisheng, DT maintainers,

Sick, thanks for piping up Samuel!
Both Rob and Krzysztof are not around at the moment, so that probably leaves it up to me.. I'm adding Arnd in case he has a take here too.

Quoted 59 lines · Jisheng Zhang

Quoted 32 lines
Several SoMs and boards are available that feature the Bouffalolab bl808 SoC. Document the compatible strings.
Signed-off-by Jisheng Zhang <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
---
 .../bindings/riscv/bouffalolab.yaml           | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +15 -0
new file mode 100644
index 000000000000..3b25d1a5d04a
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalo Lab Technology SoC-based boards
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+description:
+  Bouffalo Lab Technology SoC-based boards
+
+properties:
Documentation/devicetree/bindings/riscv/bouffalolab.yaml line 25
Quoted 10 lines
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +10 -0
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Carrier boards for the Sipeed M1s SoM
+        items:
+          - enum:
+              - sipeed,m1s-dock
+          - const: sipeed,m1s
+          - const: bouffalolab,bl808
As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V GC compatible, so can run linux."
I have also been running U-Boot and NOMMU Linux on the less powerful, but still quite fast, "M0" core. However, this core needs a different DTB because:
1) The CPU is different (T-HEAD E907 instead of C906).
2) The interrupt routing is completely different.
a. The M0 core contains a CLIC instead of a PLIC.
b. The peripherals in the SoC are split between two buses. Those
on one bus have their IRQs directly connected to M0, and share a multiplexed IRQ connection to D0; and vice versa for the other bus. So each bus's interrupt-parent needs to be swapped.

Quoted 5 lines

Using some preprocessor magic like we did for Allwinner and Renesas, I was able to share most of the SoC and board DTs between the cores[1]. However, this still ends up with two DTs for each board. So here are my questions:
- Is this acceptable?

I expected it to look worse than it actually turned out to be. I don't think Krzysztof in particular is a fan of having conditional bits in dts files, but for the shared arm/riscv stuff there was not really another sensible option.

Quoted 1 line

- Is there precedent for how we should name the two board DTs?

Arnd might have some idea about precedent here, but I like your naming well enough.

Quoted 3 lines

- How does this affect the board and SoC compatible strings?
- Should there be a separate "bouffalolab,bl808-d0" in addition to
     "bouffalolab,bl808"?

What ordering were you intending here? "pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"?

That doesn't really seem correct though, as it does not get less specific as you move right.

"pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem right either though, for the same sort of reason.

Quoted 3 lines

- Is it acceptable to use the same board compatible string for both, since the _board_ part of the DT does not change, only things inside the SoC?

I think you may need to have 2 compatibles per board, depending on which cpu. Perhaps even as verbose as:
"pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808"

Not exactly straightforward though, is it!

Quoted 4 lines

It would be possible to avoid having two DTs per board by guarding all of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong because you would end up with two totally incompatible DTBs named the same thing, depending on how the DTB was built.

I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof complain previously about conditional bits like that.

Cheers,
Conor.

Jisheng Zhang

author

2023-05-21 09:40 UTC #22 lore raw

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

Quoted 57 lines · Conor Dooley

Quoted 1 line · Samuel Holland
Hi Jisheng, DT maintainers,
Sick, thanks for piping up Samuel!
Both Rob and Krzysztof are not around at the moment, so that probably leaves it up to me.. I'm adding Arnd in case he has a take here too.
Quoted 50 lines · Jisheng Zhang
Quoted 32 lines
Several SoMs and boards are available that feature the Bouffalolab bl808 SoC. Document the compatible strings.
Signed-off-by Jisheng Zhang <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
---
 .../bindings/riscv/bouffalolab.yaml           | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +15 -0
new file mode 100644
index 000000000000..3b25d1a5d04a
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalo Lab Technology SoC-based boards
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+description:
+  Bouffalo Lab Technology SoC-based boards
+
+properties:
Documentation/devicetree/bindings/riscv/bouffalolab.yaml line 25
Quoted 10 lines
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +10 -0
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Carrier boards for the Sipeed M1s SoM
+        items:
+          - enum:
+              - sipeed,m1s-dock
+          - const: sipeed,m1s
+          - const: bouffalolab,bl808
As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V GC compatible, so can run linux."
I have also been running U-Boot and NOMMU Linux on the less powerful, but still quite fast, "M0" core. However, this core needs a different

Just FYI, I successfully ran nommu rv32 linux kernel on the "M0" core with some patches to the riscv head and irqchip driver.

Quoted 29 lines

Quoted 9 lines
DTB because:
1) The CPU is different (T-HEAD E907 instead of C906).
2) The interrupt routing is completely different.
a. The M0 core contains a CLIC instead of a PLIC.
b. The peripherals in the SoC are split between two buses. Those
on one bus have their IRQs directly connected to M0, and share a multiplexed IRQ connection to D0; and vice versa for the other bus. So each bus's interrupt-parent needs to be swapped.
Quoted 5 lines
Using some preprocessor magic like we did for Allwinner and Renesas, I was able to share most of the SoC and board DTs between the cores[1]. However, this still ends up with two DTs for each board. So here are my questions:
- Is this acceptable?
I expected it to look worse than it actually turned out to be. I don't think Krzysztof in particular is a fan of having conditional bits in dts files, but for the shared arm/riscv stuff there was not really another sensible option.
Quoted 1 line
- Is there precedent for how we should name the two board DTs?
Arnd might have some idea about precedent here, but I like your naming well enough.
Quoted 3 lines
- How does this affect the board and SoC compatible strings?
- Should there be a separate "bouffalolab,bl808-d0" in addition to
     "bouffalolab,bl808"?

Quoted 12 lines

What ordering were you intending here? "pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"?
That doesn't really seem correct though, as it does not get less specific as you move right.
"pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem right either though, for the same sort of reason.
Quoted 3 lines
- Is it acceptable to use the same board compatible string for both, since the _board_ part of the DT does not change, only things inside the SoC?

what about describing the DT as the SoC is, e.g

lp: cpu@0 {
	...
	status = disabled;
};

m0: cpu@1 {
	...
	status = disabled;
};

d0: cpu@2 {
	...
	status = disabled;
};

Then in m0 dts:

&m0 {
	status = okay;
};

in d0 dts:

&m0 {
	status = okay;
};

Quoted 17 lines

I think you may need to have 2 compatibles per board, depending on which cpu. Perhaps even as verbose as:
"pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808"
Not exactly straightforward though, is it!
Quoted 4 lines
It would be possible to avoid having two DTs per board by guarding all of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong because you would end up with two totally incompatible DTBs named the same thing, depending on how the DTB was built.
I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof complain previously about conditional bits like that.
Cheers,
Conor.

Jisheng Zhang

author

2023-05-21 09:56 UTC #23 lore raw

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

Quoted 120 lines · Jisheng Zhang

Quoted 57 lines · Conor Dooley
Quoted 1 line · Samuel Holland
Hi Jisheng, DT maintainers,
Sick, thanks for piping up Samuel!
Both Rob and Krzysztof are not around at the moment, so that probably leaves it up to me.. I'm adding Arnd in case he has a take here too.
Quoted 50 lines · Jisheng Zhang
Quoted 32 lines
Several SoMs and boards are available that feature the Bouffalolab bl808 SoC. Document the compatible strings.
Signed-off-by Jisheng Zhang <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
---
 .../bindings/riscv/bouffalolab.yaml           | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +15 -0
new file mode 100644
index 000000000000..3b25d1a5d04a
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalo Lab Technology SoC-based boards
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+description:
+  Bouffalo Lab Technology SoC-based boards
+
+properties:
Documentation/devicetree/bindings/riscv/bouffalolab.yaml line 25
Quoted 10 lines
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +10 -0
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Carrier boards for the Sipeed M1s SoM
+        items:
+          - enum:
+              - sipeed,m1s-dock
+          - const: sipeed,m1s
+          - const: bouffalolab,bl808
As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V GC compatible, so can run linux."
I have also been running U-Boot and NOMMU Linux on the less powerful, but still quite fast, "M0" core. However, this core needs a different
Just FYI, I successfully ran nommu rv32 linux kernel on the "M0" core with some patches to the riscv head and irqchip driver.
Quoted 29 lines
Quoted 9 lines
DTB because:
1) The CPU is different (T-HEAD E907 instead of C906).
2) The interrupt routing is completely different.
a. The M0 core contains a CLIC instead of a PLIC.
b. The peripherals in the SoC are split between two buses. Those
on one bus have their IRQs directly connected to M0, and share a multiplexed IRQ connection to D0; and vice versa for the other bus. So each bus's interrupt-parent needs to be swapped.
Quoted 5 lines
Using some preprocessor magic like we did for Allwinner and Renesas, I was able to share most of the SoC and board DTs between the cores[1]. However, this still ends up with two DTs for each board. So here are my questions:
- Is this acceptable?
I expected it to look worse than it actually turned out to be. I don't think Krzysztof in particular is a fan of having conditional bits in dts files, but for the shared arm/riscv stuff there was not really another sensible option.
Quoted 1 line
- Is there precedent for how we should name the two board DTs?
Arnd might have some idea about precedent here, but I like your naming well enough.
Quoted 3 lines
- How does this affect the board and SoC compatible strings?
- Should there be a separate "bouffalolab,bl808-d0" in addition to
     "bouffalolab,bl808"?
Quoted 12 lines
What ordering were you intending here? "pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"?
That doesn't really seem correct though, as it does not get less specific as you move right.
"pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem right either though, for the same sort of reason.
Quoted 3 lines
- Is it acceptable to use the same board compatible string for both, since the _board_ part of the DT does not change, only things inside the SoC?
what about describing the DT as the SoC is, e.g
lp: cpu@0 {
	...
	status = disabled;
};
m0: cpu@1 {
	...
	status = disabled;
};
d0: cpu@2 {
	...
	status = disabled;
};

Quoted 7 lines

Then in m0 dts:
&m0 {
	status = okay;
};
in d0 dts:
&m0 {

typo:

&d0 {

Quoted 23 lines

	status = okay;
};
Quoted 17 lines
I think you may need to have 2 compatibles per board, depending on which cpu. Perhaps even as verbose as:
"pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808"
Not exactly straightforward though, is it!
Quoted 4 lines
It would be possible to avoid having two DTs per board by guarding all of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong because you would end up with two totally incompatible DTBs named the same thing, depending on how the DTB was built.
I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof complain previously about conditional bits like that.
Cheers,
Conor.

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Rob Herring

maintainer

2023-06-07 20:04 UTC #24 lore raw

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

In reply to Samuel Holland

Quoted 50 lines · Samuel Holland

Hi Jisheng, DT maintainers,
Quoted 32 lines · Jisheng Zhang
Several SoMs and boards are available that feature the Bouffalolab bl808 SoC. Document the compatible strings.
Signed-off-by Jisheng Zhang <[email protected]>
Acked-by Palmer Dabbelt <[email protected]>
Reviewed-by Conor Dooley <[email protected]>
---
 .../bindings/riscv/bouffalolab.yaml           | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +15 -0
new file mode 100644
index 000000000000..3b25d1a5d04a
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalo Lab Technology SoC-based boards
+
+maintainers:
+  - Jisheng Zhang <[email protected]>
+
+description:
+  Bouffalo Lab Technology SoC-based boards
+
+properties:
Documentation/devicetree/bindings/riscv/bouffalolab.yaml line 25
Quoted 10 lines
Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file +10 -0
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Carrier boards for the Sipeed M1s SoM
+        items:
+          - enum:
+              - sipeed,m1s-dock
+          - const: sipeed,m1s
+          - const: bouffalolab,bl808
As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V GC compatible, so can run linux."

Quoted 10 lines

I have also been running U-Boot and NOMMU Linux on the less powerful, but still quite fast, "M0" core. However, this core needs a different DTB because:
1) The CPU is different (T-HEAD E907 instead of C906).
2) The interrupt routing is completely different.
a. The M0 core contains a CLIC instead of a PLIC.
b. The peripherals in the SoC are split between two buses. Those
on one bus have their IRQs directly connected to M0, and share a multiplexed IRQ connection to D0; and vice versa for the other bus. So each bus's interrupt-parent needs to be swapped.

Can't you include the dts file and then just override 'interrupt-parent'?

Quoted 9 lines

Using some preprocessor magic like we did for Allwinner and Renesas, I was able to share most of the SoC and board DTs between the cores[1]. However, this still ends up with two DTs for each board. So here are my questions:
- Is this acceptable?
- Is there precedent for how we should name the two board DTs?
- How does this affect the board and SoC compatible strings?
- Should there be a separate "bouffalolab,bl808-d0" in addition to
     "bouffalolab,bl808"?

Probably. A DT is ultimately the view of the hardware from a CPU's perspective. Different views, different compatibles.

Quoted 3 lines

- Is it acceptable to use the same board compatible string for both, since the _board_ part of the DT does not change, only things inside the SoC?

Yes.

Quoted 5 lines

It would be possible to avoid having two DTs per board by guarding all of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong because you would end up with two totally incompatible DTBs named the same thing, depending on how the DTB was built.

You can't have CONFIG_ options in .dts files.

Rob

Jisheng Zhang

author

2023-05-18 15:34 UTC #25 lore raw

PATCH v4 7/10 riscv: dts: bouffalolab: add the bl808 SoC base device tree

Add a baisc dtsi for the bouffalolab bl808 SoC.

---
 arch/riscv/boot/dts/bouffalolab/bl808.dtsi | 73 ++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808.dtsi

arch/riscv/boot/dts/bouffalolab/bl808.dtsi new file +73 -0

new file mode 100644
index 000000000000..87906fe51db5
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	compatible = "bouffalolab,bl808";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		timebase-frequency = <1000000>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			compatible = "thead,c906", "riscv";
+			device_type = "cpu";
+			reg = <0>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <256>;
+			d-cache-size = <32768>;
+			i-cache-block-size = <64>;
+			i-cache-sets = <128>;
+			i-cache-size = <32768>;
+			mmu-type = "riscv,sv39";
+			riscv,isa = "rv64imafdc";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#address-cells = <0>;
+				#interrupt-cells = <1>;
+			};
+		};
+	};
+
+	xtal: xtal-clk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		/* This value must be overridden by the board */
+		clock-frequency = <0>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		ranges;
+		interrupt-parent = <&plic>;
+		dma-noncoherent;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		uart3: serial@30002000 {
+			compatible = "bouffalolab,bl808-uart";
+			reg = <0x30002000 0x1000>;
+			interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&xtal>;
+			status = "disabled";
+		};
+
+		plic: interrupt-controller@e0000000 {
+			compatible = "bouffalolab,bl808-plic", "thead,c900-plic";
+			reg = <0xe0000000 0x4000000>;
+			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <2>;
+			riscv,ndev = <82>;
+		};
+	};
+};

Signature · 7 lines

2.40.0


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Samuel Holland

2023-05-19 03:51 UTC #26 lore raw

Re: [PATCH v4 07/10] riscv: dts: bouffalolab: add the bl808 SoC base device tree

Hi Jisheng,

Quoted 64 lines · Jisheng Zhang

Add a baisc dtsi for the bouffalolab bl808 SoC.

[1]: https://github.com/openbouffalo/u-boot/commit/3ca800850f30
[2]: https://github.com/openbouffalo/u-boot/commits/bl808/clk-reset

---
 arch/riscv/boot/dts/bouffalolab/bl808.dtsi | 73 ++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808.dtsi

arch/riscv/boot/dts/bouffalolab/bl808.dtsi new file +49 -0

new file mode 100644
index 000000000000..87906fe51db5
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	compatible = "bouffalolab,bl808";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		timebase-frequency = <1000000>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			compatible = "thead,c906", "riscv";
+			device_type = "cpu";
+			reg = <0>;
+			d-cache-block-size = <64>;
+			d-cache-sets = <256>;
+			d-cache-size = <32768>;
+			i-cache-block-size = <64>;
+			i-cache-sets = <128>;
+			i-cache-size = <32768>;
+			mmu-type = "riscv,sv39";
+			riscv,isa = "rv64imafdc";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#address-cells = <0>;
+				#interrupt-cells = <1>;
+			};
+		};
+	};
+
+	xtal: xtal-clk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		/* This value must be overridden by the board */
+		clock-frequency = <0>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		ranges;

arch/riscv/boot/dts/bouffalolab/bl808.dtsi line 59

Quoted 10 lines

arch/riscv/boot/dts/bouffalolab/bl808.dtsi new file +10 -0

+		interrupt-parent = <&plic>;
+		dma-noncoherent;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		uart3: serial@30002000 {
+			compatible = "bouffalolab,bl808-uart";
+			reg = <0x30002000 0x1000>;
+			interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&xtal>;

This isn't strictly accurate, and gives you the right frequency if you are using the vendor "low_load" bootloader. Without that (e.g. when loading U-Boot directly from the boot ROM), the routing is:

MM_MUXPLL_160M / 1 => MM_BCLK1X
MM_BCLK1X / 1 => MM_UART

So this UART module clock is 160 MHz, not 40 MHz.

The way to make this work reliably is to add drivers for the clock tree (from the preliminary work at [1][2], we'll need at least five of them), but that is a huge effort, so I'm not sure what we want to do for now.

Regards,
Samuel

Quoted 14 lines

arch/riscv/boot/dts/bouffalolab/bl808.dtsi new file +14 -0

+			status = "disabled";
+		};
+
+		plic: interrupt-controller@e0000000 {
+			compatible = "bouffalolab,bl808-plic", "thead,c900-plic";
+			reg = <0xe0000000 0x4000000>;
+			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <2>;
+			riscv,ndev = <82>;
+		};
+	};
+};

Jisheng Zhang

author

2023-05-18 15:34 UTC #27 lore raw

PATCH v4 8/10 riscv: dts: bouffalolab: add Sipeed M1s SoM and Dock devicetree

Sipeed manufactures a M1s system-on-module and dock board, add basic support for them.

---
 arch/riscv/boot/dts/Makefile                  |  1 +
 arch/riscv/boot/dts/bouffalolab/Makefile      |  2 ++
 .../dts/bouffalolab/bl808-sipeed-m1s-dock.dts | 25 +++++++++++++++++++
 .../dts/bouffalolab/bl808-sipeed-m1s.dtsi     | 21 ++++++++++++++++
 4 files changed, 49 insertions(+)
 create mode 100644 arch/riscv/boot/dts/bouffalolab/Makefile
 create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
 create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi

arch/riscv/boot/dts/Makefile +1 -0

index f0d9f89054f8..133e6c38c9b0 100644
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 subdir-y += allwinner
+subdir-y += bouffalolab
 subdir-y += sifive
 subdir-y += starfive
 subdir-y += canaan

arch/riscv/boot/dts/bouffalolab/Makefile new file +2 -0

new file mode 100644
index 000000000000..5419964e892d
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_BOUFFALOLAB) += bl808-sipeed-m1s-dock.dtb

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts new file +25 -0

new file mode 100644
index 000000000000..aa6cf909cd4d
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "bl808-sipeed-m1s.dtsi"
+
+/ {
+	model = "Sipeed M1s Dock";
+	compatible = "sipeed,m1s-dock", "sipeed,m1s", "bouffalolab,bl808";
+
+	aliases {
+		serial3 = &uart3;
+	};
+
+	chosen {
+		stdout-path = "serial3:2000000n8";
+	};
+};
+
+&uart3 {
+	status = "okay";
+};

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi new file +21 -0

new file mode 100644
index 000000000000..5026de768534
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "bl808.dtsi"
+
+/ {
+	compatible = "sipeed,m1s", "bouffalolab,bl808";
+
+	memory@50000000 {
+		device_type = "memory";
+		reg = <0x50000000 0x04000000>;
+	};
+};
+
+&xtal {
+	clock-frequency = <40000000>;
+};

Signature · 7 lines

2.40.0


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Samuel Holland

2023-05-19 03:55 UTC #28 lore raw

Re: [PATCH v4 08/10] riscv: dts: bouffalolab: add Sipeed M1s SoM and Dock devicetree

Hi Jisheng,

Quoted 77 lines · Jisheng Zhang

Sipeed manufactures a M1s system-on-module and dock board, add basic support for them.

---
 arch/riscv/boot/dts/Makefile                  |  1 +
 arch/riscv/boot/dts/bouffalolab/Makefile      |  2 ++
 .../dts/bouffalolab/bl808-sipeed-m1s-dock.dts | 25 +++++++++++++++++++
 .../dts/bouffalolab/bl808-sipeed-m1s.dtsi     | 21 ++++++++++++++++
 4 files changed, 49 insertions(+)
 create mode 100644 arch/riscv/boot/dts/bouffalolab/Makefile
 create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
 create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi

arch/riscv/boot/dts/Makefile +1 -0

index f0d9f89054f8..133e6c38c9b0 100644
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 subdir-y += allwinner
+subdir-y += bouffalolab
 subdir-y += sifive
 subdir-y += starfive
 subdir-y += canaan

arch/riscv/boot/dts/bouffalolab/Makefile new file +2 -0

new file mode 100644
index 000000000000..5419964e892d
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_BOUFFALOLAB) += bl808-sipeed-m1s-dock.dtb

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts new file +25 -0

new file mode 100644
index 000000000000..aa6cf909cd4d
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "bl808-sipeed-m1s.dtsi"
+
+/ {
+	model = "Sipeed M1s Dock";
+	compatible = "sipeed,m1s-dock", "sipeed,m1s", "bouffalolab,bl808";
+
+	aliases {
+		serial3 = &uart3;
+	};
+
+	chosen {
+		stdout-path = "serial3:2000000n8";
+	};
+};
+
+&uart3 {
+	status = "okay";
+};

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi new file +6 -0

new file mode 100644
index 000000000000..5026de768534
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi line 16

Quoted 10 lines

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi new file +10 -0

+
+#include "bl808.dtsi"
+
+/ {
+	compatible = "sipeed,m1s", "bouffalolab,bl808";
+
+	memory@50000000 {
+		device_type = "memory";
+		reg = <0x50000000 0x04000000>;
+	};

Especially since the SoC contains three heterogeneous CPUs, the firmware may want to divide the PSRAM among them, so I do not think it is a good idea to define this statically. (Or would all of the DTs contain this same node, and then use reserved-memory nodes to cover the other CPUs' allocations?)

Regards,
Samuel

Quoted 5 lines

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi new file +5 -0
+};
+
+&xtal {
+	clock-frequency = <40000000>;
+};

Jisheng Zhang

author

2023-05-21 09:52 UTC #29 lore raw

Re: [PATCH v4 08/10] riscv: dts: bouffalolab: add Sipeed M1s SoM and Dock devicetree

Quoted 86 lines · Samuel Holland

Hi Jisheng,

Quoted 83 lines · Jisheng Zhang

Sipeed manufactures a M1s system-on-module and dock board, add basic support for them.

---
 arch/riscv/boot/dts/Makefile                  |  1 +
 arch/riscv/boot/dts/bouffalolab/Makefile      |  2 ++
 .../dts/bouffalolab/bl808-sipeed-m1s-dock.dts | 25 +++++++++++++++++++
 .../dts/bouffalolab/bl808-sipeed-m1s.dtsi     | 21 ++++++++++++++++
 4 files changed, 49 insertions(+)
 create mode 100644 arch/riscv/boot/dts/bouffalolab/Makefile
 create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
 create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi

arch/riscv/boot/dts/Makefile +1 -0

index f0d9f89054f8..133e6c38c9b0 100644
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 subdir-y += allwinner
+subdir-y += bouffalolab
 subdir-y += sifive
 subdir-y += starfive
 subdir-y += canaan

arch/riscv/boot/dts/bouffalolab/Makefile new file +2 -0

new file mode 100644
index 000000000000..5419964e892d
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_BOUFFALOLAB) += bl808-sipeed-m1s-dock.dtb

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts new file +25 -0

new file mode 100644
index 000000000000..aa6cf909cd4d
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "bl808-sipeed-m1s.dtsi"
+
+/ {
+	model = "Sipeed M1s Dock";
+	compatible = "sipeed,m1s-dock", "sipeed,m1s", "bouffalolab,bl808";
+
+	aliases {
+		serial3 = &uart3;
+	};
+
+	chosen {
+		stdout-path = "serial3:2000000n8";
+	};
+};
+
+&uart3 {
+	status = "okay";
+};

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi new file +12 -0

new file mode 100644
index 000000000000..5026de768534
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "bl808.dtsi"
+
+/ {
+	compatible = "sipeed,m1s", "bouffalolab,bl808";
+

Quoted 8 lines

arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi line 16
Quoted 4 lines
arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi new file +4 -0
+	memory@50000000 {
+		device_type = "memory";
+		reg = <0x50000000 0x04000000>;
+	};
Especially since the SoC contains three heterogeneous CPUs, the firmware may want to divide the PSRAM among them, so I do not think it is a good idea to define this statically. (Or would all of the DTs contain this

do you want the bootloader/firmware e.g uboot to add the memory node dynamically?

But to be honest, nowdays most SoCs contain some heterogeneous CPUs, and in real products some of those CPUs need to use DDR memory. FWICT, their dtbs(in arch/arm64/boot/dts/...) still define the memory statically. I believe this is acchieved by dynamically update the memory node of DT. This solution doesn't make obvious difference with the uboot adding memory node solution.

Quoted 12 lines

same node, and then use reserved-memory nodes to cover the other CPUs' allocations?)
Regards,
Samuel
arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi line 21
Quoted 5 lines
arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi new file +5 -0
+};
+
+&xtal {
+	clock-frequency = <40000000>;
+};

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Jisheng Zhang

author

2023-05-18 15:34 UTC #30 lore raw

PATCH v4 9/10 MAINTAINERS: riscv: add entry for Bouffalolab SoC

Add Jisheng Zhang as Bouffalolab SoC maintainer.

---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

MAINTAINERS +7 -0

index e0ad886d3163..0ae136f2656f 100644
@@ -18115,6 +18115,13 @@ F:	arch/riscv/
 N:	riscv
 K:	riscv
 
+RISC-V BOUFFALOLAB SOC SUPPORT
+M:	Jisheng Zhang <[email protected]>
+L:	[email protected]
+S:	Maintained
+F:	arch/riscv/boot/dts/bouffalolab/
+F:	drivers/tty/serial/bflb_uart.c
+
 RISC-V MICROCHIP FPGA SUPPORT
 M:	Conor Dooley <[email protected]>
 M:	Daire McNamara <[email protected]>

Signature · 7 lines

2.40.0


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Jisheng Zhang

author

2023-05-18 15:34 UTC #31 lore raw

PATCH v4 10/10 riscv: defconfig: enable BOUFFALOLAB SoC

Enable BOUFFALOLAB soc config in defconfig to allow the default upstream kernel to boot on Sipeed M1s Dock board.