[U-Boot-Users] [RESEND DTC PATCH 2/2] Add support for binary includes.
david at gibson.dropbear.id.au
Mon Dec 24 01:16:23 CET 2007
On Sat, Dec 22, 2007 at 07:57:17AM -0600, Scott Wood wrote:
> On Sat, Dec 22, 2007 at 01:51:30PM +1100, David Gibson wrote:
> > On Fri, Dec 21, 2007 at 11:09:21AM -0600, Scott Wood wrote:
> > > OK. I was being lazy. :-P
> > In general I'd approve, but having to invoke dtc in the right place
> > for the dts file is a bit too big a usability problem, I think.
> Yeah, I agree. It looks like the existing /include/ has the same
> problem, BTW.
Uh, yes, I guess it would. I suppose we'd better fix that too. We'll
see how bored I get at my parents' place over Christmas.
> > > Yeah, I wanted something that would cause dtc to return an error code,
> > > and it doesn't seem that calling yyerror(f) will do that at present. I
> > > guess I should fix that rather than overload YYERROR.
> > No. As per the yacc interface, yyerror() prints only, it doesn't
> > terminate.
> I don't mean terminate early, just set a flag indicating there were
> errors, so it returns an error code once parsing is done.
Ok. We don't have a really good mechanism for that at present - for
any of the input forms. I was thinking about trying to hook that into
the checking framework - have a special sort of check that doesn't do
anything when invoked as a check, but can be "pre-failed" by the input
> > > > I'm also not sure that stat()ing the file is a good way to get the
> > > > size. This requires that the included file be a regular file with a
> > > > sane st_size value, and I can imagine cases where it might be useful
> > > > to incbin from a /dev node or other special file. Obviosuly
> > > > implementing that will require work to data_copy_file().
> > >
> > > Hmm... do you have a use case in mind?
> > Nothing really specific. I'm thinking of a dts that maybe pulls in
> > some blobs from a pre-existing firmware, by sucking in files from
> > /proc/device-tree.
> 'ls -l /proc/device-tree' seems to indicate that stat would work fine
> there (and fstree.c uses it).
Uh, yeah. That's just me being an old-timer and remembering the days
when stat() didn't operate on /proc properly.
> > Or maybe something to produce a dts for a guest under a hypervisor that
> > takes an image of a real NVRAM or other device to embed in the tree as
> > a virtual NVRAM for the guest.
> > > > Actually, I think the way to go here would be to have two variants of
> > > > the incbin directive: one which takes just a filename and includes
> > > > the whole file contents, another which takes a filename and a number
> > > > and includes just the first N bytes of the file.
> > >
> > > Maybe. /incbinrange/ "path/name" start len?
> > I'd prefer to avoid two different keywords if possible. I'll see if I
> > can think of a reasonable syntax.
> /incbin/("path", start, len)
Hrm. Not all that fond of those, but we'll see. I guess
C-function-like syntax does make a certain amount of sense in the
context of the expression syntax we intend to introduce.
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_!
More information about the U-Boot