| Message ID | 20200212103432.660256-5-damien.lemoal@wdc.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Kendryte k210 SoC boards support | expand |
On Wed, Feb 12, 2020 at 4:05 PM Damien Le Moal <damien.lemoal@wdc.com> wrote: > > Enable a kernel builtin dtb for boards not capable of providing a > device tree to the kernel. > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> This is a good feature addition for Linux RISC-V kernel. Looks good to me. Reviewed-by: Anup Patel <anup@brainfault.org> Regards, Anup > --- > arch/riscv/Kbuild | 1 + > arch/riscv/Kconfig | 18 ++++++++++++++++++ > arch/riscv/boot/dts/Makefile | 4 ++++ > arch/riscv/kernel/setup.c | 6 ++++++ > arch/riscv/mm/init.c | 4 ++++ > 5 files changed, 33 insertions(+) > > diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild > index d1d0aa70fdf1..988804e430e4 100644 > --- a/arch/riscv/Kbuild > +++ b/arch/riscv/Kbuild > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0-only > > obj-y += kernel/ mm/ net/ > +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 1a3b5a5276be..28899e15f548 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -355,6 +355,24 @@ config CMDLINE_FORCE > > endchoice > > +config USE_BUILTIN_DTB > + bool "Use builtin DTB" > + help > + Link a device tree blob for particular hardware into the kernel, > + suppressing use of the DTB pointer provided by the bootloader. > + This option should only be used with hardware or bootloaders that > + are not capable of providing a DTB to the kernel, or for > + experimental hardware without stable device tree bindings. > + > +config BUILTIN_DTB_SOURCE > + string "Source file for builtin DTB" > + default "" > + depends on USE_BUILTIN_DTB > + help > + Base name (without suffix, relative to arch/riscv/boot/dts) for > + the a DTS file that will be used to produce the DTB linked into > + the kernel. > + > endmenu > > menu "Power management options" > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile > index dcc3ada78455..0bf2669aa12d 100644 > --- a/arch/riscv/boot/dts/Makefile > +++ b/arch/riscv/boot/dts/Makefile > @@ -1,2 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") > +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o > +else > subdir-y += sifive > +endif > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > index 0a6d415b0a5a..3e89be9d888c 100644 > --- a/arch/riscv/kernel/setup.c > +++ b/arch/riscv/kernel/setup.c > @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) > > setup_bootmem(); > paging_init(); > + > +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > + unflatten_and_copy_device_tree(); > +#else > unflatten_device_tree(); > +#endif > + > clint_init_boot_cpu(); > > #ifdef CONFIG_SWIOTLB > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 965a8cf4829c..1274e889d008 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) > #else > asmlinkage void __init setup_vm(uintptr_t dtb_pa) > { > +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > + dtb_early_va = __dtb_start; > +#else > dtb_early_va = (void *)dtb_pa; > +#endif > } > > static inline void setup_vm_final(void) > -- > 2.24.1 > >
On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: > Enable a kernel builtin dtb for boards not capable of providing a > device tree to the kernel. I'd prefer if we picked a mechanism that allows a single kernel binary to be run on multiple systems. I think there's two use cases here: * Bootloaders that provide no DTB at all. * Bootloaders that provied a DTB that, for some reason, isn't usable. Given those constraints, could we do something similar to the early fixups? I'm thinking we could build a mapping between a hardware identifier and a DTB, then look up the DTB we want to use. Users that want a kernel that only runs on a single device can do so by configuring only a single DTB, users that want a more portable kernel can select a bunch -- that's essentially the same as how we're treating everything else (for example, the CONFIG_SOC_* stuff). For the hardware ID, could we do something like: * Check for the top-level DT compatible string, on systems where we have a provided DTB. * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some sort of masking functionality if we later need one. These are availiable via SBI calls, but I'd be inclined to restrict them to M-mode boot and just say the SBI must provide a device tree with at least a suitable compatible string. While I suppose we could put together a tool for generating these tables, for now we could probably just stick the mappings in a table for now given that there's only one of them. That said, I'm not sure what to do about the different Kendryte boards -- is there any way to poke the hardware to see which is which? > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> > --- > arch/riscv/Kbuild | 1 + > arch/riscv/Kconfig | 18 ++++++++++++++++++ > arch/riscv/boot/dts/Makefile | 4 ++++ > arch/riscv/kernel/setup.c | 6 ++++++ > arch/riscv/mm/init.c | 4 ++++ > 5 files changed, 33 insertions(+) > > diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild > index d1d0aa70fdf1..988804e430e4 100644 > --- a/arch/riscv/Kbuild > +++ b/arch/riscv/Kbuild > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0-only > > obj-y += kernel/ mm/ net/ > +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 1a3b5a5276be..28899e15f548 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -355,6 +355,24 @@ config CMDLINE_FORCE > > endchoice > > +config USE_BUILTIN_DTB > + bool "Use builtin DTB" > + help > + Link a device tree blob for particular hardware into the kernel, > + suppressing use of the DTB pointer provided by the bootloader. > + This option should only be used with hardware or bootloaders that > + are not capable of providing a DTB to the kernel, or for > + experimental hardware without stable device tree bindings. > + > +config BUILTIN_DTB_SOURCE > + string "Source file for builtin DTB" > + default "" > + depends on USE_BUILTIN_DTB > + help > + Base name (without suffix, relative to arch/riscv/boot/dts) for > + the a DTS file that will be used to produce the DTB linked into > + the kernel. > + > endmenu > > menu "Power management options" > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile > index dcc3ada78455..0bf2669aa12d 100644 > --- a/arch/riscv/boot/dts/Makefile > +++ b/arch/riscv/boot/dts/Makefile > @@ -1,2 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") > +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o > +else > subdir-y += sifive > +endif > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > index 0a6d415b0a5a..3e89be9d888c 100644 > --- a/arch/riscv/kernel/setup.c > +++ b/arch/riscv/kernel/setup.c > @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) > > setup_bootmem(); > paging_init(); > + > +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > + unflatten_and_copy_device_tree(); > +#else > unflatten_device_tree(); > +#endif > + > clint_init_boot_cpu(); > > #ifdef CONFIG_SWIOTLB > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 965a8cf4829c..1274e889d008 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) > #else > asmlinkage void __init setup_vm(uintptr_t dtb_pa) > { > +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > + dtb_early_va = __dtb_start; > +#else > dtb_early_va = (void *)dtb_pa; > +#endif > } > > static inline void setup_vm_final(void)
> -----Original Message----- > From: Palmer Dabbelt <palmer@dabbelt.com> > Sent: 05 March 2020 00:59 > To: Damien Le Moal <Damien.LeMoal@wdc.com> > Cc: linux-riscv@lists.infradead.org; Paul Walmsley > <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> > Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support > > On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: > > Enable a kernel builtin dtb for boards not capable of providing a > > device tree to the kernel. > > I'd prefer if we picked a mechanism that allows a single kernel binary to be > run on multiple systems. I think there's two use cases here: I strongly support "single kernel binary for multiple systems" but it's for different purpose here. > > * Bootloaders that provide no DTB at all. > * Bootloaders that provied a DTB that, for some reason, isn't usable. > > Given those constraints, could we do something similar to the early fixups? > I'm thinking we could build a mapping between a hardware identifier and a > DTB, then look up the DTB we want to use. Users that want a kernel that > only runs on a single device can do so by configuring only a single DTB, users > that want a more portable kernel can select a bunch -- that's essentially the > same as how we're treating everything else (for example, the > CONFIG_SOC_* stuff). There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel boots directly. The BUILTIN_DTB is only applicable to cases where there is no bootloader before kernel. The Linux RISC-V NOMMU will tend be used in cases where: 1. There is no bootloader and kernel boots directly hence we need builtin DTB feature. 2. There is very less RAM so we will have to build kernel specific to a particular platform with bare minimum drivers. Due to this, we will have separate defconfig for NOMMU platforms. I think point1 can be tackled if we enforce having bootloader (such as U-Boot) for NOMMU systems and drop this patch. For point2 above, we don't have much alternatives other than reducing kernel binary size by disabling unwanted drivers. > > For the hardware ID, could we do something like: > > * Check for the top-level DT compatible string, on systems where we have a > provided DTB. > * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some > sort of > masking functionality if we later need one. These are availiable via SBI > calls, but I'd be inclined to restrict them to M-mode boot and just say the > SBI must provide a device tree with at least a suitable compatible string. > > While I suppose we could put together a tool for generating these tables, for > now we could probably just stick the mappings in a table for now given that > there's only one of them. > > That said, I'm not sure what to do about the different Kendryte boards -- is > there any way to poke the hardware to see which is which? I am sure there are two three different boards out there. Don't know exact differences between these boards. Regards, Anup > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> > > --- > > arch/riscv/Kbuild | 1 + > > arch/riscv/Kconfig | 18 ++++++++++++++++++ > > arch/riscv/boot/dts/Makefile | 4 ++++ > > arch/riscv/kernel/setup.c | 6 ++++++ > > arch/riscv/mm/init.c | 4 ++++ > > 5 files changed, 33 insertions(+) > > > > diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index > > d1d0aa70fdf1..988804e430e4 100644 > > --- a/arch/riscv/Kbuild > > +++ b/arch/riscv/Kbuild > > @@ -1,3 +1,4 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > > > obj-y += kernel/ mm/ net/ > > +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > > 1a3b5a5276be..28899e15f548 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -355,6 +355,24 @@ config CMDLINE_FORCE > > > > endchoice > > > > +config USE_BUILTIN_DTB > > + bool "Use builtin DTB" > > + help > > + Link a device tree blob for particular hardware into the kernel, > > + suppressing use of the DTB pointer provided by the bootloader. > > + This option should only be used with hardware or bootloaders that > > + are not capable of providing a DTB to the kernel, or for > > + experimental hardware without stable device tree bindings. > > + > > +config BUILTIN_DTB_SOURCE > > + string "Source file for builtin DTB" > > + default "" > > + depends on USE_BUILTIN_DTB > > + help > > + Base name (without suffix, relative to arch/riscv/boot/dts) for > > + the a DTS file that will be used to produce the DTB linked into > > + the kernel. > > + > > endmenu > > > > menu "Power management options" > > diff --git a/arch/riscv/boot/dts/Makefile > > b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d 100644 > > --- a/arch/riscv/boot/dts/Makefile > > +++ b/arch/riscv/boot/dts/Makefile > > @@ -1,2 +1,6 @@ > > # SPDX-License-Identifier: GPL-2.0 > > +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") > > +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst > > +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o > > +else > > subdir-y += sifive > > +endif > > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > > index 0a6d415b0a5a..3e89be9d888c 100644 > > --- a/arch/riscv/kernel/setup.c > > +++ b/arch/riscv/kernel/setup.c > > @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) > > > > setup_bootmem(); > > paging_init(); > > + > > +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > > + unflatten_and_copy_device_tree(); > > +#else > > unflatten_device_tree(); > > +#endif > > + > > clint_init_boot_cpu(); > > > > #ifdef CONFIG_SWIOTLB > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index > > 965a8cf4829c..1274e889d008 100644 > > --- a/arch/riscv/mm/init.c > > +++ b/arch/riscv/mm/init.c > > @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else > > asmlinkage void __init setup_vm(uintptr_t dtb_pa) { > > +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > > + dtb_early_va = __dtb_start; > > +#else > > dtb_early_va = (void *)dtb_pa; > > +#endif > > } > > > > static inline void setup_vm_final(void)
On 2020/03/05 13:58, Anup Patel wrote: > > >> -----Original Message----- >> From: Palmer Dabbelt <palmer@dabbelt.com> >> Sent: 05 March 2020 00:59 >> To: Damien Le Moal <Damien.LeMoal@wdc.com> >> Cc: linux-riscv@lists.infradead.org; Paul Walmsley >> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> >> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support >> >> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: >>> Enable a kernel builtin dtb for boards not capable of providing a >>> device tree to the kernel. >> >> I'd prefer if we picked a mechanism that allows a single kernel binary to be >> run on multiple systems. I think there's two use cases here: > > I strongly support "single kernel binary for multiple systems" but it's for > different purpose here. > >> >> * Bootloaders that provide no DTB at all. >> * Bootloaders that provied a DTB that, for some reason, isn't usable. Sure, but as Anup mentions below, the current use case it to not even use any bootloader at all for the K210 since that brings no value at all (in my opinion). More on this below. >> >> Given those constraints, could we do something similar to the early fixups? >> I'm thinking we could build a mapping between a hardware identifier and a >> DTB, then look up the DTB we want to use. Users that want a kernel that >> only runs on a single device can do so by configuring only a single DTB, users >> that want a more portable kernel can select a bunch -- that's essentially the >> same as how we're treating everything else (for example, the >> CONFIG_SOC_* stuff). > > There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel > boots directly. The BUILTIN_DTB is only applicable to cases where there is > no bootloader before kernel. > > The Linux RISC-V NOMMU will tend be used in cases where: > 1. There is no bootloader and kernel boots directly hence we need > builtin DTB feature. > 2. There is very less RAM so we will have to build kernel specific to > a particular platform with bare minimum drivers. Due to this, we will > have separate defconfig for NOMMU platforms. > > I think point1 can be tackled if we enforce having bootloader (such as U-Boot) > for NOMMU systems and drop this patch. But that would go against point 2 as that will use more memory... By "drop this patch", may be you meant to say "not use this config option" ? > For point2 above, we don't have much alternatives other than reducing > kernel binary size by disabling unwanted drivers. And not using a boot loader. Sean got U-boot working with Kendryte, so it is not that we cannot make it work. It is only that it may be less optimal due to the memory used by the boot loader itself. Unless we can recover it if the kernel relocate itself over it ? Surely doable, but it does sound to me like an overkill for this particular use case, i.e. a tiny, hyper-embedded board where running Linux is probably not the best choice in the first place, at least when looking at real applications. The story is different for "hobbyist" level. My on-going 6 DoF robotic arm project controlled with Linux on K210 is a valid use case after all :) > >> >> For the hardware ID, could we do something like: >> >> * Check for the top-level DT compatible string, on systems where we have a >> provided DTB. >> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some >> sort of >> masking functionality if we later need one. These are availiable via SBI >> calls, but I'd be inclined to restrict them to M-mode boot and just say the >> SBI must provide a device tree with at least a suitable compatible string. >> >> While I suppose we could put together a tool for generating these tables, for >> now we could probably just stick the mappings in a table for now given that >> there's only one of them. >> >> That said, I'm not sure what to do about the different Kendryte boards -- is >> there any way to poke the hardware to see which is which? > > I am sure there are two three different boards out there. Don't know exact > differences between these boards. As far as I can tell, all the boards use the exact same SoC. No differences that I can detect nor aware of. What differs between the different flavors of boards are the perypherals attached: some have WiFi, different LCDs and different cameras. The device tree is able to describe that of course, but the core dtsi part for the SoC itself seem to be OK at least for the 4 different boards I have (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan Dock). > > Regards, > Anup > >> >>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> >>> --- >>> arch/riscv/Kbuild | 1 + >>> arch/riscv/Kconfig | 18 ++++++++++++++++++ >>> arch/riscv/boot/dts/Makefile | 4 ++++ >>> arch/riscv/kernel/setup.c | 6 ++++++ >>> arch/riscv/mm/init.c | 4 ++++ >>> 5 files changed, 33 insertions(+) >>> >>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index >>> d1d0aa70fdf1..988804e430e4 100644 >>> --- a/arch/riscv/Kbuild >>> +++ b/arch/riscv/Kbuild >>> @@ -1,3 +1,4 @@ >>> # SPDX-License-Identifier: GPL-2.0-only >>> >>> obj-y += kernel/ mm/ net/ >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index >>> 1a3b5a5276be..28899e15f548 100644 >>> --- a/arch/riscv/Kconfig >>> +++ b/arch/riscv/Kconfig >>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE >>> >>> endchoice >>> >>> +config USE_BUILTIN_DTB >>> + bool "Use builtin DTB" >>> + help >>> + Link a device tree blob for particular hardware into the kernel, >>> + suppressing use of the DTB pointer provided by the bootloader. >>> + This option should only be used with hardware or bootloaders that >>> + are not capable of providing a DTB to the kernel, or for >>> + experimental hardware without stable device tree bindings. >>> + >>> +config BUILTIN_DTB_SOURCE >>> + string "Source file for builtin DTB" >>> + default "" >>> + depends on USE_BUILTIN_DTB >>> + help >>> + Base name (without suffix, relative to arch/riscv/boot/dts) for >>> + the a DTS file that will be used to produce the DTB linked into >>> + the kernel. >>> + >>> endmenu >>> >>> menu "Power management options" >>> diff --git a/arch/riscv/boot/dts/Makefile >>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d 100644 >>> --- a/arch/riscv/boot/dts/Makefile >>> +++ b/arch/riscv/boot/dts/Makefile >>> @@ -1,2 +1,6 @@ >>> # SPDX-License-Identifier: GPL-2.0 >>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst >>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o >>> +else >>> subdir-y += sifive >>> +endif >>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c >>> index 0a6d415b0a5a..3e89be9d888c 100644 >>> --- a/arch/riscv/kernel/setup.c >>> +++ b/arch/riscv/kernel/setup.c >>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) >>> >>> setup_bootmem(); >>> paging_init(); >>> + >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) >>> + unflatten_and_copy_device_tree(); >>> +#else >>> unflatten_device_tree(); >>> +#endif >>> + >>> clint_init_boot_cpu(); >>> >>> #ifdef CONFIG_SWIOTLB >>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index >>> 965a8cf4829c..1274e889d008 100644 >>> --- a/arch/riscv/mm/init.c >>> +++ b/arch/riscv/mm/init.c >>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else >>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) { >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) >>> + dtb_early_va = __dtb_start; >>> +#else >>> dtb_early_va = (void *)dtb_pa; >>> +#endif >>> } >>> >>> static inline void setup_vm_final(void) >
> -----Original Message----- > From: Damien Le Moal > Sent: 05 March 2020 10:44 > To: Anup Patel <Anup.Patel@wdc.com>; Palmer Dabbelt > <palmer@dabbelt.com> > Cc: linux-riscv@lists.infradead.org; Paul Walmsley > <paul.walmsley@sifive.com> > Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support > > On 2020/03/05 13:58, Anup Patel wrote: > > > > > >> -----Original Message----- > >> From: Palmer Dabbelt <palmer@dabbelt.com> > >> Sent: 05 March 2020 00:59 > >> To: Damien Le Moal <Damien.LeMoal@wdc.com> > >> Cc: linux-riscv@lists.infradead.org; Paul Walmsley > >> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> > >> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support > >> > >> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: > >>> Enable a kernel builtin dtb for boards not capable of providing a > >>> device tree to the kernel. > >> > >> I'd prefer if we picked a mechanism that allows a single kernel > >> binary to be run on multiple systems. I think there's two use cases here: > > > > I strongly support "single kernel binary for multiple systems" but > > it's for different purpose here. > > > >> > >> * Bootloaders that provide no DTB at all. > >> * Bootloaders that provied a DTB that, for some reason, isn't usable. > > Sure, but as Anup mentions below, the current use case it to not even use > any bootloader at all for the K210 since that brings no value at all (in my > opinion). More on this below. > > >> > >> Given those constraints, could we do something similar to the early > fixups? > >> I'm thinking we could build a mapping between a hardware identifier > >> and a DTB, then look up the DTB we want to use. Users that want a > >> kernel that only runs on a single device can do so by configuring > >> only a single DTB, users that want a more portable kernel can select > >> a bunch -- that's essentially the same as how we're treating > >> everything else (for example, the > >> CONFIG_SOC_* stuff). > > > > There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel > > boots directly. The BUILTIN_DTB is only applicable to cases where > > there is no bootloader before kernel. > > > > The Linux RISC-V NOMMU will tend be used in cases where: > > 1. There is no bootloader and kernel boots directly hence we need > > builtin DTB feature. > > 2. There is very less RAM so we will have to build kernel specific to > > a particular platform with bare minimum drivers. Due to this, we will > > have separate defconfig for NOMMU platforms. > > > > I think point1 can be tackled if we enforce having bootloader (such as > > U-Boot) for NOMMU systems and drop this patch. > > But that would go against point 2 as that will use more memory... By "drop > this patch", may be you meant to say "not use this config option" ? I meant to use U-Boot on Kendryte to launch kernel. > > > For point2 above, we don't have much alternatives other than reducing > > kernel binary size by disabling unwanted drivers. > > And not using a boot loader. Sean got U-boot working with Kendryte, so it is > not that we cannot make it work. It is only that it may be less optimal due to > the memory used by the boot loader itself. Unless we can recover it if the > kernel relocate itself over it ? Surely doable, but it does sound to me like an > overkill for this particular use case, i.e. a tiny, hyper-embedded board where > running Linux is probably not the best choice in the first place, at least when > looking at real applications. The story is different for "hobbyist" level. My on- > going 6 DoF robotic arm project controlled with Linux on K210 is a valid use > case after all :) Dropping BUILTIN DTB feature will be more like a Linux RISC-V policy thingy. My suggestion was more about discouraging Linux S-mode users to use the BUILTIN DTB feature. I agree that it is difficult to fit a proper boot-flow (having proper bootloader) due to limited RAM. If we don't link DTB to Linux RISC-V NOMMU then some thing else need to provide it hence bootloader suggestion. Apart from the Linux RISC-V NOMMU use-case, the BUILTIN DTB feature can be useful in environments such as FPGAs/Palladium where proper bootloader is not available. Regards, Anup > > > > >> > >> For the hardware ID, could we do something like: > >> > >> * Check for the top-level DT compatible string, on systems where we > have a > >> provided DTB. > >> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with > >> some sort of > >> masking functionality if we later need one. These are availiable via SBI > >> calls, but I'd be inclined to restrict them to M-mode boot and just say the > >> SBI must provide a device tree with at least a suitable compatible string. > >> > >> While I suppose we could put together a tool for generating these > >> tables, for now we could probably just stick the mappings in a table > >> for now given that there's only one of them. > >> > >> That said, I'm not sure what to do about the different Kendryte > >> boards -- is there any way to poke the hardware to see which is which? > > > > I am sure there are two three different boards out there. Don't know > > exact differences between these boards. > > As far as I can tell, all the boards use the exact same SoC. No differences that > I can detect nor aware of. What differs between the different flavors of > boards are the perypherals attached: some have WiFi, different LCDs and > different cameras. The device tree is able to describe that of course, but the > core dtsi part for the SoC itself seem to be OK at least for the 4 different > boards I have (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan > Dock). > > > > > Regards, > > Anup > > > >> > >>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> > >>> --- > >>> arch/riscv/Kbuild | 1 + > >>> arch/riscv/Kconfig | 18 ++++++++++++++++++ > >>> arch/riscv/boot/dts/Makefile | 4 ++++ > >>> arch/riscv/kernel/setup.c | 6 ++++++ > >>> arch/riscv/mm/init.c | 4 ++++ > >>> 5 files changed, 33 insertions(+) > >>> > >>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index > >>> d1d0aa70fdf1..988804e430e4 100644 > >>> --- a/arch/riscv/Kbuild > >>> +++ b/arch/riscv/Kbuild > >>> @@ -1,3 +1,4 @@ > >>> # SPDX-License-Identifier: GPL-2.0-only > >>> > >>> obj-y += kernel/ mm/ net/ > >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ > >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > >>> 1a3b5a5276be..28899e15f548 100644 > >>> --- a/arch/riscv/Kconfig > >>> +++ b/arch/riscv/Kconfig > >>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE > >>> > >>> endchoice > >>> > >>> +config USE_BUILTIN_DTB > >>> + bool "Use builtin DTB" > >>> + help > >>> + Link a device tree blob for particular hardware into the kernel, > >>> + suppressing use of the DTB pointer provided by the bootloader. > >>> + This option should only be used with hardware or bootloaders that > >>> + are not capable of providing a DTB to the kernel, or for > >>> + experimental hardware without stable device tree bindings. > >>> + > >>> +config BUILTIN_DTB_SOURCE > >>> + string "Source file for builtin DTB" > >>> + default "" > >>> + depends on USE_BUILTIN_DTB > >>> + help > >>> + Base name (without suffix, relative to arch/riscv/boot/dts) for > >>> + the a DTS file that will be used to produce the DTB linked into > >>> + the kernel. > >>> + > >>> endmenu > >>> > >>> menu "Power management options" > >>> diff --git a/arch/riscv/boot/dts/Makefile > >>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d > >>> 100644 > >>> --- a/arch/riscv/boot/dts/Makefile > >>> +++ b/arch/riscv/boot/dts/Makefile > >>> @@ -1,2 +1,6 @@ > >>> # SPDX-License-Identifier: GPL-2.0 > >>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") > >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst > >>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o > >>> +else > >>> subdir-y += sifive > >>> +endif > >>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > >>> index 0a6d415b0a5a..3e89be9d888c 100644 > >>> --- a/arch/riscv/kernel/setup.c > >>> +++ b/arch/riscv/kernel/setup.c > >>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) > >>> > >>> setup_bootmem(); > >>> paging_init(); > >>> + > >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > >>> + unflatten_and_copy_device_tree(); > >>> +#else > >>> unflatten_device_tree(); > >>> +#endif > >>> + > >>> clint_init_boot_cpu(); > >>> > >>> #ifdef CONFIG_SWIOTLB > >>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index > >>> 965a8cf4829c..1274e889d008 100644 > >>> --- a/arch/riscv/mm/init.c > >>> +++ b/arch/riscv/mm/init.c > >>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else > >>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) { > >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > >>> + dtb_early_va = __dtb_start; > >>> +#else > >>> dtb_early_va = (void *)dtb_pa; > >>> +#endif > >>> } > >>> > >>> static inline void setup_vm_final(void) > > > > > -- > Damien Le Moal > Western Digital Research
On 2020/03/05 14:37, Anup Patel wrote: > > >> -----Original Message----- >> From: Damien Le Moal >> Sent: 05 March 2020 10:44 >> To: Anup Patel <Anup.Patel@wdc.com>; Palmer Dabbelt >> <palmer@dabbelt.com> >> Cc: linux-riscv@lists.infradead.org; Paul Walmsley >> <paul.walmsley@sifive.com> >> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support >> >> On 2020/03/05 13:58, Anup Patel wrote: >>> >>> >>>> -----Original Message----- >>>> From: Palmer Dabbelt <palmer@dabbelt.com> >>>> Sent: 05 March 2020 00:59 >>>> To: Damien Le Moal <Damien.LeMoal@wdc.com> >>>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley >>>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> >>>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support >>>> >>>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: >>>>> Enable a kernel builtin dtb for boards not capable of providing a >>>>> device tree to the kernel. >>>> >>>> I'd prefer if we picked a mechanism that allows a single kernel >>>> binary to be run on multiple systems. I think there's two use cases here: >>> >>> I strongly support "single kernel binary for multiple systems" but >>> it's for different purpose here. >>> >>>> >>>> * Bootloaders that provide no DTB at all. >>>> * Bootloaders that provied a DTB that, for some reason, isn't usable. >> >> Sure, but as Anup mentions below, the current use case it to not even use >> any bootloader at all for the K210 since that brings no value at all (in my >> opinion). More on this below. >> >>>> >>>> Given those constraints, could we do something similar to the early >> fixups? >>>> I'm thinking we could build a mapping between a hardware identifier >>>> and a DTB, then look up the DTB we want to use. Users that want a >>>> kernel that only runs on a single device can do so by configuring >>>> only a single DTB, users that want a more portable kernel can select >>>> a bunch -- that's essentially the same as how we're treating >>>> everything else (for example, the >>>> CONFIG_SOC_* stuff). >>> >>> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel >>> boots directly. The BUILTIN_DTB is only applicable to cases where >>> there is no bootloader before kernel. >>> >>> The Linux RISC-V NOMMU will tend be used in cases where: >>> 1. There is no bootloader and kernel boots directly hence we need >>> builtin DTB feature. >>> 2. There is very less RAM so we will have to build kernel specific to >>> a particular platform with bare minimum drivers. Due to this, we will >>> have separate defconfig for NOMMU platforms. >>> >>> I think point1 can be tackled if we enforce having bootloader (such as >>> U-Boot) for NOMMU systems and drop this patch. >> >> But that would go against point 2 as that will use more memory... By "drop >> this patch", may be you meant to say "not use this config option" ? > > I meant to use U-Boot on Kendryte to launch kernel. > >> >>> For point2 above, we don't have much alternatives other than reducing >>> kernel binary size by disabling unwanted drivers. >> >> And not using a boot loader. Sean got U-boot working with Kendryte, so it is >> not that we cannot make it work. It is only that it may be less optimal due to >> the memory used by the boot loader itself. Unless we can recover it if the >> kernel relocate itself over it ? Surely doable, but it does sound to me like an >> overkill for this particular use case, i.e. a tiny, hyper-embedded board where >> running Linux is probably not the best choice in the first place, at least when >> looking at real applications. The story is different for "hobbyist" level. My on- >> going 6 DoF robotic arm project controlled with Linux on K210 is a valid use >> case after all :) > > Dropping BUILTIN DTB feature will be more like a Linux RISC-V policy thingy. > My suggestion was more about discouraging Linux S-mode users to use the > BUILTIN DTB feature. Got it. For now, we could tie BUILTIN DTB config to !MMU case only. If there is a valid use case that pops up for regular MMU/S-mode Linux, it is easy to change. > I agree that it is difficult to fit a proper boot-flow (having proper bootloader) > due to limited RAM. If we don't link DTB to Linux RISC-V NOMMU then some > thing else need to provide it hence bootloader suggestion. OK. Understood and I agree. > > Apart from the Linux RISC-V NOMMU use-case, the BUILTIN DTB feature can > be useful in environments such as FPGAs/Palladium where proper bootloader > is not available. OK. But we do not have to enable it for this right away, no ? So should I just not allow BUILTIN DTB for MMU==true case for now ? > > Regards, > Anup > >> >>> >>>> >>>> For the hardware ID, could we do something like: >>>> >>>> * Check for the top-level DT compatible string, on systems where we >> have a >>>> provided DTB. >>>> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with >>>> some sort of >>>> masking functionality if we later need one. These are availiable via SBI >>>> calls, but I'd be inclined to restrict them to M-mode boot and just say the >>>> SBI must provide a device tree with at least a suitable compatible string. >>>> >>>> While I suppose we could put together a tool for generating these >>>> tables, for now we could probably just stick the mappings in a table >>>> for now given that there's only one of them. >>>> >>>> That said, I'm not sure what to do about the different Kendryte >>>> boards -- is there any way to poke the hardware to see which is which? >>> >>> I am sure there are two three different boards out there. Don't know >>> exact differences between these boards. >> >> As far as I can tell, all the boards use the exact same SoC. No differences that >> I can detect nor aware of. What differs between the different flavors of >> boards are the perypherals attached: some have WiFi, different LCDs and >> different cameras. The device tree is able to describe that of course, but the >> core dtsi part for the SoC itself seem to be OK at least for the 4 different >> boards I have (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan >> Dock). >> >>> >>> Regards, >>> Anup >>> >>>> >>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> >>>>> --- >>>>> arch/riscv/Kbuild | 1 + >>>>> arch/riscv/Kconfig | 18 ++++++++++++++++++ >>>>> arch/riscv/boot/dts/Makefile | 4 ++++ >>>>> arch/riscv/kernel/setup.c | 6 ++++++ >>>>> arch/riscv/mm/init.c | 4 ++++ >>>>> 5 files changed, 33 insertions(+) >>>>> >>>>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index >>>>> d1d0aa70fdf1..988804e430e4 100644 >>>>> --- a/arch/riscv/Kbuild >>>>> +++ b/arch/riscv/Kbuild >>>>> @@ -1,3 +1,4 @@ >>>>> # SPDX-License-Identifier: GPL-2.0-only >>>>> >>>>> obj-y += kernel/ mm/ net/ >>>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ >>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index >>>>> 1a3b5a5276be..28899e15f548 100644 >>>>> --- a/arch/riscv/Kconfig >>>>> +++ b/arch/riscv/Kconfig >>>>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE >>>>> >>>>> endchoice >>>>> >>>>> +config USE_BUILTIN_DTB >>>>> + bool "Use builtin DTB" >>>>> + help >>>>> + Link a device tree blob for particular hardware into the kernel, >>>>> + suppressing use of the DTB pointer provided by the bootloader. >>>>> + This option should only be used with hardware or bootloaders that >>>>> + are not capable of providing a DTB to the kernel, or for >>>>> + experimental hardware without stable device tree bindings. >>>>> + >>>>> +config BUILTIN_DTB_SOURCE >>>>> + string "Source file for builtin DTB" >>>>> + default "" >>>>> + depends on USE_BUILTIN_DTB >>>>> + help >>>>> + Base name (without suffix, relative to arch/riscv/boot/dts) for >>>>> + the a DTS file that will be used to produce the DTB linked into >>>>> + the kernel. >>>>> + >>>>> endmenu >>>>> >>>>> menu "Power management options" >>>>> diff --git a/arch/riscv/boot/dts/Makefile >>>>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d >>>>> 100644 >>>>> --- a/arch/riscv/boot/dts/Makefile >>>>> +++ b/arch/riscv/boot/dts/Makefile >>>>> @@ -1,2 +1,6 @@ >>>>> # SPDX-License-Identifier: GPL-2.0 >>>>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") >>>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst >>>>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o >>>>> +else >>>>> subdir-y += sifive >>>>> +endif >>>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c >>>>> index 0a6d415b0a5a..3e89be9d888c 100644 >>>>> --- a/arch/riscv/kernel/setup.c >>>>> +++ b/arch/riscv/kernel/setup.c >>>>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) >>>>> >>>>> setup_bootmem(); >>>>> paging_init(); >>>>> + >>>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) >>>>> + unflatten_and_copy_device_tree(); >>>>> +#else >>>>> unflatten_device_tree(); >>>>> +#endif >>>>> + >>>>> clint_init_boot_cpu(); >>>>> >>>>> #ifdef CONFIG_SWIOTLB >>>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index >>>>> 965a8cf4829c..1274e889d008 100644 >>>>> --- a/arch/riscv/mm/init.c >>>>> +++ b/arch/riscv/mm/init.c >>>>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else >>>>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) { >>>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) >>>>> + dtb_early_va = __dtb_start; >>>>> +#else >>>>> dtb_early_va = (void *)dtb_pa; >>>>> +#endif >>>>> } >>>>> >>>>> static inline void setup_vm_final(void) >>> >> >> >> -- >> Damien Le Moal >> Western Digital Research >
On Wed, Mar 4, 2020 at 9:14 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote: > > On 2020/03/05 13:58, Anup Patel wrote: > > > > > >> -----Original Message----- > >> From: Palmer Dabbelt <palmer@dabbelt.com> > >> Sent: 05 March 2020 00:59 > >> To: Damien Le Moal <Damien.LeMoal@wdc.com> > >> Cc: linux-riscv@lists.infradead.org; Paul Walmsley > >> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> > >> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support > >> > >> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: > >>> Enable a kernel builtin dtb for boards not capable of providing a > >>> device tree to the kernel. > >> > >> I'd prefer if we picked a mechanism that allows a single kernel binary to be > >> run on multiple systems. I think there's two use cases here: > > > > I strongly support "single kernel binary for multiple systems" but it's for > > different purpose here. > > > >> > >> * Bootloaders that provide no DTB at all. > >> * Bootloaders that provied a DTB that, for some reason, isn't usable. > > Sure, but as Anup mentions below, the current use case it to not even use any > bootloader at all for the K210 since that brings no value at all (in my > opinion). More on this below. > > >> > >> Given those constraints, could we do something similar to the early fixups? > >> I'm thinking we could build a mapping between a hardware identifier and a > >> DTB, then look up the DTB we want to use. Users that want a kernel that > >> only runs on a single device can do so by configuring only a single DTB, users > >> that want a more portable kernel can select a bunch -- that's essentially the > >> same as how we're treating everything else (for example, the > >> CONFIG_SOC_* stuff). > > > > There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel > > boots directly. The BUILTIN_DTB is only applicable to cases where there is > > no bootloader before kernel. > > > > The Linux RISC-V NOMMU will tend be used in cases where: > > 1. There is no bootloader and kernel boots directly hence we need > > builtin DTB feature. > > 2. There is very less RAM so we will have to build kernel specific to > > a particular platform with bare minimum drivers. Due to this, we will > > have separate defconfig for NOMMU platforms. > > > > I think point1 can be tackled if we enforce having bootloader (such as U-Boot) > > for NOMMU systems and drop this patch. > > But that would go against point 2 as that will use more memory... By "drop this > patch", may be you meant to say "not use this config option" ? > > > For point2 above, we don't have much alternatives other than reducing > > kernel binary size by disabling unwanted drivers. > > And not using a boot loader. Sean got U-boot working with Kendryte, so it is not > that we cannot make it work. It is only that it may be less optimal due to the > memory used by the boot loader itself. Unless we can recover it if the kernel > relocate itself over it ? Surely doable, but it does sound to me like an > overkill for this particular use case, i.e. a tiny, hyper-embedded board where > running Linux is probably not the best choice in the first place, at least when > looking at real applications. The story is different for "hobbyist" level. My > on-going 6 DoF robotic arm project controlled with Linux on K210 is a valid use > case after all :) > Just a thought: How about keeping the loader out of kernel as a separate project as a tinyloader ? That tinyloader project can host the DTB and pass it to kernel in a1 register. This tinyloader can be used for any M-mode only platforms with memory constraints. If platform has sufficient memory and supports U-boot, users can use that as well. That will allow single kernel image to boot all the platforms and we can mandate one booting protocol for all platforms. Otherwise, we have to specify different booting protocol for M-Mode/NoMMU linux and S-mode Linux. In future, there may be more platforms with Builtin DTB request as well. > > > >> > >> For the hardware ID, could we do something like: > >> > >> * Check for the top-level DT compatible string, on systems where we have a > >> provided DTB. > >> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some > >> sort of > >> masking functionality if we later need one. These are availiable via SBI > >> calls, but I'd be inclined to restrict them to M-mode boot and just say the > >> SBI must provide a device tree with at least a suitable compatible string. > >> > >> While I suppose we could put together a tool for generating these tables, for > >> now we could probably just stick the mappings in a table for now given that > >> there's only one of them. > >> > >> That said, I'm not sure what to do about the different Kendryte boards -- is > >> there any way to poke the hardware to see which is which? > > > > I am sure there are two three different boards out there. Don't know exact > > differences between these boards. > > As far as I can tell, all the boards use the exact same SoC. No differences that > I can detect nor aware of. What differs between the different flavors of boards > are the perypherals attached: some have WiFi, different LCDs and different > cameras. The device tree is able to describe that of course, but the core dtsi > part for the SoC itself seem to be OK at least for the 4 different boards I have > (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan Dock). > > > > > Regards, > > Anup > > > >> > >>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> > >>> --- > >>> arch/riscv/Kbuild | 1 + > >>> arch/riscv/Kconfig | 18 ++++++++++++++++++ > >>> arch/riscv/boot/dts/Makefile | 4 ++++ > >>> arch/riscv/kernel/setup.c | 6 ++++++ > >>> arch/riscv/mm/init.c | 4 ++++ > >>> 5 files changed, 33 insertions(+) > >>> > >>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index > >>> d1d0aa70fdf1..988804e430e4 100644 > >>> --- a/arch/riscv/Kbuild > >>> +++ b/arch/riscv/Kbuild > >>> @@ -1,3 +1,4 @@ > >>> # SPDX-License-Identifier: GPL-2.0-only > >>> > >>> obj-y += kernel/ mm/ net/ > >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ > >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > >>> 1a3b5a5276be..28899e15f548 100644 > >>> --- a/arch/riscv/Kconfig > >>> +++ b/arch/riscv/Kconfig > >>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE > >>> > >>> endchoice > >>> > >>> +config USE_BUILTIN_DTB > >>> + bool "Use builtin DTB" > >>> + help > >>> + Link a device tree blob for particular hardware into the kernel, > >>> + suppressing use of the DTB pointer provided by the bootloader. > >>> + This option should only be used with hardware or bootloaders that > >>> + are not capable of providing a DTB to the kernel, or for > >>> + experimental hardware without stable device tree bindings. > >>> + > >>> +config BUILTIN_DTB_SOURCE > >>> + string "Source file for builtin DTB" > >>> + default "" > >>> + depends on USE_BUILTIN_DTB > >>> + help > >>> + Base name (without suffix, relative to arch/riscv/boot/dts) for > >>> + the a DTS file that will be used to produce the DTB linked into > >>> + the kernel. > >>> + > >>> endmenu > >>> > >>> menu "Power management options" > >>> diff --git a/arch/riscv/boot/dts/Makefile > >>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d 100644 > >>> --- a/arch/riscv/boot/dts/Makefile > >>> +++ b/arch/riscv/boot/dts/Makefile > >>> @@ -1,2 +1,6 @@ > >>> # SPDX-License-Identifier: GPL-2.0 > >>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") > >>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst > >>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o > >>> +else > >>> subdir-y += sifive > >>> +endif > >>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > >>> index 0a6d415b0a5a..3e89be9d888c 100644 > >>> --- a/arch/riscv/kernel/setup.c > >>> +++ b/arch/riscv/kernel/setup.c > >>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) > >>> > >>> setup_bootmem(); > >>> paging_init(); > >>> + > >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > >>> + unflatten_and_copy_device_tree(); > >>> +#else > >>> unflatten_device_tree(); > >>> +#endif > >>> + > >>> clint_init_boot_cpu(); > >>> > >>> #ifdef CONFIG_SWIOTLB > >>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index > >>> 965a8cf4829c..1274e889d008 100644 > >>> --- a/arch/riscv/mm/init.c > >>> +++ b/arch/riscv/mm/init.c > >>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else > >>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) { > >>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > >>> + dtb_early_va = __dtb_start; > >>> +#else > >>> dtb_early_va = (void *)dtb_pa; > >>> +#endif > >>> } > >>> > >>> static inline void setup_vm_final(void) > > > > > -- > Damien Le Moal > Western Digital Research >
On 3/5/20 12:14 AM, Damien Le Moal wrote: > On 2020/03/05 13:58, Anup Patel wrote: >> >> >>> -----Original Message----- >>> From: Palmer Dabbelt <palmer@dabbelt.com> >>> Sent: 05 March 2020 00:59 >>> To: Damien Le Moal <Damien.LeMoal@wdc.com> >>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley >>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> >>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support >>> >>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: >>>> Enable a kernel builtin dtb for boards not capable of providing a >>>> device tree to the kernel. >>> >>> I'd prefer if we picked a mechanism that allows a single kernel binary to be >>> run on multiple systems. I think there's two use cases here: >> >> I strongly support "single kernel binary for multiple systems" but it's for >> different purpose here. >> >>> >>> * Bootloaders that provide no DTB at all. >>> * Bootloaders that provied a DTB that, for some reason, isn't usable. > > Sure, but as Anup mentions below, the current use case it to not even use any > bootloader at all for the K210 since that brings no value at all (in my > opinion). More on this below. > >>> >>> Given those constraints, could we do something similar to the early fixups? >>> I'm thinking we could build a mapping between a hardware identifier and a >>> DTB, then look up the DTB we want to use. Users that want a kernel that >>> only runs on a single device can do so by configuring only a single DTB, users >>> that want a more portable kernel can select a bunch -- that's essentially the >>> same as how we're treating everything else (for example, the >>> CONFIG_SOC_* stuff). >> >> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel >> boots directly. The BUILTIN_DTB is only applicable to cases where there is >> no bootloader before kernel. >> >> The Linux RISC-V NOMMU will tend be used in cases where: >> 1. There is no bootloader and kernel boots directly hence we need >> builtin DTB feature. >> 2. There is very less RAM so we will have to build kernel specific to >> a particular platform with bare minimum drivers. Due to this, we will >> have separate defconfig for NOMMU platforms. >> >> I think point1 can be tackled if we enforce having bootloader (such as U-Boot) >> for NOMMU systems and drop this patch. > > But that would go against point 2 as that will use more memory... By "drop this > patch", may be you meant to say "not use this config option" ? > >> For point2 above, we don't have much alternatives other than reducing >> kernel binary size by disabling unwanted drivers. > > And not using a boot loader. Sean got U-boot working with Kendryte, so it is not > that we cannot make it work. It is only that it may be less optimal due to the > memory used by the boot loader itself. Unless we can recover it if the kernel > relocate itself over it ? Surely doable, but it does sound to me like an > overkill for this particular use case, i.e. a tiny, hyper-embedded board where > running Linux is probably not the best choice in the first place, at least when > looking at real applications. The story is different for "hobbyist" level. My > on-going 6 DoF robotic arm project controlled with Linux on K210 is a valid use > case after all :) At the moment there is not too much reason to use a bootloader outside of helping debugging/experimenting. I would like to get support to where one can boot off the MMC slot, or perhaps over the network via the ESP32 chip on some boards. This is something that the built-in firmware cannot do. >>> >>> For the hardware ID, could we do something like: >>> >>> * Check for the top-level DT compatible string, on systems where we have a >>> provided DTB. >>> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with some >>> sort of >>> masking functionality if we later need one. These are availiable via SBI >>> calls, but I'd be inclined to restrict them to M-mode boot and just say the >>> SBI must provide a device tree with at least a suitable compatible string. >>> >>> While I suppose we could put together a tool for generating these tables, for >>> now we could probably just stick the mappings in a table for now given that >>> there's only one of them. >>> >>> That said, I'm not sure what to do about the different Kendryte boards -- is >>> there any way to poke the hardware to see which is which? >> >> I am sure there are two three different boards out there. Don't know exact >> differences between these boards. > > As far as I can tell, all the boards use the exact same SoC. No differences that > I can detect nor aware of. What differs between the different flavors of boards > are the perypherals attached: some have WiFi, different LCDs and different > cameras. The device tree is able to describe that of course, but the core dtsi > part for the SoC itself seem to be OK at least for the 4 different boards I have > (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan Dock). Yeah, as far as I can tell the only difference is in peripherals. Perhaps there are some differences in the firmware? There are some hardware descriptions at 0x88001C00 and up, but they only describe the SoC. We could try and compare dumps of the firmware. I currently have a Maix BitM and a Maixduino. --Sean
On 3/5/20 3:18 AM, Atish Patra wrote: > On Wed, Mar 4, 2020 at 9:14 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote: >> >> On 2020/03/05 13:58, Anup Patel wrote: >>> >>> >>>> -----Original Message----- >>>> From: Palmer Dabbelt <palmer@dabbelt.com> >>>> Sent: 05 March 2020 00:59 >>>> To: Damien Le Moal <Damien.LeMoal@wdc.com> >>>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley >>>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> >>>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support >>>> >>>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: >>>>> Enable a kernel builtin dtb for boards not capable of providing a >>>>> device tree to the kernel. >>>> >>>> I'd prefer if we picked a mechanism that allows a single kernel binary to be >>>> run on multiple systems. I think there's two use cases here: >>> >>> I strongly support "single kernel binary for multiple systems" but it's for >>> different purpose here. >>> >>>> >>>> * Bootloaders that provide no DTB at all. >>>> * Bootloaders that provied a DTB that, for some reason, isn't usable. >> >> Sure, but as Anup mentions below, the current use case it to not even use any >> bootloader at all for the K210 since that brings no value at all (in my >> opinion). More on this below. >> >>>> >>>> Given those constraints, could we do something similar to the early fixups? >>>> I'm thinking we could build a mapping between a hardware identifier and a >>>> DTB, then look up the DTB we want to use. Users that want a kernel that >>>> only runs on a single device can do so by configuring only a single DTB, users >>>> that want a more portable kernel can select a bunch -- that's essentially the >>>> same as how we're treating everything else (for example, the >>>> CONFIG_SOC_* stuff). >>> >>> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel >>> boots directly. The BUILTIN_DTB is only applicable to cases where there is >>> no bootloader before kernel. >>> >>> The Linux RISC-V NOMMU will tend be used in cases where: >>> 1. There is no bootloader and kernel boots directly hence we need >>> builtin DTB feature. >>> 2. There is very less RAM so we will have to build kernel specific to >>> a particular platform with bare minimum drivers. Due to this, we will >>> have separate defconfig for NOMMU platforms. >>> >>> I think point1 can be tackled if we enforce having bootloader (such as U-Boot) >>> for NOMMU systems and drop this patch. >> >> But that would go against point 2 as that will use more memory... By "drop this >> patch", may be you meant to say "not use this config option" ? >> >>> For point2 above, we don't have much alternatives other than reducing >>> kernel binary size by disabling unwanted drivers. >> >> And not using a boot loader. Sean got U-boot working with Kendryte, so it is not >> that we cannot make it work. It is only that it may be less optimal due to the >> memory used by the boot loader itself. Unless we can recover it if the kernel >> relocate itself over it ? Surely doable, but it does sound to me like an >> overkill for this particular use case, i.e. a tiny, hyper-embedded board where >> running Linux is probably not the best choice in the first place, at least when >> looking at real applications. The story is different for "hobbyist" level. My >> on-going 6 DoF robotic arm project controlled with Linux on K210 is a valid use >> case after all :) >> > > Just a thought: How about keeping the loader out of kernel as a > separate project as a tinyloader ? > That tinyloader project can host the DTB and pass it to kernel in a1 > register. This tinyloader can be used for > any M-mode only platforms with memory constraints. If platform has > sufficient memory and supports U-boot, users can use that as well. > That will allow single kernel image to boot all the platforms and we > can mandate one booting protocol for all platforms. > Otherwise, we have to specify different booting protocol for > M-Mode/NoMMU linux and S-mode Linux. > In future, there may be more platforms with Builtin DTB request as well. Couldn't this sort of thing be done by SBI? OpenSBI currently has a port for the K210. The only issue with SBI in general is that there is no way to set the VM mode, since it is stored in mstatus and not satp on older priv spec versions. There used to be a proposal related to this, but they chose to change the location of the VM mode rather than have SBI or some other bootloader set it. I think one of the ideas was for SBI to set the mode based off the mmu-type property. --Sean
On Fri, 2020-03-06 at 19:02 -0500, Sean Anderson wrote: > On 3/5/20 3:18 AM, Atish Patra wrote: > > On Wed, Mar 4, 2020 at 9:14 PM Damien Le Moal < > > Damien.LeMoal@wdc.com> wrote: > > > On 2020/03/05 13:58, Anup Patel wrote: > > > > > > > > > -----Original Message----- > > > > > From: Palmer Dabbelt <palmer@dabbelt.com> > > > > > Sent: 05 March 2020 00:59 > > > > > To: Damien Le Moal <Damien.LeMoal@wdc.com> > > > > > Cc: linux-riscv@lists.infradead.org; Paul Walmsley > > > > > <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> > > > > > Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support > > > > > > > > > > On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal > > > > > wrote: > > > > > > Enable a kernel builtin dtb for boards not capable of > > > > > > providing a > > > > > > device tree to the kernel. > > > > > > > > > > I'd prefer if we picked a mechanism that allows a single > > > > > kernel binary to be > > > > > run on multiple systems. I think there's two use cases here: > > > > > > > > I strongly support "single kernel binary for multiple systems" > > > > but it's for > > > > different purpose here. > > > > > > > > > * Bootloaders that provide no DTB at all. > > > > > * Bootloaders that provied a DTB that, for some reason, isn't > > > > > usable. > > > > > > Sure, but as Anup mentions below, the current use case it to not > > > even use any > > > bootloader at all for the K210 since that brings no value at all > > > (in my > > > opinion). More on this below. > > > > > > > > Given those constraints, could we do something similar to the > > > > > early fixups? > > > > > I'm thinking we could build a mapping between a hardware > > > > > identifier and a > > > > > DTB, then look up the DTB we want to use. Users that want a > > > > > kernel that > > > > > only runs on a single device can do so by configuring only a > > > > > single DTB, users > > > > > that want a more portable kernel can select a bunch -- that's > > > > > essentially the > > > > > same as how we're treating everything else (for example, the > > > > > CONFIG_SOC_* stuff). > > > > > > > > There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU > > > > kernel > > > > boots directly. The BUILTIN_DTB is only applicable to cases > > > > where there is > > > > no bootloader before kernel. > > > > > > > > The Linux RISC-V NOMMU will tend be used in cases where: > > > > 1. There is no bootloader and kernel boots directly hence we > > > > need > > > > builtin DTB feature. > > > > 2. There is very less RAM so we will have to build kernel > > > > specific to > > > > a particular platform with bare minimum drivers. Due to this, > > > > we will > > > > have separate defconfig for NOMMU platforms. > > > > > > > > I think point1 can be tackled if we enforce having bootloader > > > > (such as U-Boot) > > > > for NOMMU systems and drop this patch. > > > > > > But that would go against point 2 as that will use more memory... > > > By "drop this > > > patch", may be you meant to say "not use this config option" ? > > > > > > > For point2 above, we don't have much alternatives other than > > > > reducing > > > > kernel binary size by disabling unwanted drivers. > > > > > > And not using a boot loader. Sean got U-boot working with > > > Kendryte, so it is not > > > that we cannot make it work. It is only that it may be less > > > optimal due to the > > > memory used by the boot loader itself. Unless we can recover it > > > if the kernel > > > relocate itself over it ? Surely doable, but it does sound to me > > > like an > > > overkill for this particular use case, i.e. a tiny, hyper- > > > embedded board where > > > running Linux is probably not the best choice in the first place, > > > at least when > > > looking at real applications. The story is different for > > > "hobbyist" level. My > > > on-going 6 DoF robotic arm project controlled with Linux on K210 > > > is a valid use > > > case after all :) > > > > > > > Just a thought: How about keeping the loader out of kernel as a > > separate project as a tinyloader ? > > That tinyloader project can host the DTB and pass it to kernel in > > a1 > > register. This tinyloader can be used for > > any M-mode only platforms with memory constraints. If platform has > > sufficient memory and supports U-boot, users can use that as well. > > That will allow single kernel image to boot all the platforms and > > we > > can mandate one booting protocol for all platforms. > > Otherwise, we have to specify different booting protocol for > > M-Mode/NoMMU linux and S-mode Linux. > > In future, there may be more platforms with Builtin DTB request as > > well. > > Couldn't this sort of thing be done by SBI? OpenSBI currently has a > port > for the K210. The only issue with SBI in general is that there is no > way > to set the VM mode, since it is stored in mstatus and not satp on > older > priv spec versions. There used to be a proposal related to this, but > they chose to change the location of the VM mode rather than have SBI > or > some other bootloader set it. I think one of the ideas was for SBI to > set the mode based off the mmu-type property. > Just to avoid confusion: SBI is the specification and OpenSBI is the implementation. I think you meant OpenSBI here. It is possible but the question is whether it should be done by OpenSBI. Because OpenSBI is supposed to provide the SBI implementation. As NOMMU Linux doesn't need any of the SBI, I think it would be unnecessary to keep the OpenSBI code resident after Linux boots. I think U-Boot or a separate loader is an ideal solution but I see your U-Boot patches mention that loading an Image still is an issue. However, everybody needs to agree that booting single Linux kernel image on all boards(at least supported in upstream Linux) can be documented as a hard requirement before we discuss more on this topic. If that is possible, it is easier to enforce booting protocol (a0 - hartid, a1 - DTB and no builtin DTB) as well. I am not sure if that is the best approach but that's what we have currently. > --Sean >
> Just to avoid confusion: SBI is the specification and OpenSBI is the > implementation. I think you meant OpenSBI here. It is possible but the > question is whether it should be done by OpenSBI. Because OpenSBI is > supposed to provide the SBI implementation. As NOMMU Linux doesn't need > any of the SBI, I think it would be unnecessary to keep the OpenSBI > code resident after Linux boots. I mean OpenSBI when I talk about it having support. I mean SBI when I talk about setting up the MMU. You're right that M-mode linux doesn't need it, though these are some issues we will need to deal with when looking at an S-mode port. > > I think U-Boot or a separate loader is an ideal solution but I see > your U-Boot patches mention that loading an Image still is an issue. Yeah, I suspect it's just a memory layout problem. Hopefully I can figure out how to get everything working. > However, everybody needs to agree that booting single Linux kernel > image on all boards(at least supported in upstream Linux) > can be documented as a hard requirement before we discuss more on this > topic. If that is possible, it is easier to enforce booting protocol > (a0 - hartid, a1 - DTB and no builtin DTB) as well. I am not sure if > that is the best approach but that's what we have currently. I think it is a good goal to have one kernel for all the K210 boards, and just have different device trees. --Sean
On Thu, Mar 5, 2020 at 11:43 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote: > > On 2020/03/05 14:37, Anup Patel wrote: > > > > > >> -----Original Message----- > >> From: Damien Le Moal > >> Sent: 05 March 2020 10:44 > >> To: Anup Patel <Anup.Patel@wdc.com>; Palmer Dabbelt > >> <palmer@dabbelt.com> > >> Cc: linux-riscv@lists.infradead.org; Paul Walmsley > >> <paul.walmsley@sifive.com> > >> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support > >> > >> On 2020/03/05 13:58, Anup Patel wrote: > >>> > >>> > >>>> -----Original Message----- > >>>> From: Palmer Dabbelt <palmer@dabbelt.com> > >>>> Sent: 05 March 2020 00:59 > >>>> To: Damien Le Moal <Damien.LeMoal@wdc.com> > >>>> Cc: linux-riscv@lists.infradead.org; Paul Walmsley > >>>> <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com> > >>>> Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support > >>>> > >>>> On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal wrote: > >>>>> Enable a kernel builtin dtb for boards not capable of providing a > >>>>> device tree to the kernel. > >>>> > >>>> I'd prefer if we picked a mechanism that allows a single kernel > >>>> binary to be run on multiple systems. I think there's two use cases here: > >>> > >>> I strongly support "single kernel binary for multiple systems" but > >>> it's for different purpose here. > >>> > >>>> > >>>> * Bootloaders that provide no DTB at all. > >>>> * Bootloaders that provied a DTB that, for some reason, isn't usable. > >> > >> Sure, but as Anup mentions below, the current use case it to not even use > >> any bootloader at all for the K210 since that brings no value at all (in my > >> opinion). More on this below. > >> > >>>> > >>>> Given those constraints, could we do something similar to the early > >> fixups? > >>>> I'm thinking we could build a mapping between a hardware identifier > >>>> and a DTB, then look up the DTB we want to use. Users that want a > >>>> kernel that only runs on a single device can do so by configuring > >>>> only a single DTB, users that want a more portable kernel can select > >>>> a bunch -- that's essentially the same as how we're treating > >>>> everything else (for example, the > >>>> CONFIG_SOC_* stuff). > >>> > >>> There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU kernel > >>> boots directly. The BUILTIN_DTB is only applicable to cases where > >>> there is no bootloader before kernel. > >>> > >>> The Linux RISC-V NOMMU will tend be used in cases where: > >>> 1. There is no bootloader and kernel boots directly hence we need > >>> builtin DTB feature. > >>> 2. There is very less RAM so we will have to build kernel specific to > >>> a particular platform with bare minimum drivers. Due to this, we will > >>> have separate defconfig for NOMMU platforms. > >>> > >>> I think point1 can be tackled if we enforce having bootloader (such as > >>> U-Boot) for NOMMU systems and drop this patch. > >> > >> But that would go against point 2 as that will use more memory... By "drop > >> this patch", may be you meant to say "not use this config option" ? > > > > I meant to use U-Boot on Kendryte to launch kernel. > > > >> > >>> For point2 above, we don't have much alternatives other than reducing > >>> kernel binary size by disabling unwanted drivers. > >> > >> And not using a boot loader. Sean got U-boot working with Kendryte, so it is > >> not that we cannot make it work. It is only that it may be less optimal due to > >> the memory used by the boot loader itself. Unless we can recover it if the > >> kernel relocate itself over it ? Surely doable, but it does sound to me like an > >> overkill for this particular use case, i.e. a tiny, hyper-embedded board where > >> running Linux is probably not the best choice in the first place, at least when > >> looking at real applications. The story is different for "hobbyist" level. My on- > >> going 6 DoF robotic arm project controlled with Linux on K210 is a valid use > >> case after all :) > > > > Dropping BUILTIN DTB feature will be more like a Linux RISC-V policy thingy. > > My suggestion was more about discouraging Linux S-mode users to use the > > BUILTIN DTB feature. > > Got it. For now, we could tie BUILTIN DTB config to !MMU case only. If there is > a valid use case that pops up for regular MMU/S-mode Linux, it is easy to change. > > > I agree that it is difficult to fit a proper boot-flow (having proper bootloader) > > due to limited RAM. If we don't link DTB to Linux RISC-V NOMMU then some > > thing else need to provide it hence bootloader suggestion. > > OK. Understood and I agree. > > > > > Apart from the Linux RISC-V NOMMU use-case, the BUILTIN DTB feature can > > be useful in environments such as FPGAs/Palladium where proper bootloader > > is not available. > > OK. But we do not have to enable it for this right away, no ? So should I just > not allow BUILTIN DTB for MMU==true case for now ? Making kconfig option BUILTIN_DTB depends on !MMU looks reasonable to me. Maybe you can send v2 with this change ? Regards, Anup > > > > > Regards, > > Anup > > > >> > >>> > >>>> > >>>> For the hardware ID, could we do something like: > >>>> > >>>> * Check for the top-level DT compatible string, on systems where we > >> have a > >>>> provided DTB. > >>>> * Check for a matching mimpid/marchid/mvendorid tuple, maybe with > >>>> some sort of > >>>> masking functionality if we later need one. These are availiable via SBI > >>>> calls, but I'd be inclined to restrict them to M-mode boot and just say the > >>>> SBI must provide a device tree with at least a suitable compatible string. > >>>> > >>>> While I suppose we could put together a tool for generating these > >>>> tables, for now we could probably just stick the mappings in a table > >>>> for now given that there's only one of them. > >>>> > >>>> That said, I'm not sure what to do about the different Kendryte > >>>> boards -- is there any way to poke the hardware to see which is which? > >>> > >>> I am sure there are two three different boards out there. Don't know > >>> exact differences between these boards. > >> > >> As far as I can tell, all the boards use the exact same SoC. No differences that > >> I can detect nor aware of. What differs between the different flavors of > >> boards are the perypherals attached: some have WiFi, different LCDs and > >> different cameras. The device tree is able to describe that of course, but the > >> core dtsi part for the SoC itself seem to be OK at least for the 4 different > >> boards I have (Kendryte KD233, Sipeed MAIXDUINO, MAIX Go and Dan > >> Dock). > >> > >>> > >>> Regards, > >>> Anup > >>> > >>>> > >>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> > >>>>> --- > >>>>> arch/riscv/Kbuild | 1 + > >>>>> arch/riscv/Kconfig | 18 ++++++++++++++++++ > >>>>> arch/riscv/boot/dts/Makefile | 4 ++++ > >>>>> arch/riscv/kernel/setup.c | 6 ++++++ > >>>>> arch/riscv/mm/init.c | 4 ++++ > >>>>> 5 files changed, 33 insertions(+) > >>>>> > >>>>> diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index > >>>>> d1d0aa70fdf1..988804e430e4 100644 > >>>>> --- a/arch/riscv/Kbuild > >>>>> +++ b/arch/riscv/Kbuild > >>>>> @@ -1,3 +1,4 @@ > >>>>> # SPDX-License-Identifier: GPL-2.0-only > >>>>> > >>>>> obj-y += kernel/ mm/ net/ > >>>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ > >>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > >>>>> 1a3b5a5276be..28899e15f548 100644 > >>>>> --- a/arch/riscv/Kconfig > >>>>> +++ b/arch/riscv/Kconfig > >>>>> @@ -355,6 +355,24 @@ config CMDLINE_FORCE > >>>>> > >>>>> endchoice > >>>>> > >>>>> +config USE_BUILTIN_DTB > >>>>> + bool "Use builtin DTB" > >>>>> + help > >>>>> + Link a device tree blob for particular hardware into the kernel, > >>>>> + suppressing use of the DTB pointer provided by the bootloader. > >>>>> + This option should only be used with hardware or bootloaders that > >>>>> + are not capable of providing a DTB to the kernel, or for > >>>>> + experimental hardware without stable device tree bindings. > >>>>> + > >>>>> +config BUILTIN_DTB_SOURCE > >>>>> + string "Source file for builtin DTB" > >>>>> + default "" > >>>>> + depends on USE_BUILTIN_DTB > >>>>> + help > >>>>> + Base name (without suffix, relative to arch/riscv/boot/dts) for > >>>>> + the a DTS file that will be used to produce the DTB linked into > >>>>> + the kernel. > >>>>> + > >>>>> endmenu > >>>>> > >>>>> menu "Power management options" > >>>>> diff --git a/arch/riscv/boot/dts/Makefile > >>>>> b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d > >>>>> 100644 > >>>>> --- a/arch/riscv/boot/dts/Makefile > >>>>> +++ b/arch/riscv/boot/dts/Makefile > >>>>> @@ -1,2 +1,6 @@ > >>>>> # SPDX-License-Identifier: GPL-2.0 > >>>>> +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") > >>>>> +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst > >>>>> +"%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o > >>>>> +else > >>>>> subdir-y += sifive > >>>>> +endif > >>>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > >>>>> index 0a6d415b0a5a..3e89be9d888c 100644 > >>>>> --- a/arch/riscv/kernel/setup.c > >>>>> +++ b/arch/riscv/kernel/setup.c > >>>>> @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) > >>>>> > >>>>> setup_bootmem(); > >>>>> paging_init(); > >>>>> + > >>>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > >>>>> + unflatten_and_copy_device_tree(); > >>>>> +#else > >>>>> unflatten_device_tree(); > >>>>> +#endif > >>>>> + > >>>>> clint_init_boot_cpu(); > >>>>> > >>>>> #ifdef CONFIG_SWIOTLB > >>>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index > >>>>> 965a8cf4829c..1274e889d008 100644 > >>>>> --- a/arch/riscv/mm/init.c > >>>>> +++ b/arch/riscv/mm/init.c > >>>>> @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else > >>>>> asmlinkage void __init setup_vm(uintptr_t dtb_pa) { > >>>>> +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) > >>>>> + dtb_early_va = __dtb_start; > >>>>> +#else > >>>>> dtb_early_va = (void *)dtb_pa; > >>>>> +#endif > >>>>> } > >>>>> > >>>>> static inline void setup_vm_final(void) > >>> > >> > >> > >> -- > >> Damien Le Moal > >> Western Digital Research > > > > > -- > Damien Le Moal > Western Digital Research >
diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild index d1d0aa70fdf1..988804e430e4 100644 --- a/arch/riscv/Kbuild +++ b/arch/riscv/Kbuild @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0-only obj-y += kernel/ mm/ net/ +obj-$(CONFIG_USE_BUILTIN_DTB) += boot/dts/ diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 1a3b5a5276be..28899e15f548 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -355,6 +355,24 @@ config CMDLINE_FORCE endchoice +config USE_BUILTIN_DTB + bool "Use builtin DTB" + help + Link a device tree blob for particular hardware into the kernel, + suppressing use of the DTB pointer provided by the bootloader. + This option should only be used with hardware or bootloaders that + are not capable of providing a DTB to the kernel, or for + experimental hardware without stable device tree bindings. + +config BUILTIN_DTB_SOURCE + string "Source file for builtin DTB" + default "" + depends on USE_BUILTIN_DTB + help + Base name (without suffix, relative to arch/riscv/boot/dts) for + the a DTS file that will be used to produce the DTB linked into + the kernel. + endmenu menu "Power management options" diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile index dcc3ada78455..0bf2669aa12d 100644 --- a/arch/riscv/boot/dts/Makefile +++ b/arch/riscv/boot/dts/Makefile @@ -1,2 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 +ifneq ($(CONFIG_BUILTIN_DTB_SOURCE),"") +obj-$(CONFIG_USE_BUILTIN_DTB) += $(patsubst "%",%,$(CONFIG_BUILTIN_DTB_SOURCE)).dtb.o +else subdir-y += sifive +endif diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c index 0a6d415b0a5a..3e89be9d888c 100644 --- a/arch/riscv/kernel/setup.c +++ b/arch/riscv/kernel/setup.c @@ -68,7 +68,13 @@ void __init setup_arch(char **cmdline_p) setup_bootmem(); paging_init(); + +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) + unflatten_and_copy_device_tree(); +#else unflatten_device_tree(); +#endif + clint_init_boot_cpu(); #ifdef CONFIG_SWIOTLB diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 965a8cf4829c..1274e889d008 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -480,7 +480,11 @@ static void __init setup_vm_final(void) #else asmlinkage void __init setup_vm(uintptr_t dtb_pa) { +#if IS_ENABLED(CONFIG_USE_BUILTIN_DTB) + dtb_early_va = __dtb_start; +#else dtb_early_va = (void *)dtb_pa; +#endif } static inline void setup_vm_final(void)
Enable a kernel builtin dtb for boards not capable of providing a device tree to the kernel. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> --- arch/riscv/Kbuild | 1 + arch/riscv/Kconfig | 18 ++++++++++++++++++ arch/riscv/boot/dts/Makefile | 4 ++++ arch/riscv/kernel/setup.c | 6 ++++++ arch/riscv/mm/init.c | 4 ++++ 5 files changed, 33 insertions(+)