On Thu, Apr 11, 2013 at 06:44:20PM -0400, Mike Frysinger wrote: > On Thursday 11 April 2013 00:11:30 David Gibson wrote: > > On Wed, Apr 10, 2013 at 02:29:11PM -0400, Mike Frysinger wrote: > > > Often times, fdts get embedded in other larger files. Rather than force > > > people to `dd` the blob out themselves, make the fdtdump file smarter. > > > > > > It can now scan the blob looking for the fdt magic. Once locate, it does > > > a little validation on the main struct to make sure we didn't hit random > > > binary data. > > > > Hrm. I have mixed feelings about this. The scanning functionality is > > certainly useful. But on the other hand, fdtdump is not supposed to > > be a general use tool. It's basically a debugging aid: a quick and > > dirty independent implementation of a dtb dump, for checking that dtc > > is producing sane output. The preferred way to dump dtbs "for real" > > is to use dtc -I dtb -O dts > > > > I think the way I'd prefer to see this functionality would be to add a > > new input format to dtc which is a little wrapper around the dtb input > > format which does the scan. > > that seems reasonable, but really my use case was: scan a big blob, find the > dtb embedded in there, then both decode and dump the offsets. this was so i > could easily hack said big blob with a hexeditor and tweak a few > keys.
Yeah, so when I got to your debug patch, I already started changing my
mind here.
> adding a new input format would satisfy the first part (locating the dtb),
> and
> the fact that dtc already supports "-O dtb" is good as it'd allow me to run
> it
> through fdtdump after the fact. i can probably even chain them in a pipeline.
>
> i'd still want the --debug option in fdtdump, but it sounds like that
> wouldn't
> be against your desired goal for this utility ?
>
> if that sounds good to you, i can rework things so that dtc gets a new "scan"
> input format (guessing i don't need to name it "scan-dtb"). then we both
> should be happy.
Actually, you've convinced me. So for now, just go back to your
original approach and address the other more specific comments and
that should be fine. When I made that suggestion I hadn't realised
what you were using this for. Now that I have, I think it fits into
fdtdump as intended.
> on a related note, is there a reason these tools malloc & read in the whole
> file into memory instead of just doing mmap() when possible ?
Some combination of simplicity and portability. I've never really
thought about it much..
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
_______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
