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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <mhng-10244c1f-e77f-4b81-80ef-1b6d1a73c095@palmerdabbelt-glaptop>
Date:   Fri, 11 Jun 2021 21:10:45 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     alex@...ti.fr
CC:     Arnd Bergmann <arnd@...db.de>, robh+dt@...nel.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, devicetree@...r.kernel.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject:     Re: [PATCH -fixes] riscv: Fix BUILTIN_DTB for sifive and microchip soc

On Sun, 06 Jun 2021 00:40:34 PDT (-0700), alex@...ti.fr wrote:
> 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 :)

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