On Sun, Apr 4, 2010 at 3:11 PM, David Gibson <[email protected]> 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 >> <[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. [...] >> >> 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. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
