linux-kernel - Re: [PATCH -fixes] riscv: Fix BUILTIN_DTB for sifive and microchip soc

Open Source and information security mailing list archives

Message-ID: <5d3a00d1-9e45-398a-39cf-1e6e9924eb18@ghiti.fr>
Date:   Sun, 6 Jun 2021 09:40:34 +0200
From:   Alex Ghiti <alex@...ti.fr>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        DTML <devicetree@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -fixes] riscv: Fix BUILTIN_DTB for sifive and microchip
 soc

Le 5/06/2021 à 13:00, Arnd Bergmann a écrit :
> On Sat, Jun 5, 2021 at 8:37 AM Alex Ghiti <alex@...ti.fr> wrote:
>> Le 4/06/2021 à 15:08, Arnd Bergmann a écrit :
>>> On Fri, Jun 4, 2021 at 2:06 PM Alexandre Ghiti <alex@...ti.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@...ti.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 :)

> 
>           Arnd
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives