linux-kernel - Re: [RFC PATCH 0/1] riscv: dts: Allow BUILTIN

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240221-islamic-quartered-3863e44bc862@spud>
Date: Wed, 21 Feb 2024 11:30:57 +0000
From: Conor Dooley <conor@...nel.org>
To: Yangyu Chen <cyy@...self.name>
Cc: linux-riscv@...ts.infradead.org,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, linux-kernel@...r.kernel.org,
	Masahiro Yamada <masahiroy@...nel.org>,
	Alexandre Ghiti <alex@...ti.fr>, Rob Herring <robh+dt@...nel.org>,
	devicetree@...r.kernel.org
Subject: Re: [RFC PATCH 0/1] riscv: dts: Allow BUILTIN_DTB for all socs

Hey,

On Wed, Feb 21, 2024 at 03:01:53AM +0800, 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.

To be honest, I would rather delete BUILTIN_DTB (and the configurations
that depend on it) than expand its usefulness.

> 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.

My inclination here is to say "fix your bootloader" and if that's not
possible, chainload a bootloader that allows you control over
modifications to your devicetree.

> 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
> a kernel without this patch to boot, we need to write the memory nodes 
> in the DT manually.

If, as Alex suggests, there's a way to gain support some more memory in
sv39, we should do so - but it is worth mentioning that highmem is on the
removal list for the kernel, so mainline support for that is highly
unlikely.

> 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.

I don't use Linuxboot, but let me try to understand. Linuxboot uses kexec
to boot the main Linux kernel, but the dtb you want to use is not used, and
instead the one that Linuxboot itself was booted with is used?

It sounds like Linuxboot has a --dtb argumet that is meant to be used to
set the dtb for the next stage, but that argument is being ignored?

That sounds like a pretty serious issue with Linuxboot which should be
fixed - what am I missing?

> So I would like to do debugging on DT using
> 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.

I'm not sure what you mean by this, other distros manage to create
kernel packages without using builtin dtbs.

Thanks,
Conor.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)