Messages in this thread | | | Date | Fri, 11 Jun 2021 21:10:45 -0700 (PDT) | Subject | Re: [PATCH -fixes] riscv: Fix BUILTIN_DTB for sifive and microchip soc | From | Palmer Dabbelt <> |
| |
On Sun, 06 Jun 2021 00:40:34 PDT (-0700), alex@ghiti.fr wrote: > Le 5/06/2021 à 13:00, Arnd Bergmann a écrit : >> On Sat, Jun 5, 2021 at 8:37 AM Alex Ghiti <alex@ghiti.fr> wrote: >>> Le 4/06/2021 à 15:08, Arnd Bergmann a écrit : >>>> On Fri, Jun 4, 2021 at 2:06 PM Alexandre Ghiti <alex@ghiti.fr> wrote: >>>>> >>>>> Fix BUILTIN_DTB config which resulted in a dtb that was actually not built >>>>> into the Linux image: in the same manner as Canaan soc does, create an object >>>>> file from the dtb file that will get linked into the Linux image. >>>>> >>>>> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr> >>>> >>>> Along the same lines as the comment that Jisheng Zhang made on the fixed >>>> address, building a dtb into the kernel itself fundamentally breaks generic >>>> kernel images. >>>> >>>> I can understand using it on K210, which is extremely limited and wouldn't >>>> run a generic kernel anyway, but for normal platforms like microchip and >>>> sifive, it would be better to disallow CONFIG_BUILTIN_DTB in Kconfig >>>> and require a non-broken boot loader. >>> >>> I kind of disagree because if I want to build a custom kernel for those >>> platforms with a builtin dtb for some reasons (debug, development..Etc), >>> I think I should be able to do so. >> >> How is the builtin dtb better than appended dtb, or passing the dtb to the >> boot loader in that case? > > Ah never said it was better, just it was available so there is no reason > we could not allow it :)
I agree: I'm not really a fan of BUILTIN_DTB (and I tried pretty hard not to have it in the first place), but whatever we have shouldn't be broken.
This is on fixes.
| |