OpenRISC de0 nano single and multicore boards

Acked-by Conor Dooley <[email protected]>

pw-bot: not-applicable

In FPGA Development boards with GPIOs we use the opencores gpio verilog rtl. This is compatible with the gpio-mmio. Add the compatible string to allow as below.

Example:

        gpio0: gpio@91000000 {
                compatible = "opencores,gpio", "brcm,bcm6345-gpio";
                reg = <0x91000000 0x1>, <0x91000001 0x1>;
                reg-names = "dat", "dirout";
                gpio-controller;
                #gpio-cells = <2>;
                status = "okay";
        };

Link https://opencores.org/projects/gpio

Signed-off-by Stafford Horne <[email protected]>

In FPGA Development boards with GPIOs we use the opencores gpio verilog rtl. This is compatible with the gpio-mmio. Add the compatible string to allow as below.

Example:

        gpio0: gpio@91000000 {
                compatible = "opencores,gpio", "brcm,bcm6345-gpio";
                reg = <0x91000000 0x1>, <0x91000001 0x1>;
                reg-names = "dat", "dirout";
                gpio-controller;
                #gpio-cells = <2>;
                status = "okay";
        };

Link https://opencores.org/projects/gpio

Signed-off-by Stafford Horne <[email protected]>

Documentation/devicetree/bindings/gpio/gpio-mmio.yaml +0 -5

@@ -18,11 +18,16 @@ description:
 
 properties:
   compatible:
-    enum:
-      - brcm,bcm6345-gpio
-      - ni,169445-nand-gpio
-      - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
-      - intel,ixp4xx-expansion-bus-mmio-gpio

Hi Stafford,

Quoted 15 lines · Stafford Horne

In FPGA Development boards with GPIOs we use the opencores gpio verilog rtl. This is compatible with the gpio-mmio. Add the compatible string to allow as below.

Example:

        gpio0: gpio@91000000 {
                compatible = "opencores,gpio", "brcm,bcm6345-gpio";
                reg = <0x91000000 0x1>, <0x91000001 0x1>;
                reg-names = "dat", "dirout";
                gpio-controller;
                #gpio-cells = <2>;
                status = "okay";
        };

Quoted 2 lines

Link https://opencores.org/projects/gpio

Signed-off-by Stafford Horne <[email protected]>

Thanks for your patch, which is now commit f48b5e8bc2e1344f ("dt-bindings: gpio-mmio: Add compatible string for opencores,gpio") in gpio/gpio/for-next.

Quoted 17 lines

Documentation/devicetree/bindings/gpio/gpio-mmio.yaml +6 -5

@@ -18,11 +18,16 @@ description:
 
 properties:
   compatible:
-    enum:
-      - brcm,bcm6345-gpio
-      - ni,169445-nand-gpio
-      - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
-      - intel,ixp4xx-expansion-bus-mmio-gpio
+    oneOf:
+      - enum:
+          - brcm,bcm6345-gpio
+          - ni,169445-nand-gpio
+          - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
+          - intel,ixp4xx-expansion-bus-mmio-gpio

Documentation/devicetree/bindings/gpio/gpio-mmio.yaml description: · line 30

Quoted 4 lines

Documentation/devicetree/bindings/gpio/gpio-mmio.yaml +4 -0

+      - items:
+          - enum:
+              - opencores,gpio
+          - const: brcm,bcm6345-gpio

What is the rationale behind using brcm,bcm6345-gpio?
Given brcm,bcm6345-gpio has 32-bit registers, while opencores,gpio has 8-bit registers, I doubt the latter is compatible with the former...

Quoted 40 lines · Geert Uytterhoeven

Quoted 15 lines · Stafford Horne

In FPGA Development boards with GPIOs we use the opencores gpio verilog rtl. This is compatible with the gpio-mmio. Add the compatible string to allow as below.

Example:

        gpio0: gpio@91000000 {
                compatible = "opencores,gpio", "brcm,bcm6345-gpio";
                reg = <0x91000000 0x1>, <0x91000001 0x1>;
                reg-names = "dat", "dirout";
                gpio-controller;
                #gpio-cells = <2>;
                status = "okay";
        };

