On Wed, Oct 18, 2017 at 7:59 AM, Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi Grant, > >> On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: >> >> On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@xxxxxxxx> 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@xxxxxxxxxx> 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. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
