Similar to ARM64, add support for building DTB files from DT source
data for RISC-V boards.
This patch starts with the infrastructure needed for SiFive boards.
Boards from other vendors would add support here in a similar form.
Signed-off-by: Paul Walmsley <[email protected]>
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Albert Ou <[email protected]>
---
arch/riscv/boot/dts/Makefile | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 arch/riscv/boot/dts/Makefile
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
new file mode 100644
index 000000000000..dcc3ada78455
--- /dev/null
+++ b/arch/riscv/boot/dts/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+subdir-y += sifive
--
2.20.1
On Sun 02 Jun 2019 at 01:04, Paul Walmsley <[email protected]> wrote:
> Similar to ARM64, add support for building DTB files from DT source
> data for RISC-V boards.
>
> This patch starts with the infrastructure needed for SiFive boards.
> Boards from other vendors would add support here in a similar form.
>
> Signed-off-by: Paul Walmsley <[email protected]>
> Signed-off-by: Paul Walmsley <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Albert Ou <[email protected]>
> ---
> arch/riscv/boot/dts/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
> create mode 100644 arch/riscv/boot/dts/Makefile
>
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> new file mode 100644
> index 000000000000..dcc3ada78455
> --- /dev/null
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +subdir-y += sifive
Always build it ?
Any particular reason to drop ARCH_SIFIVE ?
On Tue, 4 Jun 2019, Loys Ollivier wrote:
> Always build it ?
> Any particular reason to drop ARCH_SIFIVE ?
Palmer had some reservations about it, so I dropped it for now. But then
as I was thinking about it, I remembered that I also had some reservations
about it, years ago: that everyone should use CONFIG_SOC_* for this,
rather than CONFIG_ARCH. CONFIG_ARCH_* seems better reserved for
CPU architectures.
If you agree, would you like to send a followup series, based on the DT
patches, to make the SiFive DT file builds depend on CONFIG_SOC_* instead?
Thanks for the comment,
- Paul
On Thu 06 Jun 2019 at 22:12, Paul Walmsley <[email protected]> wrote:
> On Tue, 4 Jun 2019, Loys Ollivier wrote:
>
>> Always build it ?
>> Any particular reason to drop ARCH_SIFIVE ?
>
> Palmer had some reservations about it, so I dropped it for now. But then
> as I was thinking about it, I remembered that I also had some reservations
> about it, years ago: that everyone should use CONFIG_SOC_* for this,
> rather than CONFIG_ARCH. CONFIG_ARCH_* seems better reserved for
> CPU architectures.
Agree on the CONFIG_SOC.
>
> If you agree, would you like to send a followup series, based on the DT
> patches, to make the SiFive DT file builds depend on CONFIG_SOC_* instead?
Sure, I'd be glad to follow up on that. I'll send a followup series to
start a discussion.
--
Loys
On Thu, 06 Jun 2019 22:12:05 PDT (-0700), Paul Walmsley wrote:
> On Tue, 4 Jun 2019, Loys Ollivier wrote:
>
>> Always build it ?
>> Any particular reason to drop ARCH_SIFIVE ?
>
> Palmer had some reservations about it, so I dropped it for now. But then
> as I was thinking about it, I remembered that I also had some reservations
> about it, years ago: that everyone should use CONFIG_SOC_* for this,
> rather than CONFIG_ARCH. CONFIG_ARCH_* seems better reserved for
> CPU architectures.
Specifically my worry is that "ARCH_SIFIVE" makes it sound like we're adding
SiFive-specific architecture features, and we've been trying really hard to
make sure that the various bits of core software avoid boing vendor specific.
We've had suggestions of adding vendor-specific instructions to the Linux port
with those instructions being conditionally compiled under ARCH_$VENDOR, but
I'd rejected that under the "no vendor-specific stuff" argument. As such it
doesn't seem fair to go add in an ARCH_SIFIVE for our vendor-specific stuff.
The SOC stuff will, of course, be vendor specific. In this idealized world
SiFive's SOC support has nothing to do with RISC-V, but of course all of
SiFive's SOCs are RISC-V based so the separation is a bit of pedantry. That
said, in this case I think getting the name right does make it slightly easier
to espouse this "one kernel can run on all RISC-V systems" philosophy.
Balancing the SiFive and RISC-V stuff can be a bit tricky, which is why I am
sometimes a bit pedantic about these sorts of things.
> If you agree, would you like to send a followup series, based on the DT
> patches, to make the SiFive DT file builds depend on CONFIG_SOC_* instead?
I'd be happy with something like that. We'd also talked about this selecting
all the SiFive platform drivers. It should, of course, be possible to select
multiple SOC vendors in a single kernel -- we don't have any other real
hardware right now, but maybe some sort of "CONFIG_SOC_RISCV_VIRT" would be a
good proof of concept?
> Thanks for the comment,
>
> - Paul
On Sat, 8 Jun 2019, Palmer Dabbelt wrote:
> On Thu, 06 Jun 2019 22:12:05 PDT (-0700), Paul Walmsley wrote:
> > On Tue, 4 Jun 2019, Loys Ollivier wrote:
> >
> > > Always build it ?
> > > Any particular reason to drop ARCH_SIFIVE ?
> >
> > Palmer had some reservations about it, so I dropped it for now. But then
> > as I was thinking about it, I remembered that I also had some reservations
> > about it, years ago: that everyone should use CONFIG_SOC_* for this,
> > rather than CONFIG_ARCH. CONFIG_ARCH_* seems better reserved for
> > CPU architectures.
>
> The SOC stuff will, of course, be vendor specific. In this idealized world
> SiFive's SOC support has nothing to do with RISC-V, but of course all of
> SiFive's SOCs are RISC-V based so the separation is a bit of pedantry. That
> said, in this case I think getting the name right does make it slightly easier
> to espouse this "one kernel can run on all RISC-V systems" philosophy.
> Balancing the SiFive and RISC-V stuff can be a bit tricky, which is why I am
> sometimes a bit pedantic about these sorts of things.
Once there are SoC variants that have different CPU cores, but with the
remaining chip integration the same, I think it would make sense to move
the CONFIG_SOC_ stuff out from ARM, RISC-V, etc., into something that's
not CPU architecture-specific. But for the time being, that seems
premature. Might as well have it be driven by an actual use-case.
- Paul
On Sat, Jun 08, 2019 at 10:50:14PM -0700, Paul Walmsley wrote:
> Once there are SoC variants that have different CPU cores, but with the
> remaining chip integration the same, I think it would make sense to move
> the CONFIG_SOC_ stuff out from ARM, RISC-V, etc., into something that's
> not CPU architecture-specific. But for the time being, that seems
> premature. Might as well have it be driven by an actual use-case.
We've already had a few SOC families with the same periphals glue and
either m68k/powerpc, powerpc/mips or mips/arm/arm64 CPUs, so this isn't
exactly new. Not really sure the grouping adds that much value, though.