Quoted 2 lines

Link https://opencores.org/projects/gpio

Signed-off-by Stafford Horne <[email protected]>

Thanks for your patch, which is now commit f48b5e8bc2e1344f ("dt-bindings: gpio-mmio: Add compatible string for opencores,gpio") in gpio/gpio/for-next.

Quoted 17 lines

Documentation/devicetree/bindings/gpio/gpio-mmio.yaml +6 -5

@@ -18,11 +18,16 @@ description:
 
 properties:
   compatible:
-    enum:
-      - brcm,bcm6345-gpio
-      - ni,169445-nand-gpio
-      - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
-      - intel,ixp4xx-expansion-bus-mmio-gpio
+    oneOf:
+      - enum:
+          - brcm,bcm6345-gpio
+          - ni,169445-nand-gpio
+          - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
+          - intel,ixp4xx-expansion-bus-mmio-gpio

Quoted 8 lines

Documentation/devicetree/bindings/gpio/gpio-mmio.yaml description: · line 30

Quoted 4 lines

Documentation/devicetree/bindings/gpio/gpio-mmio.yaml +4 -0

+      - items:
+          - enum:
+              - opencores,gpio
+          - const: brcm,bcm6345-gpio

What is the rationale behind using brcm,bcm6345-gpio?
Given brcm,bcm6345-gpio has 32-bit registers, while opencores,gpio has 8-bit registers, I doubt the latter is compatible with the former...

I was following what we did for uart, where we have "opencores,uart16550-rtlsvn105", "ns16550a".

I am using brcm,bcm6345-gpio to match the drivers/gpio/gpio-mmio.c driver. The opencores,gpio is compatible with the same driver as brcm,bcm6345-gpio but not 100% the same as the brcm,bcm6345-gpio. Since the device tree allows configuring the gpio-mmio driver to make it compatible with opencore,gpio I thought this would be OK.

I switch the size from 32-bit to 8-bit using the reg = <* 0x1>, <* 0x1> setting. Also the reg addresses of "dat" and "dirout" are different for the real brcm,bcm6345-gpio.

brcm,bcm6345-gpio. Example:

       /* GPIOs 192 .. 223 */
       gpio6: gpio@518 {
               compatible = "brcm,bcm6345-gpio";
               reg = <0x518 0x04>, <0x538 0x04>;
               reg-names = "dirout", "dat";
               gpio-controller;
               #gpio-cells = <2>;
       };

vs opencores,gpio Example:

       gpio0: gpio@91000000 {
               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
               reg = <0x91000000 0x1>, <0x91000001 0x1>;
               reg-names = "dat", "dirout";
               gpio-controller;
               #gpio-cells = <2>;
       };

The opencores,gpio setup does work.

Now that I think about it, would it have been better to just add opencores,gpio to gpio-mmio.c compatible list?

If so I will can revise this patch and add patch to gpio-mmio.c.

Quoted 3 lines

Quoted 3 lines

What is the rationale behind using brcm,bcm6345-gpio?
Given brcm,bcm6345-gpio has 32-bit registers, while opencores,gpio has 8-bit registers, I doubt the latter is compatible with the former...

Quoted 17 lines

I switch the size from 32-bit to 8-bit using the reg = <* 0x1>, <* 0x1> setting. Also the reg addresses of "dat" and "dirout" are different for the real brcm,bcm6345-gpio.

brcm,bcm6345-gpio. Example:

       /* GPIOs 192 .. 223 */
       gpio6: gpio@518 {
               compatible = "brcm,bcm6345-gpio";
               reg = <0x518 0x04>, <0x538 0x04>;
               reg-names = "dirout", "dat";
               gpio-controller;
               #gpio-cells = <2>;
       };

vs opencores,gpio Example:

Quoted 7 lines

       gpio0: gpio@91000000 {
               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
               reg = <0x91000000 0x1>, <0x91000001 0x1>;
               reg-names = "dat", "dirout";
               gpio-controller;
               #gpio-cells = <2>;
       };

