[PATCH v2 0/5] OpenRISC de0 nano single and multicore boards

[PATCH v2 0/5] OpenRISC de0 nano single and multicore boards

[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:

 - https://github.com/olofk/de0_nano - Single core
 - https://github.com/stffrdhrn/de0_nano-multicore - Multicore

As I work on tutorials to help other get started with OpenRISC I would like to
have these defconfig and devicetree definitions in the upstream kernel to avoid
losing them.

When I was working on resurrecting these old setup's I found a major bug in
OpenRISC SMP which is fixed in this series as well.

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

Stafford Horne (5):
  dt-bindings: Add compatible string opencores,gpio to gpio-mmio
  openrisc: dts: Add de0 nano config and devicetree
  openrisc: Fix IPIs on simple multicore systems
  openrisc: dts: Split simple smp dts to dts and dtsi
  openrisc: dts: Add de0 nano multicore config and devicetree

 .../devicetree/bindings/gpio/gpio-mmio.yaml   | 15 ++-
 arch/openrisc/boot/dts/de0-nano-common.dtsi   | 41 +++++++++
 arch/openrisc/boot/dts/de0-nano-multicore.dts | 25 +++++
 arch/openrisc/boot/dts/de0-nano.dts           | 54 +++++++++++
 arch/openrisc/boot/dts/simple-smp.dts         | 25 +++++
 .../dts/{simple_smp.dts => simple-smp.dtsi}   |  9 +-
 arch/openrisc/configs/de0_nano_defconfig      | 79 ++++++++++++++++
 .../configs/de0_nano_multicore_defconfig      | 92 +++++++++++++++++++
 arch/openrisc/configs/simple_smp_defconfig    |  2 +-
 arch/openrisc/include/asm/smp.h               |  3 +-
 arch/openrisc/kernel/smp.c                    | 22 ++++-
 drivers/irqchip/irq-ompic.c                   | 15 ++-
 drivers/irqchip/irq-or1k-pic.c                | 27 +++++-
 13 files changed, 390 insertions(+), 19 deletions(-)
 create mode 100644 arch/openrisc/boot/dts/de0-nano-common.dtsi
 create mode 100644 arch/openrisc/boot/dts/de0-nano-multicore.dts
 create mode 100644 arch/openrisc/boot/dts/de0-nano.dts
 create mode 100644 arch/openrisc/boot/dts/simple-smp.dts
 rename arch/openrisc/boot/dts/{simple_smp.dts => simple-smp.dtsi} (90%)
 create mode 100644 arch/openrisc/configs/de0_nano_defconfig
 create mode 100644 arch/openrisc/configs/de0_nano_multicore_defconfig

-- 
2.51.0

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

[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";
        };

Link: https://opencores.org/projects/gpio
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
Since v1:
 - Fix schema to actually match the example.

 .../devicetree/bindings/gpio/gpio-mmio.yaml       | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
index b4d55bf6a285..6fcf5fd2cb66 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
@@ -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
+      - items:
+          - enum:
+              - opencores,gpio
+          - const: brcm,bcm6345-gpio
 
   big-endian: true
 
-- 
2.51.0

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

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

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

[Stafford Horne]

On Thu, Dec 18, 2025 at 12:55:07AM +0000, Conor Dooley wrote:
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> pw-bot: not-applicable

Thanks,

 -Stafford

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

[Linus Walleij]

On Wed, Dec 17, 2025 at 9:09 AM Stafford Horne <shorne@gmail.com> wrote:

> 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 <shorne@gmail.com>

Looks reasonable,
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

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

[Geert Uytterhoeven]

Hi Stafford,

On Wed, 17 Dec 2025 at 09:15, Stafford Horne <shorne@gmail.com> wrote:
> 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 <shorne@gmail.com>

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

> --- a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> @@ -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
> +      - 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...

>
>    big-endian: true
>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Stafford Horne]

On Wed, Jan 07, 2026 at 03:35:45PM +0100, Geert Uytterhoeven wrote:
> Hi Stafford,
> 
> On Wed, 17 Dec 2025 at 09:15, Stafford Horne <shorne@gmail.com> wrote:
> > 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 <shorne@gmail.com>
> 
> Thanks for your patch, which is now commit f48b5e8bc2e1344f
> ("dt-bindings: gpio-mmio: Add compatible string for opencores,gpio")
> in gpio/gpio/for-next.
> 
> > --- a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> > +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> > @@ -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
> > +      - 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...

Hello,

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.

-Stafford

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

[Geert Uytterhoeven]

Hi Stafford,

(reviving linusw)

