Allow dtc to decompile device tre blobs in hexdump format

[Grant Likely]

On Sun, Apr 4, 2010 at 3:11 PM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> On Sun, Apr 04, 2010 at 12:30:15AM -0600, Grant Likely wrote:
>> On Sat, Apr 3, 2010 at 10:22 PM, David Gibson
>> <david at gibson.dropbear.id.au> 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.
[...]
>>
>> Does it really make sense to build marshaling tools into dtc itself?
>
> Well.. is it essential that dtc do this?  Clearly not.  Is it a
> sufficient convenience that it's worth it?  Maybe.
>
>> I think it would make more sense to keep transformation tools
>> independent.  ie. what if I have srecord format?  or intel hex?
>
> If they're a) sufficiently widely used, b) not to hard to implement
> and c) there aren't widely used existing conversion tools then I would
> have no problem with adding support for such formats to.
>
>> A
>> trivial python or perl script would do the job for raw hex.
>
> I've written that trivial python or perl script too darn many times,
> and I'm sick of it.  I can't be the only one.

Oh, I agree.  I don't like reimplementing tools over and over again
either.  What I'm saying is rather than increasing the complexity of
the core dtc codebase, make it a separate script and store it inside
the dtc repo so it is available to all who need it.

>>  The
>> ascii2binary tool should also work.  Also, objcopy handles
>> srecord/ihex conversion beautifully.
>
> Ah, I wasn't previously aware of ascii2binary.  If it's flexible
> enough, that might well undermine the justification for this patch.

:-)

g.