Exactly, the register space and register widths are different

Quoted 4 lines

The opencores,gpio setup does work.

Now that I think about it, would it have been better to just add opencores,gpio to gpio-mmio.c compatible list?

I think that would be better.

Quoted 1 line

If so I will can revise this patch and add patch to gpio-mmio.c.

DT maintainers: Given gpio-mmio is that generic/simple, is there a specific reason there is no generic "gpio-mmio" compatible value that can be used as a fallback, avoiding the need to keep on adding new entries to gpio_mmio_of_match[]?

Quoted 3 lines · Geert Uytterhoeven

Quoted 3 lines

Quoted 3 lines

What is the rationale behind using brcm,bcm6345-gpio?
Given brcm,bcm6345-gpio has 32-bit registers, while opencores,gpio has 8-bit registers, I doubt the latter is compatible with the former...

Yeah this needs to be fixed/reverted pronto :/

Quoted 25 lines

Quoted 17 lines

I switch the size from 32-bit to 8-bit using the reg = <* 0x1>, <* 0x1> setting. Also the reg addresses of "dat" and "dirout" are different for the real brcm,bcm6345-gpio.

brcm,bcm6345-gpio. Example:

       /* GPIOs 192 .. 223 */
       gpio6: gpio@518 {
               compatible = "brcm,bcm6345-gpio";
               reg = <0x518 0x04>, <0x538 0x04>;
               reg-names = "dirout", "dat";
               gpio-controller;
               #gpio-cells = <2>;
       };

vs opencores,gpio Example:

Quoted 7 lines

       gpio0: gpio@91000000 {
               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
               reg = <0x91000000 0x1>, <0x91000001 0x1>;
               reg-names = "dat", "dirout";
               gpio-controller;
               #gpio-cells = <2>;
       };

Quoted 1 line

Exactly, the register space and register widths are different

...as proved here.

