linux-kernel - Re: [RFC/PATCH] drivers/of: add debug for early dump of the dtb strcutrue

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: <20250818141733.GA979958-robh@kernel.org>
Date: Mon, 18 Aug 2025 09:17:33 -0500
From: Rob Herring <robh@...nel.org>
To: Ben Dooks <ben.dooks@...ethink.co.uk>
Cc: Saravana Kannan <saravanak@...gle.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH] drivers/of: add debug for early dump of the dtb
 strcutrue

On Mon, Aug 11, 2025 at 09:02:34AM +0100, Ben Dooks wrote:
> On 08/08/2025 22:10, Saravana Kannan wrote:
> > On Fri, Aug 8, 2025 at 9:25 AM Rob Herring <robh@...nel.org> wrote:
> > > 
> > > On Fri, Aug 8, 2025 at 9:26 AM Ben Dooks <ben.dooks@...ethink.co.uk> wrote:
> > > > 
> > > > When testing for boot issues, it was helpful to dump the
> > > > list of nodes and properties in the device-tree passed into
> > > > the kernel.
> > > 
> > > Shouldn't the bootloader be able to dump that?
> > > 
> > > > Add CONFIG_OF_EARLY_DUMP option to dump the list of nodes
> > > > and properties to the standard console output early in the
> > > > boot sequence. Note, you may need to have some sort of
> > > 
> > > s/may/will/
> > > 
> > > > early or debug console output if there are issues stopping
> > > > the kernel starting properly.
> > > 
> > > Seems to me this is giving the user the haystack to find the needle...
> > 
> > Completely agree with Rob.
> > 
> > Ben, can you give more context on what kind of issues this has helped
> > you (or anticipate it will) solve? Maybe there are better ways of
> > getting what you need.
> 
> We where having issues with u-boot on big-endian riscv.
> 
> turns out the string functions had issues with endian-ness and
> where corrupting the dtb when doing the final changes when booting
> into the kernel.
> 
> the kernel wouldn;t boot as sometimes depending on data alignment
> the #size-cells and #address-cells where having their names corrupted
> and thus the kernel would bail very early.

Whether the DT is un-corrupted enough to boot enough to print a message 
is completely by chance there. If the bootloader modifications need 
testing/checking, then that's the bootloader's problem to provide a 
mechanism to do so.

Rob