On Thu, 8 Jan 2026 at 09:20, Stafford Horne <shorne@gmail.com> wrote:
> On Wed, Jan 07, 2026 at 03:35:45PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 17 Dec 2025 at 09:15, Stafford Horne <shorne@gmail.com> wrote:
> > > 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 <shorne@gmail.com>
> >
> > Thanks for your patch, which is now commit f48b5e8bc2e1344f
> > ("dt-bindings: gpio-mmio: Add compatible string for opencores,gpio")
> > in gpio/gpio/for-next.
> >
> > > --- a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> > > +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> > > @@ -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
> > > +      - 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 assume the former is a 100% compatible plug-in for the latter.

> 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>;
>        };

Exactly, the register space and register widths are different

> 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.

> 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[]?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Linus Walleij]

On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> > > 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 :/

> > 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>;
> >        };
>
> 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.)

> > 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 :(

> > 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.

Yours,
Linus Walleij

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

[Geert Uytterhoeven]

Hi Linus,

On Fri, 9 Jan 2026 at 11:07, Linus Walleij <linusw@kernel.org> wrote:
> On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > 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 :/
>
> > > 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>;
> > >        };
> >
> > 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.)
>
> > > 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 :(
>
> > > 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.

Each register is described individually, and the width is derived
from the register's size, so no bus-width is needed"

  reg:
    minItems: 1
    description:
      A list of registers in the controller. The width of each register is
      determined by its size. All registers must have the same width. The number
      of GPIOs is set by the width, with bit 0 corresponding to GPIO 0, unless
      the ngpios property further restricts the number of used lines.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Stafford Horne]

On Fri, Jan 09, 2026 at 11:07:17AM +0100, Linus Walleij wrote:
> On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> > > > 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 :/
> 
> > > 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>;
> > >        };
> >
> > 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.)

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.

> > > 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

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

[Bartosz Golaszewski]

On Fri, Jan 9, 2026 at 1:51 PM Stafford Horne <shorne@gmail.com> wrote:
>
> On Fri, Jan 09, 2026 at 11:07:17AM +0100, Linus Walleij wrote:
> > On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > > > > 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 :/
> >
> > > > 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>;
> > > >        };
> > >
> > > 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.)
>
> 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?

> 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.

> 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.

Bartosz

> > > > 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

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

[Stafford Horne]

On Mon, Jan 12, 2026 at 10:25:03AM +0100, Bartosz Golaszewski wrote:
> On Fri, Jan 9, 2026 at 1:51 PM Stafford Horne <shorne@gmail.com> wrote:
> >
> > On Fri, Jan 09, 2026 at 11:07:17AM +0100, Linus Walleij wrote:
> > > On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >
> > > > > > 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 :/
> > >
> > > > > 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>;
> > > > >        };
> > > >
> > > > 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.)
> >
> > 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?

Yes, I have just sent out the v4.

> > 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.

OK.

> > 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.

Thank you.

-Stafford

> > > > > 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

[PATCH v2 2/5] openrisc: dts: Add de0 nano config and devicetree

