[PATCH 06/10] fdtdump: add a --scan option

[Mike Frysinger]

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.

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.

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 ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130411/6129177c/attachment.sig>