Received-SPF: pass (google.com: domain of linux-kernel+bounces-77347-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 22 Feb 2024 12:58:00 -0800 (PST)
Subject:     Re: [RFC PATCH 0/1] riscv: dts: Allow BUILTIN_DTB for all socs
In-Reply-To: <ac11967c-3ab4-42be-86ca-0d40c35eee04@ghiti.fr>
CC: cyy@cyyself.name, linux-riscv@lists.infradead.org,
  Paul Walmsley <paul.walmsley@sifive.com>, aou@eecs.berkeley.edu, Conor Dooley <conor@kernel.org>,
  linux-kernel@vger.kernel.org, masahiroy@kernel.org, robh+dt@kernel.org, devicetree@vger.kernel.org
From: Palmer Dabbelt <palmer@dabbelt.com>
To: alex@ghiti.fr
Message-ID: <mhng-a0b00545-1522-4045-a4fe-97c3fbb8b082@palmer-ri-x1c9a>
Precedence: bulk
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On Tue, 20 Feb 2024 12:46:57 PST (-0800), alex@ghiti.fr wrote:
> Hi Yangyu,
>
> On 20/02/2024 20:01, Yangyu Chen wrote:
>> The BUILTIN_DTB kernel feature on RISC-V only works on K210 SoC only. This
>> patch moved this configuration to entire riscv.
>>
>> Although BUILTIN_DTB is not a good choice for most platforms, it is likely
>> to be a debug feature when some bootloader will always override something
>> like the memory node in the device tree to adjust the memory size from SPD
>> or configuration resistor, which makes it hard to do some debugging. As an
>> example, some platforms with numa like sg2042 only support sv39 will fail
>> to boot when there is no ZONE_HIGHMEM patch with 128G memory. If we want

I guess that's a surprising one, but there's always some Kconfig entries 
that are necessary to set in order to get platforms to boot -- at a bare 
minimum errata and drivers, for example.

> Orthogonal to this patch, but if needs be, we can fix this issue with
> 128G on sv39 by changing the sv39 address space layout, we still have
> room to gain the 4G you miss, at that time I was pretty sure that amount
> of memory would come with sv48 :)

That seems like a reasonable way to go, as long as it's not overly 
complex.

>
> Thanks,
>
> Alex
>
>
>> a kernel without this patch to boot, we need to write the memory nodes
>> in the DT manually.
>>
>> Also, changing DT on some platforms is not easy. For Milk-V Pioneer, the
>> boot procedure is ZSBL -> OpenSBI -> LinuxBoot -> Linux. If DT gets
>> changed, OpenSBI or LinuxBoot may refuse to boot. And there is some bug on
>> LinuxBoot now which does not consume --dtb argument on kexec and always
>> uses DT from memory. So I would like to do debugging on DT using

I'd argue those are bootloader/firmware bugs.

>> BUILTIN_DTB, which makes it very simple, I can even install the kernel in
>> the distro's way and provide a kernel package for other users to test.
>>
>> Yangyu Chen (1):
>>    riscv: dts: Allow BUILTIN_DTB for all socs
>>
>>   arch/riscv/Kconfig                  | 16 ++++++++++++++-
>>   arch/riscv/Kconfig.socs             | 32 -----------------------------
>>   arch/riscv/boot/dts/Makefile        |  2 +-
>>   arch/riscv/boot/dts/canaan/Makefile |  2 --
>>   4 files changed, 16 insertions(+), 36 deletions(-)
>>