[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 <shorne@gmail.com>
---
 arch/openrisc/boot/dts/de0-nano-common.dtsi | 41 +++++++++++
 arch/openrisc/boot/dts/de0-nano.dts         | 54 ++++++++++++++
 arch/openrisc/configs/de0_nano_defconfig    | 79 +++++++++++++++++++++
 3 files changed, 174 insertions(+)
 create mode 100644 arch/openrisc/boot/dts/de0-nano-common.dtsi
 create mode 100644 arch/openrisc/boot/dts/de0-nano.dts
 create mode 100644 arch/openrisc/configs/de0_nano_defconfig

diff --git a/arch/openrisc/boot/dts/de0-nano-common.dtsi b/arch/openrisc/boot/dts/de0-nano-common.dtsi
new file mode 100644
index 000000000000..421c366d120e
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0-nano-common.dtsi
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	memory@0 {
+		device_type = "memory";
+		reg = <0x00000000 0x02000000>;
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+		status = "okay";
+		led-heartbeat {
+			gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_HEARTBEAT;
+			linux,default-trigger = "heartbeat";
+			label = "heartbeat";
+		};
+	};
+
+	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";
+	};
+
+	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";
+	};
+};
diff --git a/arch/openrisc/boot/dts/de0-nano.dts b/arch/openrisc/boot/dts/de0-nano.dts
new file mode 100644
index 000000000000..06c9b0b2406e
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0-nano.dts
@@ -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>;
+
+	aliases {
+		uart0 = &serial0;
+	};
+
+	chosen {
+		bootargs = "earlycon";
+		stdout-path = "uart0:115200";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <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;
+	};
+
+	serial0: serial@90000000 {
+		compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
+		reg = <0x90000000 0x100>;
+		interrupts = <2>;
+		clock-frequency = <50000000>;
+	};
+};
+
+&gpio1 {
+	status = "okay";
+};
diff --git a/arch/openrisc/configs/de0_nano_defconfig b/arch/openrisc/configs/de0_nano_defconfig
new file mode 100644
index 000000000000..bc63905f9cd8
--- /dev/null
+++ b/arch/openrisc/configs/de0_nano_defconfig
@@ -0,0 +1,79 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_GZIP is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+# CONFIG_RD_ZSTD is not set
+CONFIG_EXPERT=y
+# CONFIG_EPOLL is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_BUILTIN_DTB_NAME="de0-nano"
+# CONFIG_FPU is not set
+CONFIG_HZ_100=y
+# CONFIG_BLOCK is not set
+CONFIG_SLUB_TINY=y
+# CONFIG_COMPAT_BRK is not set
+# CONFIG_VM_EVENT_COUNTERS is not set
+CONFIG_NET=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_INET_UDP_DIAG=y
+CONFIG_INET_RAW_DIAG=y
+CONFIG_INET_DIAG_DESTROY=y
+# CONFIG_IPV6 is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FW_LOADER is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_PPS=y
+CONFIG_GPIO_SYSFS=y
+# CONFIG_GPIO_SYSFS_LEGACY is not set
+CONFIG_GPIO_GENERIC_PLATFORM=y
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_ACTIVITY=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_LEDS_TRIGGER_TRANSIENT=y
+CONFIG_LEDS_TRIGGER_PANIC=y
+CONFIG_LEDS_TRIGGER_NETDEV=y
+CONFIG_LEDS_TRIGGER_PATTERN=y
+CONFIG_LEDS_TRIGGER_TTY=y
+# CONFIG_VIRTIO_MENU is not set
+# CONFIG_VHOST_MENU is not set
+# CONFIG_DNOTIFY is not set
+CONFIG_TMPFS=y
+# CONFIG_XZ_DEC_X86 is not set
+# CONFIG_XZ_DEC_POWERPC is not set
+# CONFIG_XZ_DEC_ARM is not set
+# CONFIG_XZ_DEC_ARMTHUMB is not set
+# CONFIG_XZ_DEC_ARM64 is not set
+# CONFIG_XZ_DEC_SPARC is not set
+# CONFIG_XZ_DEC_RISCV is not set
+CONFIG_PRINTK_TIME=y
+# CONFIG_DEBUG_MISC is not set
+# CONFIG_FTRACE is not set
+# CONFIG_RUNTIME_TESTING_MENU is not set
-- 
2.51.0

Re: [PATCH v2 2/5] openrisc: dts: Add de0 nano config and devicetree

[Geert Uytterhoeven]

Hi Stafford,

On Wed, 17 Dec 2025 at 09:23, Stafford Horne <shorne@gmail.com> wrote:
> 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 <shorne@gmail.com>

Thanks for your patch!

> --- /dev/null
> +++ b/arch/openrisc/boot/dts/de0-nano-common.dtsi
> @@ -0,0 +1,41 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> +       memory@0 {
> +               device_type = "memory";
> +               reg = <0x00000000 0x02000000>;
> +       };
> +
> +       leds: leds {

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

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

Missing blank line.

> +               led-heartbeat {
> +                       gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> +                       color = <LED_COLOR_ID_GREEN>;
> +                       function = LED_FUNCTION_HEARTBEAT;
> +                       linux,default-trigger = "heartbeat";
> +                       label = "heartbeat";
> +               };
> +       };
> +
> +       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.

> +       };
> +
> +       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";
> +       };
> +};

> --- /dev/null
> +++ b/arch/openrisc/boot/dts/de0-nano.dts
> @@ -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>;
> +
> +       aliases {
> +               uart0 = &serial0;
> +       };
> +
> +       chosen {
> +               bootargs = "earlycon";

Do you need this?

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

Missing blank line.

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

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 2/5] openrisc: dts: Add de0 nano config and devicetree

[Stafford Horne]

