| Message ID | 20230518152244.2178-7-jszhang@kernel.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Conor Dooley |
| Headers | show |
| Series | riscv: add Bouffalolab bl808 support | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/cover_letter | success | Series has a cover letter |
| conchuod/tree_selection | success | Guessed tree name to be for-next at HEAD ac9a78681b92 |
| conchuod/fixes_present | success | Fixes tag not required for -next series |
| conchuod/maintainers_pattern | success | MAINTAINERS pattern errors before the patch: 6 and now 6 |
| conchuod/verify_signedoff | success | Signed-off-by tag matches author and committer |
| conchuod/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| conchuod/build_rv64_clang_allmodconfig | success | Errors and warnings before: 8 this patch: 8 |
| conchuod/module_param | success | Was 0 now: 0 |
| conchuod/build_rv64_gcc_allmodconfig | success | Errors and warnings before: 8 this patch: 8 |
| conchuod/build_rv32_defconfig | success | Build OK |
| conchuod/dtb_warn_rv64 | success | Errors and warnings before: 3 this patch: 3 |
| conchuod/header_inline | success | No static functions without inline keyword in header files |
| conchuod/checkpatch | warning | WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? |
| conchuod/build_rv64_nommu_k210_defconfig | success | Build OK |
| conchuod/verify_fixes | success | No Fixes tag |
| conchuod/build_rv64_nommu_virt_defconfig | success | Build OK |
Hi Jisheng, DT maintainers, On 5/18/23 10:22, Jisheng Zhang wrote: > Several SoMs and boards are available that feature the Bouffalolab > bl808 SoC. Document the compatible strings. > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > Acked-by: Palmer Dabbelt <palmer@rivosinc.com> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > --- > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++ > 1 file changed, 29 insertions(+) > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > new file mode 100644 > index 000000000000..3b25d1a5d04a > --- /dev/null > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > @@ -0,0 +1,29 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Bouffalo Lab Technology SoC-based boards > + > +maintainers: > + - Jisheng Zhang <jszhang@kernel.org> > + > +description: > + Bouffalo Lab Technology SoC-based boards > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - description: Carrier boards for the Sipeed M1s SoM > + items: > + - enum: > + - sipeed,m1s-dock > + - const: sipeed,m1s > + - const: bouffalolab,bl808 As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V GC compatible, so can run linux." I have also been running U-Boot and NOMMU Linux on the less powerful, but still quite fast, "M0" core. However, this core needs a different DTB because: 1) The CPU is different (T-HEAD E907 instead of C906). 2) The interrupt routing is completely different. a. The M0 core contains a CLIC instead of a PLIC. b. The peripherals in the SoC are split between two buses. Those on one bus have their IRQs directly connected to M0, and share a multiplexed IRQ connection to D0; and vice versa for the other bus. So each bus's interrupt-parent needs to be swapped. Using some preprocessor magic like we did for Allwinner and Renesas, I was able to share most of the SoC and board DTs between the cores[1]. However, this still ends up with two DTs for each board. So here are my questions: - Is this acceptable? - Is there precedent for how we should name the two board DTs? - How does this affect the board and SoC compatible strings? - Should there be a separate "bouffalolab,bl808-d0" in addition to "bouffalolab,bl808"? - Is it acceptable to use the same board compatible string for both, since the _board_ part of the DT does not change, only things inside the SoC? It would be possible to avoid having two DTs per board by guarding all of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong because you would end up with two totally incompatible DTBs named the same thing, depending on how the DTB was built. Thoughts? Regards, Samuel [1]: https://github.com/openbouffalo/u-boot/commit/3ca800850f30
On Thu, May 18, 2023 at 10:31:35PM -0500, Samuel Holland wrote: > Hi Jisheng, DT maintainers, Sick, thanks for piping up Samuel! Both Rob and Krzysztof are not around at the moment, so that probably leaves it up to me.. I'm adding Arnd in case he has a take here too. > On 5/18/23 10:22, Jisheng Zhang wrote: > > Several SoMs and boards are available that feature the Bouffalolab > > bl808 SoC. Document the compatible strings. > > > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com> > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > --- > > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++ > > 1 file changed, 29 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > > > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > new file mode 100644 > > index 000000000000..3b25d1a5d04a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > @@ -0,0 +1,29 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Bouffalo Lab Technology SoC-based boards > > + > > +maintainers: > > + - Jisheng Zhang <jszhang@kernel.org> > > + > > +description: > > + Bouffalo Lab Technology SoC-based boards > > + > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - description: Carrier boards for the Sipeed M1s SoM > > + items: > > + - enum: > > + - sipeed,m1s-dock > > + - const: sipeed,m1s > > + - const: bouffalolab,bl808 > > As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC > contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V > GC compatible, so can run linux." > > I have also been running U-Boot and NOMMU Linux on the less powerful, > but still quite fast, "M0" core. However, this core needs a different > DTB because: > 1) The CPU is different (T-HEAD E907 instead of C906). > 2) The interrupt routing is completely different. > a. The M0 core contains a CLIC instead of a PLIC. > b. The peripherals in the SoC are split between two buses. Those > on one bus have their IRQs directly connected to M0, and share > a multiplexed IRQ connection to D0; and vice versa for the > other bus. So each bus's interrupt-parent needs to be swapped. > > Using some preprocessor magic like we did for Allwinner and Renesas, I > was able to share most of the SoC and board DTs between the cores[1]. > However, this still ends up with two DTs for each board. So here are my > questions: > - Is this acceptable? I expected it to look worse than it actually turned out to be. I don't think Krzysztof in particular is a fan of having conditional bits in dts files, but for the shared arm/riscv stuff there was not really another sensible option. > - Is there precedent for how we should name the two board DTs? Arnd might have some idea about precedent here, but I like your naming well enough. > - How does this affect the board and SoC compatible strings? > - Should there be a separate "bouffalolab,bl808-d0" in addition to > "bouffalolab,bl808"? What ordering were you intending here? "pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"? That doesn't really seem correct though, as it does not get less specific as you move right. "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem right either though, for the same sort of reason. > - Is it acceptable to use the same board compatible string for both, > since the _board_ part of the DT does not change, only things > inside the SoC? I think you may need to have 2 compatibles per board, depending on which cpu. Perhaps even as verbose as: "pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" Not exactly straightforward though, is it! > It would be possible to avoid having two DTs per board by guarding all > of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong > because you would end up with two totally incompatible DTBs named the > same thing, depending on how the DTB was built. I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof complain previously about conditional bits like that. Cheers, Conor.
On Fri, May 19, 2023 at 12:55:02PM +0100, Conor Dooley wrote: > On Thu, May 18, 2023 at 10:31:35PM -0500, Samuel Holland wrote: > > Hi Jisheng, DT maintainers, > > Sick, thanks for piping up Samuel! > Both Rob and Krzysztof are not around at the moment, so that probably > leaves it up to me.. I'm adding Arnd in case he has a take here too. > > > On 5/18/23 10:22, Jisheng Zhang wrote: > > > Several SoMs and boards are available that feature the Bouffalolab > > > bl808 SoC. Document the compatible strings. > > > > > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com> > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > --- > > > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++ > > > 1 file changed, 29 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > > new file mode 100644 > > > index 000000000000..3b25d1a5d04a > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > > @@ -0,0 +1,29 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Bouffalo Lab Technology SoC-based boards > > > + > > > +maintainers: > > > + - Jisheng Zhang <jszhang@kernel.org> > > > + > > > +description: > > > + Bouffalo Lab Technology SoC-based boards > > > + > > > +properties: > > > + $nodename: > > > + const: '/' > > > + compatible: > > > + oneOf: > > > + - description: Carrier boards for the Sipeed M1s SoM > > > + items: > > > + - enum: > > > + - sipeed,m1s-dock > > > + - const: sipeed,m1s > > > + - const: bouffalolab,bl808 > > > > As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC > > contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V > > GC compatible, so can run linux." > > > > I have also been running U-Boot and NOMMU Linux on the less powerful, > > but still quite fast, "M0" core. However, this core needs a different Just FYI, I successfully ran nommu rv32 linux kernel on the "M0" core with some patches to the riscv head and irqchip driver. > > DTB because: > > 1) The CPU is different (T-HEAD E907 instead of C906). > > 2) The interrupt routing is completely different. > > a. The M0 core contains a CLIC instead of a PLIC. > > b. The peripherals in the SoC are split between two buses. Those > > on one bus have their IRQs directly connected to M0, and share > > a multiplexed IRQ connection to D0; and vice versa for the > > other bus. So each bus's interrupt-parent needs to be swapped. > > > > Using some preprocessor magic like we did for Allwinner and Renesas, I > > was able to share most of the SoC and board DTs between the cores[1]. > > However, this still ends up with two DTs for each board. So here are my > > questions: > > - Is this acceptable? > > I expected it to look worse than it actually turned out to be. > I don't think Krzysztof in particular is a fan of having conditional > bits in dts files, but for the shared arm/riscv stuff there was not > really another sensible option. > > > - Is there precedent for how we should name the two board DTs? > > Arnd might have some idea about precedent here, but I like your naming > well enough. > > > - How does this affect the board and SoC compatible strings? > > - Should there be a separate "bouffalolab,bl808-d0" in addition to > > "bouffalolab,bl808"? > > What ordering were you intending here? > "pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"? > > That doesn't really seem correct though, as it does not get less specific > as you move right. > > "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem > right either though, for the same sort of reason. > > > - Is it acceptable to use the same board compatible string for both, > > since the _board_ part of the DT does not change, only things > > inside the SoC? what about describing the DT as the SoC is, e.g lp: cpu@0 { ... status = disabled; }; m0: cpu@1 { ... status = disabled; }; d0: cpu@2 { ... status = disabled; }; Then in m0 dts: &m0 { status = okay; }; in d0 dts: &m0 { status = okay; }; > > I think you may need to have 2 compatibles per board, depending on which > cpu. Perhaps even as verbose as: > "pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" > > Not exactly straightforward though, is it! > > > It would be possible to avoid having two DTs per board by guarding all > > of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong > > because you would end up with two totally incompatible DTBs named the > > same thing, depending on how the DTB was built. > > I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof > complain previously about conditional bits like that. > > Cheers, > Conor.
On Sun, May 21, 2023 at 05:29:47PM +0800, Jisheng Zhang wrote: > On Fri, May 19, 2023 at 12:55:02PM +0100, Conor Dooley wrote: > > On Thu, May 18, 2023 at 10:31:35PM -0500, Samuel Holland wrote: > > > Hi Jisheng, DT maintainers, > > > > Sick, thanks for piping up Samuel! > > Both Rob and Krzysztof are not around at the moment, so that probably > > leaves it up to me.. I'm adding Arnd in case he has a take here too. > > > > > On 5/18/23 10:22, Jisheng Zhang wrote: > > > > Several SoMs and boards are available that feature the Bouffalolab > > > > bl808 SoC. Document the compatible strings. > > > > > > > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > > > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com> > > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > > --- > > > > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++ > > > > 1 file changed, 29 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > > > new file mode 100644 > > > > index 000000000000..3b25d1a5d04a > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > > > @@ -0,0 +1,29 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Bouffalo Lab Technology SoC-based boards > > > > + > > > > +maintainers: > > > > + - Jisheng Zhang <jszhang@kernel.org> > > > > + > > > > +description: > > > > + Bouffalo Lab Technology SoC-based boards > > > > + > > > > +properties: > > > > + $nodename: > > > > + const: '/' > > > > + compatible: > > > > + oneOf: > > > > + - description: Carrier boards for the Sipeed M1s SoM > > > > + items: > > > > + - enum: > > > > + - sipeed,m1s-dock > > > > + - const: sipeed,m1s > > > > + - const: bouffalolab,bl808 > > > > > > As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC > > > contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V > > > GC compatible, so can run linux." > > > > > > I have also been running U-Boot and NOMMU Linux on the less powerful, > > > but still quite fast, "M0" core. However, this core needs a different > > Just FYI, I successfully ran nommu rv32 linux kernel on the "M0" core > with some patches to the riscv head and irqchip driver. > > > > DTB because: > > > 1) The CPU is different (T-HEAD E907 instead of C906). > > > 2) The interrupt routing is completely different. > > > a. The M0 core contains a CLIC instead of a PLIC. > > > b. The peripherals in the SoC are split between two buses. Those > > > on one bus have their IRQs directly connected to M0, and share > > > a multiplexed IRQ connection to D0; and vice versa for the > > > other bus. So each bus's interrupt-parent needs to be swapped. > > > > > > Using some preprocessor magic like we did for Allwinner and Renesas, I > > > was able to share most of the SoC and board DTs between the cores[1]. > > > However, this still ends up with two DTs for each board. So here are my > > > questions: > > > - Is this acceptable? > > > > I expected it to look worse than it actually turned out to be. > > I don't think Krzysztof in particular is a fan of having conditional > > bits in dts files, but for the shared arm/riscv stuff there was not > > really another sensible option. > > > > > - Is there precedent for how we should name the two board DTs? > > > > Arnd might have some idea about precedent here, but I like your naming > > well enough. > > > > > - How does this affect the board and SoC compatible strings? > > > - Should there be a separate "bouffalolab,bl808-d0" in addition to > > > "bouffalolab,bl808"? > > > > What ordering were you intending here? > > "pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"? > > > > That doesn't really seem correct though, as it does not get less specific > > as you move right. > > > > "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem > > right either though, for the same sort of reason. > > > > > - Is it acceptable to use the same board compatible string for both, > > > since the _board_ part of the DT does not change, only things > > > inside the SoC? > > what about describing the DT as the SoC is, e.g > lp: cpu@0 { > ... > status = disabled; > }; > > m0: cpu@1 { > ... > status = disabled; > }; > > d0: cpu@2 { > ... > status = disabled; > }; > > Then in m0 dts: > &m0 { > status = okay; > }; > > in d0 dts: > &m0 { typo: &d0 { > status = okay; > }; > > > > > > I think you may need to have 2 compatibles per board, depending on which > > cpu. Perhaps even as verbose as: > > "pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" > > > > Not exactly straightforward though, is it! > > > > > It would be possible to avoid having two DTs per board by guarding all > > > of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong > > > because you would end up with two totally incompatible DTBs named the > > > same thing, depending on how the DTB was built. > > > > I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof > > complain previously about conditional bits like that. > > > > Cheers, > > Conor. > >
On Thu, May 18, 2023 at 10:31:35PM -0500, Samuel Holland wrote: > Hi Jisheng, DT maintainers, > > On 5/18/23 10:22, Jisheng Zhang wrote: > > Several SoMs and boards are available that feature the Bouffalolab > > bl808 SoC. Document the compatible strings. > > > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com> > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > --- > > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++ > > 1 file changed, 29 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > > > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > new file mode 100644 > > index 000000000000..3b25d1a5d04a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml > > @@ -0,0 +1,29 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Bouffalo Lab Technology SoC-based boards > > + > > +maintainers: > > + - Jisheng Zhang <jszhang@kernel.org> > > + > > +description: > > + Bouffalo Lab Technology SoC-based boards > > + > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - description: Carrier boards for the Sipeed M1s SoM > > + items: > > + - enum: > > + - sipeed,m1s-dock > > + - const: sipeed,m1s > > + - const: bouffalolab,bl808 > > As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC > contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V > GC compatible, so can run linux." > > I have also been running U-Boot and NOMMU Linux on the less powerful, > but still quite fast, "M0" core. However, this core needs a different > DTB because: > 1) The CPU is different (T-HEAD E907 instead of C906). > 2) The interrupt routing is completely different. > a. The M0 core contains a CLIC instead of a PLIC. > b. The peripherals in the SoC are split between two buses. Those > on one bus have their IRQs directly connected to M0, and share > a multiplexed IRQ connection to D0; and vice versa for the > other bus. So each bus's interrupt-parent needs to be swapped. Can't you include the dts file and then just override 'interrupt-parent'? > Using some preprocessor magic like we did for Allwinner and Renesas, I > was able to share most of the SoC and board DTs between the cores[1]. > However, this still ends up with two DTs for each board. So here are my > questions: > - Is this acceptable? > - Is there precedent for how we should name the two board DTs? > - How does this affect the board and SoC compatible strings? > - Should there be a separate "bouffalolab,bl808-d0" in addition to > "bouffalolab,bl808"? Probably. A DT is ultimately the view of the hardware from a CPU's perspective. Different views, different compatibles. > - Is it acceptable to use the same board compatible string for both, > since the _board_ part of the DT does not change, only things > inside the SoC? Yes. > > It would be possible to avoid having two DTs per board by guarding all > of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong > because you would end up with two totally incompatible DTBs named the > same thing, depending on how the DTB was built. You can't have CONFIG_ options in .dts files. Rob
diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml new file mode 100644 index 000000000000..3b25d1a5d04a --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml @@ -0,0 +1,29 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bouffalo Lab Technology SoC-based boards + +maintainers: + - Jisheng Zhang <jszhang@kernel.org> + +description: + Bouffalo Lab Technology SoC-based boards + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: Carrier boards for the Sipeed M1s SoM + items: + - enum: + - sipeed,m1s-dock + - const: sipeed,m1s + - const: bouffalolab,bl808 + +additionalProperties: true + +...