On Wed, Jun 14, 2017 at 11:06:39PM +0800, David Gibson wrote:
> On Wed, Jun 14, 2017 at 05:53:49PM +0300, Pantelis Antoniou wrote:
> > Dumping files with large properties results in output with
> > arbitrary long lines.
> >
> > Original (manual line breaks inserted; it's a single long line):
> >
> > / {
> > int = <0x00000001 0x00000024 0x00000004 0x00000000 \
> > 0x000502a4 0x000000df 0x00000003 0x13885783 0x13885783 \
> > 0x00000002 0x62797465 0x00000000 0x00000000 0x00000000 \
> > 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 \
> > 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000>;
> > };
> >
> > After prettification:
> >
> > / {
> > int = <0x00000001 0x00000002 0x00000008 0x00000010 0x00000024 0x000000ab>,
> > <0x00000001 0x00000017 0x00000004 0x00000038 0x00000007 0x00000009>,
> > <0x00000000 0x00000068 0x00000214 0x0000b8d9 0x000502a4 0x00000001>,
> > <0x00000004 0x0000002b 0x000000df 0x00000003 0x00000002 0x00000001>;
> > };
> >
> > There are two new options (-w/--width) and (-S/--shift).
> >
> > Width is the terminal width, shift is the amount of spaces each nest level
> > increases by.
> >
> > Width by default is set to 80, and shift to 4.
>
> Nack.
>
> fdtdump is supposed to be a trivial debug tool. If you want to
> decompile dtbs "for real" use dtc -I dtb -O dts.
There's been times, entirely unrelated to what Pantelis is doing, where
I've used fdtdump in production cases because I needed to whack a few
things around. If it's just supposed to be a trivial debug tool, we've
likely moved well beyond the point where we need to keep trivial tools
around if they shouldn't be more widely used, IMHO.
Swinging back around to what Pantelis is talking about, it would be kind
of annoying, but we could probably integrate dtc into U-Boot like the
kernel has. Is that where we're at then? Thanks!
--
Tom
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