Stafford can you send a fixup or revert patch?
(Only need to revert if you can't make a fix quick enough, which I think you can.)

Quoted 6 lines

Quoted 4 lines

The opencores,gpio setup does work.

Now that I think about it, would it have been better to just add opencores,gpio to gpio-mmio.c compatible list?

I think that would be better.

Yes this is better.

I should have seen this, I guess I was sloppy :(

Quoted 6 lines

Quoted 1 line

If so I will can revise this patch and add patch to gpio-mmio.c.

DT maintainers: Given gpio-mmio is that generic/simple, is there a specific reason there is no generic "gpio-mmio" compatible value that can be used as a fallback, avoiding the need to keep on adding new entries to gpio_mmio_of_match[]?

I think "gpio-mmio" combined with compulsory property of bus-width = <nn> (as used by multiple bindings) would be generic enough. So a schema that accepts "gpio-mmio" if and only if bus-width = 8|16|32|64 would be acceptable.

Quoted 3 lines · Geert Uytterhoeven

Quoted 3 lines

Quoted 3 lines

What is the rationale behind using brcm,bcm6345-gpio?
Given brcm,bcm6345-gpio has 32-bit registers, while opencores,gpio has 8-bit registers, I doubt the latter is compatible with the former...

Yeah this needs to be fixed/reverted pronto :/

Quoted 25 lines

Quoted 24 lines

I switch the size from 32-bit to 8-bit using the reg = <* 0x1>, <* 0x1> setting. Also the reg addresses of "dat" and "dirout" are different for the real brcm,bcm6345-gpio.

brcm,bcm6345-gpio. Example:

       /* GPIOs 192 .. 223 */
       gpio6: gpio@518 {
               compatible = "brcm,bcm6345-gpio";
               reg = <0x518 0x04>, <0x538 0x04>;
               reg-names = "dirout", "dat";
               gpio-controller;
               #gpio-cells = <2>;
       };

vs opencores,gpio Example:

       gpio0: gpio@91000000 {
               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
               reg = <0x91000000 0x1>, <0x91000001 0x1>;
               reg-names = "dat", "dirout";
               gpio-controller;
               #gpio-cells = <2>;
       };

Quoted 1 line

Exactly, the register space and register widths are different

...as proved here.

Stafford can you send a fixup or revert patch?
(Only need to revert if you can't make a fix quick enough, which I think you can.)

Quoted 6 lines

Quoted 4 lines

The opencores,gpio setup does work.

Now that I think about it, would it have been better to just add opencores,gpio to gpio-mmio.c compatible list?

I think that would be better.

Yes this is better.

I should have seen this, I guess I was sloppy :(

Quoted 35 lines · Linus Walleij

Quoted 3 lines · Geert Uytterhoeven

Quoted 3 lines

Quoted 3 lines

What is the rationale behind using brcm,bcm6345-gpio?
Given brcm,bcm6345-gpio has 32-bit registers, while opencores,gpio has 8-bit registers, I doubt the latter is compatible with the former...

Yeah this needs to be fixed/reverted pronto :/

Quoted 26 lines

Quoted 17 lines

I switch the size from 32-bit to 8-bit using the reg = <* 0x1>, <* 0x1> setting. Also the reg addresses of "dat" and "dirout" are different for the real brcm,bcm6345-gpio.

brcm,bcm6345-gpio. Example:

       /* GPIOs 192 .. 223 */
       gpio6: gpio@518 {
               compatible = "brcm,bcm6345-gpio";
               reg = <0x518 0x04>, <0x538 0x04>;
               reg-names = "dirout", "dat";
               gpio-controller;
               #gpio-cells = <2>;
       };

vs opencores,gpio Example:

Quoted 7 lines

       gpio0: gpio@91000000 {
               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
               reg = <0x91000000 0x1>, <0x91000001 0x1>;
               reg-names = "dat", "dirout";
               gpio-controller;
               #gpio-cells = <2>;
       };

Exactly, the register space and register widths are different

Quoted 5 lines

...as proved here.

Stafford can you send a fixup or revert patch?
(Only need to revert if you can't make a fix quick enough, which I think you can.)

Sure, I'll send a fixup to the devicetree binding and a update to the driver to just support opencores,gpio.

Hopefully, that can be picked up in time by Bartosz who has this one staged in gpio/for-next.

I'll send the 2 patches as part of my series for OpenRISC multicore fixups as the devicetree's I have added have a soft dependency the patches. After/if the patches are pulled to the gpio branch I can drop them from my queue and I'll just have to make sure Linux merged the GPIO changes binding updates before the OpenRISC updates during the merge window. Let me know if there are any issues.

Quoted 10 lines

Quoted 6 lines

Quoted 4 lines

The opencores,gpio setup does work.

Now that I think about it, would it have been better to just add opencores,gpio to gpio-mmio.c compatible list?

I think that would be better.

Yes this is better.

I should have seen this, I guess I was sloppy :(

I should have also thought more, but I don't do this often enough to remember all of the rules. Sorry for the head ache.

-Stafford

Quoted 43 lines · Stafford Horne

Quoted 40 lines · Linus Walleij

Quoted 3 lines · Geert Uytterhoeven

Quoted 3 lines

Quoted 3 lines

What is the rationale behind using brcm,bcm6345-gpio?
Given brcm,bcm6345-gpio has 32-bit registers, while opencores,gpio has 8-bit registers, I doubt the latter is compatible with the former...

Yeah this needs to be fixed/reverted pronto :/

Quoted 25 lines

Quoted 17 lines

I switch the size from 32-bit to 8-bit using the reg = <* 0x1>, <* 0x1> setting. Also the reg addresses of "dat" and "dirout" are different for the real brcm,bcm6345-gpio.

brcm,bcm6345-gpio. Example:

       /* GPIOs 192 .. 223 */
       gpio6: gpio@518 {
               compatible = "brcm,bcm6345-gpio";
               reg = <0x518 0x04>, <0x538 0x04>;
               reg-names = "dirout", "dat";
               gpio-controller;
               #gpio-cells = <2>;
       };

vs opencores,gpio Example:

Quoted 7 lines

       gpio0: gpio@91000000 {
               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
               reg = <0x91000000 0x1>, <0x91000001 0x1>;
               reg-names = "dat", "dirout";
               gpio-controller;
               #gpio-cells = <2>;
       };

Quoted 1 line

Exactly, the register space and register widths are different

...as proved here.

Stafford can you send a fixup or revert patch?
(Only need to revert if you can't make a fix quick enough, which I think you can.)

Quoted 3 lines

Sure, I'll send a fixup to the devicetree binding and a update to the driver to just support opencores,gpio.

I assume, the v3 you sent is *not* it and you will send a v4 with issues pointed out by Krzysztof fixes?

Quoted 3 lines

Hopefully, that can be picked up in time by Bartosz who has this one staged in gpio/for-next.

I'm ready to pick it up as soon as Krzysztof Acks it.

Quoted 6 lines

I'll send the 2 patches as part of my series for OpenRISC multicore fixups as the devicetree's I have added have a soft dependency the patches. After/if the patches are pulled to the gpio branch I can drop them from my queue and I'll just have to make sure Linux merged the GPIO changes binding updates before the OpenRISC updates during the merge window. Let me know if there are any issues.

Sounds good.

Quoted 15 lines

Quoted 10 lines

Quoted 6 lines

Quoted 4 lines

The opencores,gpio setup does work.

Now that I think about it, would it have been better to just add opencores,gpio to gpio-mmio.c compatible list?

I think that would be better.

Yes this is better.

I should have seen this, I guess I was sloppy :(

I should have also thought more, but I don't do this often enough to remember all of the rules. Sorry for the head ache.

-Stafford

The de0 nano from Terasic is an FPGA board that we use in the OpenRISC community to test OpenRISC configurations. Add a base configuration for the board that runs an OpenRISC CPU at 50Mhz with 32MB ram, UART for console and some GPIOs for LEDs and switches.

There is an older version of this floating around that defines all of the hardware on the board including SPI's, flash devices, sram, ADCs etc. Eventually it would be good to get the full version upstream but for now I think a minimal board is good to start with.

Link https://openrisc.io/tutorials/de0_nano/

Link https://github.com/olofk/de0_nano

Signed-off-by Stafford Horne <[email protected]>

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +2 -0

@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +6 -0

+               led-heartbeat {
+                       gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+                       color = <LED_COLOR_ID_GREEN>;
+                       function = LED_FUNCTION_HEARTBEAT;
+                       linux,default-trigger = "heartbeat";
+                       label = "heartbeat";

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +11 -0

+       };
+
+       gpio1: gpio@92000000 {
+               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
+               reg = <0x92000000 0x1>, <0x92000001 0x1>;
+               reg-names = "dat", "dirout";
+               gpio-controller;
+               #gpio-cells = <2>;
+               status = "disabled";
+       };
+};

arch/openrisc/boot/dts/de0-nano.dts new file +9 -0

@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "de0-nano-common.dtsi"
+
+/ {
+       model = "Terasic DE0 Nano";
+       compatible = "opencores,or1ksim";

arch/openrisc/boot/dts/de0-nano.dts new file +15 -0

+               cpu@0 {
+                       compatible = "opencores,or1200-rtlsvn481";
+                       reg = <0>;
+                       clock-frequency = <50000000>;
+               };
+       };
+
+       /*
+        * OR1K PIC is built into CPU and accessed via special purpose
+        * registers.  It is not addressable and, hence, has no 'reg'
+        * property.
+        */
+       pic: pic {
+               compatible = "opencores,or1k-pic";
+               #interrupt-cells = <1>;

Hi Stafford,

Quoted 10 lines · Stafford Horne

The de0 nano from Terasic is an FPGA board that we use in the OpenRISC community to test OpenRISC configurations. Add a base configuration for the board that runs an OpenRISC CPU at 50Mhz with 32MB ram, UART for console and some GPIOs for LEDs and switches.

There is an older version of this floating around that defines all of the hardware on the board including SPI's, flash devices, sram, ADCs etc. Eventually it would be good to get the full version upstream but for now I think a minimal board is good to start with.

Quoted 4 lines

Link https://openrisc.io/tutorials/de0_nano/

Link https://github.com/olofk/de0_nano

Signed-off-by Stafford Horne <[email protected]>

Thanks for your patch!

Quoted 9 lines

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +6 -0

@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+/ {

arch/openrisc/boot/dts/de0-nano-common.dtsi line 12

Quoted 6 lines

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +6 -0

+       memory@0 {
+               device_type = "memory";
+               reg = <0x00000000 0x02000000>;
+       };
+
+       leds: leds {

Move this up (or down), before (or after) all nodes with unit addresses?

arch/openrisc/boot/dts/de0-nano-common.dtsi line 14

Quoted 2 lines

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +2 -0

+               compatible = "gpio-leds";
+               status = "okay";

Missing blank line.

Quoted 6 lines

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +6 -0

+               led-heartbeat {
+                       gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+                       color = <LED_COLOR_ID_GREEN>;
+                       function = LED_FUNCTION_HEARTBEAT;
+                       linux,default-trigger = "heartbeat";
+                       label = "heartbeat";

arch/openrisc/boot/dts/de0-nano-common.dtsi line 30

Quoted 10 lines

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +10 -0

+               };
+       };
+
+       gpio0: gpio@91000000 {
+               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
+               reg = <0x91000000 0x1>, <0x91000001 0x1>;
+               reg-names = "dat", "dirout";
+               gpio-controller;
+               #gpio-cells = <2>;
+               status = "okay";

"okay" is the default, so you could drop this line.

Quoted 28 lines

arch/openrisc/boot/dts/de0-nano-common.dtsi new file +11 -0

+       };
+
+       gpio1: gpio@92000000 {
+               compatible = "opencores,gpio", "brcm,bcm6345-gpio";
+               reg = <0x92000000 0x1>, <0x92000001 0x1>;
+               reg-names = "dat", "dirout";
+               gpio-controller;
+               #gpio-cells = <2>;
+               status = "disabled";
+       };
+};

arch/openrisc/boot/dts/de0-nano.dts new file +13 -0

@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "de0-nano-common.dtsi"
+
+/ {
+       model = "Terasic DE0 Nano";
+       compatible = "opencores,or1ksim";
+       #address-cells = <1>;
+       #size-cells = <1>;
+       interrupt-parent = <&pic>;
+

arch/openrisc/boot/dts/de0-nano.dts line 19

Quoted 6 lines

arch/openrisc/boot/dts/de0-nano.dts new file +6 -0

+       aliases {
+               uart0 = &serial0;
+       };
+
+       chosen {
+               bootargs = "earlycon";

Do you need this?

arch/openrisc/boot/dts/de0-nano.dts line 25

Quoted 6 lines

arch/openrisc/boot/dts/de0-nano.dts new file +6 -0

+               stdout-path = "uart0:115200";
+       };
+
+       cpus {
+               #address-cells = <1>;
+               #size-cells = <0>;

Missing blank line.

Quoted 17 lines

arch/openrisc/boot/dts/de0-nano.dts new file +17 -0

+               cpu@0 {
+                       compatible = "opencores,or1200-rtlsvn481";
+                       reg = <0>;
+                       clock-frequency = <50000000>;
+               };
+       };
+
+       /*
+        * OR1K PIC is built into CPU and accessed via special purpose
+        * registers.  It is not addressable and, hence, has no 'reg'
+        * property.
+        */
+       pic: pic {
+               compatible = "opencores,or1k-pic";
+               #interrupt-cells = <1>;
+               interrupt-controller;
+       };

arch/openrisc/boot/dts/de0-nano.dts line 50

Quoted 8 lines

arch/openrisc/boot/dts/de0-nano.dts new file +8 -0

+
+       serial0: serial@90000000 {
+               compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
+               reg = <0x90000000 0x100>;
+               interrupts = <2>;
+               clock-frequency = <50000000>;
+       };
+};

Quoted 32 lines · Geert Uytterhoeven

Quoted 31 lines · Stafford Horne

The de0 nano from Terasic is an FPGA board that we use in the OpenRISC community to test OpenRISC configurations. Add a base configuration for the board that runs an OpenRISC CPU at 50Mhz with 32MB ram, UART for console and some GPIOs for LEDs and switches.

There is an older version of this floating around that defines all of the hardware on the board including SPI's, flash devices, sram, ADCs etc. Eventually it would be good to get the full version upstream but for now I think a minimal board is good to start with.

Link https://openrisc.io/tutorials/de0_nano/

Link https://github.com/olofk/de0_nano

Signed-off-by Stafford Horne <[email protected]>

arch/openrisc/boot/dts/de0-nano.dts new file +13 -0

@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "de0-nano-common.dtsi"
+
+/ {
+       model = "Terasic DE0 Nano";
+       compatible = "opencores,or1ksim";
+       #address-cells = <1>;
+       #size-cells = <1>;
+       interrupt-parent = <&pic>;
+

Quoted 8 lines

arch/openrisc/boot/dts/de0-nano.dts line 19

Quoted 6 lines

arch/openrisc/boot/dts/de0-nano.dts new file +6 -0

+       aliases {
+               uart0 = &serial0;
+       };
+
+       chosen {
+               bootargs = "earlycon";

Do you need this?

What do you mean here? I want to keep "earlycon", and it is not supplied in de0-nano-common.dtsi.

Hi Stafford,

Quoted 42 lines · Stafford Horne

Quoted 40 lines · Geert Uytterhoeven

Quoted 27 lines · Stafford Horne

The de0 nano from Terasic is an FPGA board that we use in the OpenRISC community to test OpenRISC configurations. Add a base configuration for the board that runs an OpenRISC CPU at 50Mhz with 32MB ram, UART for console and some GPIOs for LEDs and switches.

There is an older version of this floating around that defines all of the hardware on the board including SPI's, flash devices, sram, ADCs etc. Eventually it would be good to get the full version upstream but for now I think a minimal board is good to start with.

Link https://openrisc.io/tutorials/de0_nano/

Link https://github.com/olofk/de0_nano

Signed-off-by Stafford Horne <[email protected]>

arch/openrisc/boot/dts/de0-nano.dts new file +9 -0

@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "de0-nano-common.dtsi"
+
+/ {
+       model = "Terasic DE0 Nano";
+       compatible = "opencores,or1ksim";

arch/openrisc/boot/dts/de0-nano.dts line 19

Quoted 10 lines

arch/openrisc/boot/dts/de0-nano.dts new file +10 -0

+       #address-cells = <1>;
+       #size-cells = <1>;
+       interrupt-parent = <&pic>;
+
+       aliases {
+               uart0 = &serial0;
+       };
+
+       chosen {
+               bootargs = "earlycon";

Do you need this?

Quoted 2 lines

What do you mean here? I want to keep "earlycon", and it is not supplied in de0-nano-common.dtsi.

Why do you want to keep it? "earlycon" is a typical debug option, and should not be needed during normal use.

Just curious, Do you have a quick way to enable out of tree debug patches i.e. to dts and defconfigs?

Hi Stafford,

Quoted 2 lines · Stafford Horne

Just curious, Do you have a quick way to enable out of tree debug patches i.e. to dts and defconfigs?

Keep them in your local working branch, and rebase that when upgrading? /me has +1200 local patches :-(

Split out the common memory, CPU and PIC definitions of the simple SMP system to a DTSI file which we will later use for our De0 Nano multicore board device tree. We also take this opportunity to swich underscores to dashes as that seems to be the more common convention for DTS files.

Signed-off-by Stafford Horne <[email protected]>

arch/openrisc/boot/dts/simple-smp.dts new file +13 -0

@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "simple-smp.dtsi"
+
+/ {
+       model = "Simple SMP Board";
+};
+
+&cpu0 {
+       clock-frequency = <20000000>;
+};

arch/openrisc/boot/dts/simple-smp.dts new file +2 -0

+       status = "okay";
+};

arch/openrisc/boot/dts/simple-smp.dtsi renamed from arch/openrisc/boot/dts/simple_smp.dts +0 -1

similarity index 90%
rename from arch/openrisc/boot/dts/simple_smp.dts
rename to arch/openrisc/boot/dts/simple-smp.dtsi
index 71af0e117bfe..2013fd3e7a18 100644
@@ -1,4 +1,3 @@
-/dts-v1/;
 / {
        compatible = "opencores,or1ksim";
        #address-cells = <1>;

Hi Stafford,

Quoted 6 lines · Stafford Horne

Split out the common memory, CPU and PIC definitions of the simple SMP system to a DTSI file which we will later use for our De0 Nano multicore board device tree. We also take this opportunity to swich underscores to dashes as that seems to be the more common convention for DTS files.

Signed-off-by Stafford Horne <[email protected]>

Thanks for your patch!

Quoted 20 lines

arch/openrisc/boot/dts/simple-smp.dts new file +17 -0

@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "simple-smp.dtsi"
+
+/ {
+       model = "Simple SMP Board";
+};
+
+&cpu0 {
+       clock-frequency = <20000000>;
+};
+
+&cpu1 {
+       clock-frequency = <20000000>;
+};

arch/openrisc/boot/dts/simple-smp.dts line 23

Quoted 6 lines

arch/openrisc/boot/dts/simple-smp.dts new file +6 -0

+
+&serial0 {
+       clock-frequency = <20000000>;
+};
+
+&enet0 {

Alphabetical sort order?

Quoted 12 lines

arch/openrisc/boot/dts/simple-smp.dts new file +2 -0

+       status = "okay";
+};

arch/openrisc/boot/dts/simple-smp.dtsi renamed from arch/openrisc/boot/dts/simple_smp.dts +0 -1

similarity index 90%
rename from arch/openrisc/boot/dts/simple_smp.dts
rename to arch/openrisc/boot/dts/simple-smp.dtsi
index 71af0e117bfe..2013fd3e7a18 100644
@@ -1,4 +1,3 @@
-/dts-v1/;
 / {

arch/openrisc/boot/dts/simple-smp.dtsi memory@0 { · line 23

Quoted 6 lines

arch/openrisc/boot/dts/simple-smp.dtsi renamed from arch/openrisc/boot/dts/simple_smp.dts +0 -0

        compatible = "opencores,or1ksim";
        #address-cells = <1>;

@@ -22,15 +21,13 @@ memory@0 {
        cpus {
                #address-cells = <1>;
                #size-cells = <0>;

Missing blank line.

arch/openrisc/boot/dts/simple-smp.dtsi memory@0 { · line 27

Quoted 6 lines

arch/openrisc/boot/dts/simple-smp.dtsi renamed from arch/openrisc/boot/dts/simple_smp.dts +1 -2

-               cpu@0 {
+               cpu0: cpu@0 {
                        compatible = "opencores,or1200-rtlsvn481";
                        reg = <0>;
-                       clock-frequency = <20000000>;
                };

Likewise.

arch/openrisc/boot/dts/simple-smp.dtsi memory@0 { · line 33

Quoted 8 lines

arch/openrisc/boot/dts/simple-smp.dtsi renamed from arch/openrisc/boot/dts/simple_smp.dts +1 -2

-               cpu@1 {
+               cpu1: cpu@1 {
                        compatible = "opencores,or1200-rtlsvn481";
                        reg = <1>;
-                       clock-frequency = <20000000>;
                };
        };
 

Since v1:
- Use proper schema in gpio-mmio suggsted by Conor Dooley
- Remove 0 clock-frequency definitions in dtsi file

The patches add support for OpenRISC systems running on the De0 Nano FPGA development board. We have two SoCs which are available here:

[...]

Quoted 7 lines · Stafford Horne

Since v1:
- Use proper schema in gpio-mmio suggsted by Conor Dooley
- Remove 0 clock-frequency definitions in dtsi file

The patches add support for OpenRISC systems running on the De0 Nano FPGA development board. We have two SoCs which are available here:

Quoted 1 line

[...]

Tweaked the commit message a bit and applied, thanks!

[1/5] dt-bindings: Add compatible string opencores,gpio to gpio-mmio

      commit: f48b5e8bc2e1344f588cc730082aed6ccc5a6b3e