On Thu, Dec 18, 2025 at 07:36:08PM +0100, Geert Uytterhoeven wrote:
> Hi Stafford,
> 
> On Wed, 17 Dec 2025 at 09:23, Stafford Horne <shorne@gmail.com> wrote:
> > 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 <shorne@gmail.com>
> 
> Thanks for your patch!
> 
> > --- /dev/null
> > +++ b/arch/openrisc/boot/dts/de0-nano-common.dtsi
> > @@ -0,0 +1,41 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/leds/common.h>
> > +
> > +/ {
> > +       memory@0 {
> > +               device_type = "memory";
> > +               reg = <0x00000000 0x02000000>;
> > +       };
> > +
> > +       leds: leds {
> 
> Move this up (or down), before (or after) all nodes with unit addresses?

OK.

> > +               compatible = "gpio-leds";
> > +               status = "okay";
> 
> Missing blank line.

OK, also I can remove the "okay" line as well.

> > +               led-heartbeat {
> > +                       gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> > +                       color = <LED_COLOR_ID_GREEN>;
> > +                       function = LED_FUNCTION_HEARTBEAT;
> > +                       linux,default-trigger = "heartbeat";
> > +                       label = "heartbeat";
> > +               };
> > +       };
> > +
> > +       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.

OK.

> > +       };
> > +
> > +       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";
> > +       };
> > +};
> 
> > --- /dev/null
> > +++ b/arch/openrisc/boot/dts/de0-nano.dts
> > @@ -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>;
> > +
> > +       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.

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

OK.

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

-Stafford

Re: [PATCH v2 2/5] openrisc: dts: Add de0 nano config and devicetree

[Geert Uytterhoeven]

Hi Stafford,

On Sat, 3 Jan 2026 at 07:17, Stafford Horne <shorne@gmail.com> wrote:
> On Thu, Dec 18, 2025 at 07:36:08PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 17 Dec 2025 at 09:23, Stafford Horne <shorne@gmail.com> wrote:
> > > 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 <shorne@gmail.com>

> > > --- /dev/null
> > > +++ b/arch/openrisc/boot/dts/de0-nano.dts
> > > @@ -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>;
> > > +
> > > +       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.

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

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 2/5] openrisc: dts: Add de0 nano config and devicetree

[Stafford Horne]

On Mon, Jan 05, 2026 at 12:02:52PM +0100, Geert Uytterhoeven wrote:
> Hi Stafford,
> 
> On Sat, 3 Jan 2026 at 07:17, Stafford Horne <shorne@gmail.com> wrote:
> > On Thu, Dec 18, 2025 at 07:36:08PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 17 Dec 2025 at 09:23, Stafford Horne <shorne@gmail.com> wrote:
> > > > 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 <shorne@gmail.com>
> 
> > > > --- /dev/null
> > > > +++ b/arch/openrisc/boot/dts/de0-nano.dts
> > > > @@ -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>;
> > > > +
> > > > +       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.
> 
> Why do you want to keep it? "earlycon" is a typical debug option,
> and should not be needed during normal use.

I see, I am always debugging so I leave it on.  But, good point for these
default configs.  I'll remove the debug defaults.

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

-Stafford

Re: [PATCH v2 2/5] openrisc: dts: Add de0 nano config and devicetree

[Geert Uytterhoeven]

Hi Stafford,

On Tue, 6 Jan 2026 at 10:54, Stafford Horne <shorne@gmail.com> wrote:
> 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 :-(

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 2/5] openrisc: dts: Add de0 nano config and devicetree

[Stafford Horne]

On Tue, Jan 06, 2026 at 11:18:01AM +0100, Geert Uytterhoeven wrote:
> Hi Stafford,
> 
> On Tue, 6 Jan 2026 at 10:54, Stafford Horne <shorne@gmail.com> wrote:
> > 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 :-(

I see :)

I am going to play with mini.config's using KCONFIG_ALLCONFIG.

-Stafford

[PATCH v2 3/5] openrisc: Fix IPIs on simple multicore systems

[Stafford Horne]

Commit c05671846451 ("openrisc: sleep instead of spin on secondary
wait") fixed OpenRISC SMP Linux for QEMU. However, stability was never
achieved on FPGA development boards.  This is because the above patch
has a step to unmask IPIs on non-boot cpu's but on hardware without
power management, IPIs remain masked.

This meant that IPI's were never actually working on the simple SMP
systems we run on development boards.  The systems booted but stability
was very suspect.

Add the ability to unmask IPI's on the non-boot cores.  This is done by
making the OMPIC IRQs proper percpu IRQs.  We can then use the
enabled_percpu_irq() to unmask IRQ on the non-boot cpus.

Update the or1k PIC driver to use a flow handler that can switch between
percpu and the configured level or edge flow handlers at runtime.
This mechanism is inspired by that done in the J-Core AIC driver.

Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 arch/openrisc/include/asm/smp.h |  3 ++-
 arch/openrisc/kernel/smp.c      | 22 +++++++++++++++++++++-
 drivers/irqchip/irq-ompic.c     | 15 +++++++++++----
 drivers/irqchip/irq-or1k-pic.c  | 27 ++++++++++++++++++++++++++-
 4 files changed, 60 insertions(+), 7 deletions(-)

diff --git a/arch/openrisc/include/asm/smp.h b/arch/openrisc/include/asm/smp.h
index e21d2f12b5b6..007296f160ef 100644
--- a/arch/openrisc/include/asm/smp.h
+++ b/arch/openrisc/include/asm/smp.h
@@ -20,7 +20,8 @@ extern void smp_init_cpus(void);
 extern void arch_send_call_function_single_ipi(int cpu);
 extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
 
-extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
+extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int),
+			       unsigned int irq);
 extern void handle_IPI(unsigned int ipi_msg);
 
 #endif /* __ASM_OPENRISC_SMP_H */
