> -----Original Message-----
> From: Rob on Wednesday, October 18, 2017 7:14 AM
> On Wed, Oct 18, 2017 at 7:59 AM, Pantelis Antoniou
> <panto@antoniou-consulting.com> wrote:
> > Hi Grant,
> >
> >> On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> wrote:
> >>
> >> On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com>
> wrote:
> >>>> -----Original Message-----
> >>>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM
> >>>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org>
> wrote:
> >>>>> I think this also gets to having bindings described in a structured way
> so
> >>>> they can be utilized for validation of dts files.  We are doing a little of
> this in
> >>>> Zephyr since we are using a structured binding spec to generate code
> from
> >>>> .dts (since we don’t utilize a runtime dtb).
> >>>>
> >>>> So you are basically generating board files from .dts?
> >>>> (closing the loop ;-)
> 
> Briefly, what Zephyr is doing is controlling configuration (what
> drivers are built) and generating register base addresses and maybe
> interrupts. That's not really board.dts -> board.c.
> 
> >>>
> >>> I think we ought to do this on Linux, as a size optimization.
> >>> -- Tim
> >>>
> >>> P.S.  I think I'll leave it ambiguous whether this was meant as a joke or
> not. :-)
> >>
> >
> > As crazy that sounds it is possible using the YAML bindings, i.e. C structure
> definitions
> > and fill-up from DT automatically. Whether this is a good idea it’s another
> question :)
> 
> Yeah, yeah. YAML solves *all* the problems.
> 
> >> Talk to Nicolas Pitre and Rob Herring about this. They've already made
> >> a bunch of progress on reducing memory footprint.
> 
> Or just look at linux-next. :) The focus is purely on runtime RAM
> usage with all code being XIP. Basically, I've reduced the size of the
> unflattened tree by skipping unflattening of disabled nodes and
> shrinking the unflattened tree structs. For example removing the
> kobject for !SYSFS. This reduced RAM usage from 120K to 11K on an
> stm32 board. The next thing in the heat map of RAM usage is struct
> device size. There's some things like DMA related elements that could
> be moved to separate structures, but that will be quite invasive.
> 
> Another idea is to run the kernel unflattening code on the tree at
> build time and embed that as const data into the kernel. The
> unflattening code is pretty self contained and XIP images are platform
> specific anyway. It would also allow running all dtb files thru
> unflattening at build time for some validation. Though I'm not sure
> there's anything unflattening would fail on that dtc can't check.

I should have read all the way to the end of the thread before responding.
It looks like people are already looking at what I've been thinking about for a while.
Sorry I missed Nicolas' talk at LC.  I'll go take a look at the video.
 -- Tim