On Mon, Aug 11, 2025 at 09:02:34AM +0100, Ben Dooks wrote:

On 08/08/2025 22:10, Saravana Kannan wrote:

quoted

On Fri, Aug 8, 2025 at 9:25 AM Rob Herring [off-list ref] wrote:

quoted

On Fri, Aug 8, 2025 at 9:26 AM Ben Dooks [off-list ref] wrote:

quoted

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?

quoted

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/

quoted

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