diff --git a/arch/openrisc/kernel/smp.c b/arch/openrisc/kernel/smp.c
index 86da4bc5ee0b..040ca201b692 100644
--- a/arch/openrisc/kernel/smp.c
+++ b/arch/openrisc/kernel/smp.c
@@ -13,6 +13,7 @@
 
 #include <linux/smp.h>
 #include <linux/cpu.h>
+#include <linux/interrupt.h>
 #include <linux/sched.h>
 #include <linux/sched/mm.h>
 #include <linux/irq.h>
@@ -25,6 +26,7 @@
 
 asmlinkage __init void secondary_start_kernel(void);
 
+static unsigned int ipi_irq __ro_after_init;
 static void (*smp_cross_call)(const struct cpumask *, unsigned int);
 
 unsigned long secondary_release = -1;
@@ -39,6 +41,14 @@ enum ipi_msg_type {
 
 static DEFINE_SPINLOCK(boot_lock);
 
+static void or1k_ipi_enable(void)
+{
+	if (WARN_ON_ONCE(!ipi_irq))
+		return;
+
+	enable_percpu_irq(ipi_irq, 0);
+}
+
 static void boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
 	/*
@@ -136,6 +146,7 @@ asmlinkage __init void secondary_start_kernel(void)
 	complete(&cpu_running);
 
 	synchronise_count_slave(cpu);
+	or1k_ipi_enable();
 	set_cpu_online(cpu, true);
 
 	local_irq_enable();
@@ -195,9 +206,18 @@ void smp_send_stop(void)
 	smp_call_function(stop_this_cpu, NULL, 0);
 }
 
-void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
+void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int),
+			       unsigned int irq)
 {
+	if (WARN_ON(ipi_irq))
+		return;
+
 	smp_cross_call = fn;
+
+	ipi_irq = irq;
+
+	/* Enabled IPIs for boot CPU immediately */
+	or1k_ipi_enable();
 }
 
 void arch_send_call_function_single_ipi(int cpu)
diff --git a/drivers/irqchip/irq-ompic.c b/drivers/irqchip/irq-ompic.c
index e66ef4373b1e..f0e0b435bb1d 100644
--- a/drivers/irqchip/irq-ompic.c
+++ b/drivers/irqchip/irq-ompic.c
@@ -84,6 +84,8 @@ DEFINE_PER_CPU(unsigned long, ops);
 
 static void __iomem *ompic_base;
 
+static DEFINE_PER_CPU_READ_MOSTLY(int, ipi_dummy_dev);
+
 static inline u32 ompic_readreg(void __iomem *base, loff_t offset)
 {
 	return ioread32be(base + offset);
@@ -183,12 +185,17 @@ static int __init ompic_of_init(struct device_node *node,
 		goto out_unmap;
 	}
 
-	ret = request_irq(irq, ompic_ipi_handler, IRQF_PERCPU,
-				"ompic_ipi", NULL);
-	if (ret)
+	irq_set_percpu_devid(irq);
+	ret = request_percpu_irq(irq, ompic_ipi_handler, "ompic_ipi",
+				 &ipi_dummy_dev);
+
+	if (ret) {
+		pr_err("ompic: failed to request irq %d, error: %d",
+		       irq, ret);
 		goto out_irq_disp;
+	}
 
-	set_smp_cross_call(ompic_raise_softirq);
+	set_smp_cross_call(ompic_raise_softirq, irq);
 
 	return 0;
 
diff --git a/drivers/irqchip/irq-or1k-pic.c b/drivers/irqchip/irq-or1k-pic.c
index 48126067c54b..73dc99c71d40 100644
--- a/drivers/irqchip/irq-or1k-pic.c
+++ b/drivers/irqchip/irq-or1k-pic.c
@@ -118,11 +118,36 @@ static void or1k_pic_handle_irq(struct pt_regs *regs)
 		generic_handle_domain_irq(root_domain, irq);
 }
 
