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

[Rob Herring]

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@xxxxxxxxxx> wrote:
> > > 
> > > On Fri, Aug 8, 2025 at 9:26 AM Ben Dooks <ben.dooks@xxxxxxxxxxxxxxx> 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