On Sat, Apr 3, 2010 at 10:22 PM, David Gibson <[email protected]> wrote: > When debugging handoffs between different boot stages which use > flattened device trees to communicate, it's often useful to dump the > device tree blob being passed and use dtc to decompile it to something > readable. However, with some debugging tools it's possible to perform > a hex memory dump of the device tree, but it's awkward or impossible > to directly dump the memory as a binary blob. > > Obviously, it's quite straightforward to write a script or program to > convert the hex dump back to binary, but I'm not aware of a standard > tool to do so. > > This patch, therefore, adds a "hex" input format to dtc which allows > it to directly (or almost so) parse and decompile a device tree blob > supplied as a hex dump. The input dtc expects in this mode must have > no addresses or other extraneous text which could contain valid hex > digits, however it will silently ignore any whitespace, punctuation, > or other non-hex-digit formatting in the dump. The dump must also > either be either byte-by-byte, or display each hex number as > big-endian (so "od -t x1" will produce suitable output on any system, > but "od -t x2" will produce suitable output only when run on a > big-endian system). > > Thus, if addresses and any header/footer are removed (usually easy to > do in an editor), dtc will accept quite a wide range of likely hex > dump formats.
Does it really make sense to build marshaling tools into dtc itself? I think it would make more sense to keep transformation tools independent. ie. what if I have srecord format? or intel hex? A trivial python or perl script would do the job for raw hex. The ascii2binary tool should also work. Also, objcopy handles srecord/ihex conversion beautifully. I don't think it makes sense to be teaching dtc different representations of the same dtb format. g. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