+/*
+ * The OR1K PIC is a cpu-local interrupt controller and does not distinguish or
+ * use distinct irq number ranges for per-cpu event interrupts (IPI). Since
+ * information to determine whether a particular irq number should be treated as
+ * per-cpu is not available at mapping time, we use a wrapper handler function
+ * which chooses the right handler at runtime based on whether IRQF_PERCPU was
+ * used when requesting the irq.  Borrowed from J-Core AIC.
+ */
+static void or1k_irq_flow_handler(struct irq_desc *desc)
+{
+#ifdef CONFIG_SMP
+	struct irq_data *data = irq_desc_get_irq_data(desc);
+	struct or1k_pic_dev *pic = data->domain->host_data;
+
+	if (irqd_is_per_cpu(data))
+		handle_percpu_devid_irq(desc);
+	else
+		pic->handle(desc);
+#endif
+}
+
 static int or1k_map(struct irq_domain *d, unsigned int irq, irq_hw_number_t hw)
 {
 	struct or1k_pic_dev *pic = d->host_data;
 
-	irq_set_chip_and_handler(irq, &pic->chip, pic->handle);
+	if (IS_ENABLED(CONFIG_SMP))
+		irq_set_chip_and_handler(irq, &pic->chip, or1k_irq_flow_handler);
+	else
+		irq_set_chip_and_handler(irq, &pic->chip, pic->handle);
+
 	irq_set_status_flags(irq, pic->flags);
 
 	return 0;
-- 
2.51.0

[PATCH v2 4/5] openrisc: dts: Split simple smp dts to dts and dtsi

[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 <shorne@gmail.com>
---
Since v1:
  - Removed clock-frequency 0 in dtsi file.
  - Fix DTB name in defconfig file

 arch/openrisc/boot/dts/simple-smp.dts         | 25 +++++++++++++++++++
 .../dts/{simple_smp.dts => simple-smp.dtsi}   |  9 +++----
 arch/openrisc/configs/simple_smp_defconfig    |  2 +-
 3 files changed, 29 insertions(+), 7 deletions(-)
 create mode 100644 arch/openrisc/boot/dts/simple-smp.dts
 rename arch/openrisc/boot/dts/{simple_smp.dts => simple-smp.dtsi} (90%)

diff --git a/arch/openrisc/boot/dts/simple-smp.dts b/arch/openrisc/boot/dts/simple-smp.dts
new file mode 100644
index 000000000000..26f6a9236b30
--- /dev/null
+++ b/arch/openrisc/boot/dts/simple-smp.dts
@@ -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>;
+};
+
+&serial0 {
+	clock-frequency = <20000000>;
+};
+
+&enet0 {
+	status = "okay";
+};
diff --git a/arch/openrisc/boot/dts/simple_smp.dts b/arch/openrisc/boot/dts/simple-smp.dtsi
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
--- a/arch/openrisc/boot/dts/simple_smp.dts
+++ b/arch/openrisc/boot/dts/simple-smp.dtsi
@@ -1,4 +1,3 @@
-/dts-v1/;
 / {
 	compatible = "opencores,or1ksim";
 	#address-cells = <1>;
@@ -22,15 +21,13 @@ memory@0 {
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
-		cpu@0 {
+		cpu0: cpu@0 {
 			compatible = "opencores,or1200-rtlsvn481";
 			reg = <0>;
-			clock-frequency = <20000000>;
 		};
-		cpu@1 {
+		cpu1: cpu@1 {
 			compatible = "opencores,or1200-rtlsvn481";
 			reg = <1>;
-			clock-frequency = <20000000>;
 		};
 	};
 
@@ -57,7 +54,6 @@ serial0: serial@90000000 {
 		compatible = "opencores,uart16550-rtlsvn105", "ns16550a";
 		reg = <0x90000000 0x100>;
 		interrupts = <2>;
-		clock-frequency = <20000000>;
 	};
 
 	enet0: ethoc@92000000 {
@@ -65,5 +61,6 @@ enet0: ethoc@92000000 {
 		reg = <0x92000000 0x800>;
 		interrupts = <4>;
 		big-endian;
+		status = "disabled";
 	};
 };
diff --git a/arch/openrisc/configs/simple_smp_defconfig b/arch/openrisc/configs/simple_smp_defconfig
index 6008e824d31c..db77c795225e 100644
--- a/arch/openrisc/configs/simple_smp_defconfig
+++ b/arch/openrisc/configs/simple_smp_defconfig
@@ -20,7 +20,7 @@ CONFIG_SLUB=y
 CONFIG_SLUB_TINY=y
 CONFIG_MODULES=y
 # CONFIG_BLOCK is not set
-CONFIG_BUILTIN_DTB_NAME="simple_smp"
+CONFIG_BUILTIN_DTB_NAME="simple-smp"
 CONFIG_SMP=y
 CONFIG_HZ_100=y
 CONFIG_OPENRISC_HAVE_SHADOW_GPRS=y
-- 
2.51.0

Re: [PATCH v2 4/5] openrisc: dts: Split simple smp dts to dts and dtsi

[Geert Uytterhoeven]

Hi Stafford,

On Wed, 17 Dec 2025 at 09:23, Stafford Horne <shorne@gmail.com> wrote:
> 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 <shorne@gmail.com>

Thanks for your patch!

> --- /dev/null
> +++ b/arch/openrisc/boot/dts/simple-smp.dts
> @@ -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>;
> +};
> +
> +&serial0 {
> +       clock-frequency = <20000000>;
> +};
> +
> +&enet0 {

Alphabetical sort order?

> +       status = "okay";
> +};
> diff --git a/arch/openrisc/boot/dts/simple_smp.dts b/arch/openrisc/boot/dts/simple-smp.dtsi
> 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
> --- a/arch/openrisc/boot/dts/simple_smp.dts
> +++ b/arch/openrisc/boot/dts/simple-smp.dtsi
> @@ -1,4 +1,3 @@
> -/dts-v1/;
>  / {
>         compatible = "opencores,or1ksim";
>         #address-cells = <1>;
> @@ -22,15 +21,13 @@ memory@0 {
>         cpus {
>                 #address-cells = <1>;
>                 #size-cells = <0>;

Missing blank line.

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

Likewise.

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

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 4/5] openrisc: dts: Split simple smp dts to dts and dtsi

[Stafford Horne]

On Thu, Dec 18, 2025 at 07:37:43PM +0100, Geert Uytterhoeven wrote:
> Hi Stafford,
> 
> On Wed, 17 Dec 2025 at 09:23, Stafford Horne <shorne@gmail.com> wrote:
> > 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 <shorne@gmail.com>
> 
> Thanks for your patch!

Thanks for the review.  Sorry for the delay my home server (internet) went down
when I was out of the country and I didn't fix until I go back.

> > --- /dev/null
> > +++ b/arch/openrisc/boot/dts/simple-smp.dts
> > @@ -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>;
> > +};
> > +
> > +&serial0 {
> > +       clock-frequency = <20000000>;
> > +};
> > +
> > +&enet0 {
> 
> Alphabetical sort order?

Sure, I'll fix, I didn't know all of the conventions, thanks for pointing out.

> > +       status = "okay";
> > +};
> > diff --git a/arch/openrisc/boot/dts/simple_smp.dts b/arch/openrisc/boot/dts/simple-smp.dtsi
> > 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
> > --- a/arch/openrisc/boot/dts/simple_smp.dts
> > +++ b/arch/openrisc/boot/dts/simple-smp.dtsi
> > @@ -1,4 +1,3 @@
> > -/dts-v1/;
> >  / {
> >         compatible = "opencores,or1ksim";
> >         #address-cells = <1>;
> > @@ -22,15 +21,13 @@ memory@0 {
> >         cpus {
> >                 #address-cells = <1>;
> >                 #size-cells = <0>;
> 
> Missing blank line.

OK.

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

OK.

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

Thanks,

 -Stafford

[PATCH v2 5/5] openrisc: dts: Add de0 nano multicore config and devicetree

[Stafford Horne]

Add a multicore configuration for the Terasic de0 nano FPGA development
board.  This SoC runs 2 OpenRISC CPUs at 50Mhz with 32MB ram, UART for
console and GPIOs for LEDs.

This FPGA SoC is based on the simple-smp reference board and brings in
devices from the de0 nano common DTSI file.

A default config is added that brings together the device tree and
driver setup.

Link: https://github.com/stffrdhrn/de0_nano-multicore

Signed-off-by: Stafford Horne <shorne@gmail.com>
---
 arch/openrisc/boot/dts/de0-nano-multicore.dts | 25 +++++
 .../configs/de0_nano_multicore_defconfig      | 92 +++++++++++++++++++
 2 files changed, 117 insertions(+)
 create mode 100644 arch/openrisc/boot/dts/de0-nano-multicore.dts
 create mode 100644 arch/openrisc/configs/de0_nano_multicore_defconfig

diff --git a/arch/openrisc/boot/dts/de0-nano-multicore.dts b/arch/openrisc/boot/dts/de0-nano-multicore.dts
new file mode 100644
index 000000000000..b6cf286afaa4
--- /dev/null
+++ b/arch/openrisc/boot/dts/de0-nano-multicore.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+/dts-v1/;
+
+#include "simple-smp.dtsi"
+#include "de0-nano-common.dtsi"
+
+/ {
+	model = "Terasic DE0 Nano - Multicore";
+};
+
+&cpu0 {
+	clock-frequency = <50000000>;
+};
+
+&cpu1 {
+	clock-frequency = <50000000>;
+};
+
+&serial0 {
+	clock-frequency = <50000000>;
+};
diff --git a/arch/openrisc/configs/de0_nano_multicore_defconfig b/arch/openrisc/configs/de0_nano_multicore_defconfig
new file mode 100644
index 000000000000..d33b1226e09c
--- /dev/null
+++ b/arch/openrisc/configs/de0_nano_multicore_defconfig
@@ -0,0 +1,92 @@
+CONFIG_LOCALVERSION="-de0nano-smp"
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_GZIP is not set
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EXPERT=y
+# CONFIG_EPOLL is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_KALLSYMS_ALL=y
+CONFIG_DCACHE_WRITETHROUGH=y
+CONFIG_BUILTIN_DTB_NAME="de0-nano-multicore"
+CONFIG_OPENRISC_HAVE_INST_CMOV=y
+CONFIG_SMP=y
+CONFIG_HZ_100=y
+CONFIG_JUMP_LABEL=y
+# CONFIG_BLOCK is not set
+CONFIG_SLUB_TINY=y
+# CONFIG_COMPAT_BRK is not set
+# CONFIG_VM_EVENT_COUNTERS is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_TCP_CONG_ADVANCED=y
+# CONFIG_TCP_CONG_BIC is not set
+# CONFIG_TCP_CONG_CUBIC is not set
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FW_LOADER is not set
+CONFIG_NETDEVICES=y
+CONFIG_ETHOC=y
+CONFIG_MICREL_PHY=y
+# CONFIG_WLAN is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_GPIO_SYSFS=y
+# CONFIG_GPIO_CDEV_V1 is not set
+CONFIG_GPIO_GENERIC_PLATFORM=y
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_ACTIVITY=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_LEDS_TRIGGER_TRANSIENT=y
+CONFIG_LEDS_TRIGGER_PANIC=y
+CONFIG_LEDS_TRIGGER_NETDEV=y
+CONFIG_LEDS_TRIGGER_PATTERN=y
+CONFIG_LEDS_TRIGGER_TTY=y
+# CONFIG_DNOTIFY is not set
+CONFIG_TMPFS=y
+CONFIG_NFS_FS=y
+CONFIG_XZ_DEC=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
+CONFIG_GDB_SCRIPTS=y
+CONFIG_VMLINUX_MAP=y
+CONFIG_HARDLOCKUP_DETECTOR=y
+CONFIG_WQ_WATCHDOG=y
+CONFIG_WQ_CPU_INTENSIVE_REPORT=y
+CONFIG_STACKTRACE=y
+CONFIG_RCU_CPU_STALL_CPUTIME=y
+# CONFIG_RCU_TRACE is not set
-- 
2.51.0

Re: (subset) [PATCH v2 0/5] OpenRISC de0 nano single and multicore boards

[Bartosz Golaszewski]

On Wed, 17 Dec 2025 08:08:26 +0000, Stafford Horne wrote:
> 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:
> 
> [...]

Tweaked the commit message a bit and applied, thanks!

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

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: (subset) [PATCH v2 0/5] OpenRISC de0 nano single and multicore boards

[Stafford Horne]

On Thu, Dec 18, 2025 at 02:46:48PM +0100, Bartosz Golaszewski wrote:
> 
> On Wed, 17 Dec 2025 08:08:26 +0000, Stafford Horne wrote:
> > 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:
> > 
> > [...]
> 
> Tweaked the commit message a bit and applied, thanks!
> 
> [1/5] dt-bindings: Add compatible string opencores,gpio to gpio-mmio
>       commit: f48b5e8bc2e1344f588cc730082aed6ccc5a6b3e

Hi Bartosz,

After discussion [1] with Linus W and Geert U on this patch we agreed it would be
best to drop this old patch and replace with a patch to add "opencores,gpio" to
the binding and the driver.

I have sent two new patches for that.  Can you please consider dropping this
original patch from your queue and replacing with the new?

If you prefer me to post these in a different way I can do that too.

[1] https://lore.kernel.org/lkml/CAD++jLm1u9ChqsftwvbOptiG3Qo2KWxPjqN2snOVuZDYuVST5Q@mail.gmail.com/

-Stafford