Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017)

[Rob Herring <robh@kernel.org>]

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.

Rob