[lkml]   [2017]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files
On 08/16/17 09:16, Rob Herring wrote:
> On Wed, Aug 16, 2017 at 10:57 AM, Tom Rini <> wrote:
>> On Wed, Aug 16, 2017 at 10:43:16AM -0500, Rob Herring wrote:
>>> On Tue, Aug 15, 2017 at 5:49 PM, Tom Rini <> wrote:
>>>> On Tue, Aug 15, 2017 at 05:36:11PM -0500, Rob Herring wrote:
>>>>> On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini <> wrote:
>>>>>> With support for stacked overlays being part of libfdt it is now
>>>>>> possible and likely that overlays which require __symbols__ will be
>>>>>> applied to the dtb files generated by the kernel. This is done by
>>>>>> passing -@ to dtc. This does increase the filesize (and resident memory
>>>>>> usage) based on the number of __symbol__ entries added to match the
>>>>>> contents of the dts.
>>>>>> Cc: Rob Herring <>
>>>>>> Cc: Frank Rowand <>
>>>>>> Cc: Masahiro Yamada <>
>>>>>> Cc: Michal Marek <>
>>>>>> Cc: Pantelis Antoniou <>
>>>>>> Cc:
>>>>>> Cc:
>>>>>> CC:
>>>>>> Signed-off-by: Tom Rini <>
>>>>>> ---
>>>>>> In order for a dtb file to be useful with all types of overlays, it
>>>>>> needs to be generated with the -@ flag passed to dtc so that __symbols__
>>>>>> are generated. This however is not free, and increases the resulting
>>>>>> dtb file by up to approximately 50% today. In the current worst case
>>>>>> this is moving from 88KiB to 133KiB. In talking with Frank about this,
>>>>> Plus some amount for the unflattened tree in memory, too.
>>>>>> he outlined 3 possible ways (with the 4th option of something else
>>>>>> entirely).
>>>>>> 1. Make passing -@ to dtc be dependent upon some CONFIG symbol.
>>>>>> 2. In the kernel, if the kernel does not have overlay support, discard
>>>>>> the __symbols__ information that we've been passed.
>>>>>> 3. Have the bootloader pass in, or not, __symbols__ information.
>>>>>> This patch is an attempt to implement something between the 3rd option
>>>>>> and a different, 4th option. Frank was thinking that we might introduce
>>>>>> a new symbol to control generation of __symbol__ information for option
>>>>>> 1. I think this gets the usage backwards and will lead to confusion
>>>>>> among users and developers.
>>>>>> My proposal is that we do not want __symbols__ existence to be dependent
>>>>>> on some part of the kernel configuration for a number of reasons.
>>>>>> First, this is out of step with the rest of how dtbs are created today
>>>>>> and more importantly, thought about. Today, all dtb content is
>>>>>> independent of CONFIG options. If you build a dtb from a given kernel
>>>>>> tree, everyone will agree on the result. This is part of the "contract"
>>>>>> on passing old kernels and new dtb files even.
>>>>> Agree completely. I don't even like that building dtbs depends on the ARCH.
>>>>> However, option 2 may still be useful. There's no point exposing what
>>>>> can't be used. Furthermore, exposing __symbols__ in /proc/device-tree
>>>>> at all may be a bad idea. We should consider if it should always be
>>>>> hidden. That would also allow storing the __symbols__ data however we
>>>>> want internally (i.e. with less memory usage). The complication is
>>>>> always kexec which I haven't thought about too much here.
>>>> A further patch to the kernel at run-time, OK. If you give me some
>>>> crumbs I'll see if I can figure out the next steps.
>>>>> Also, perhaps we need finer grain control of __symbols__ generation.
>>>> Here I have to disagree.
>>>>> We really don't want userspace to be able to modify anything in the DT
>>>>> at any point in time. That's a big can of worms and we don't want to
>>>>> start there. The problem is labels are widely used just for
>>>>> convenience and weren't part of the ABI. With overlays that changes,
>>>>> so we either need to restrict labels usage or define another way. It
>>>>> could be as simple as defining some prefix for label names for labels
>>>>> to export.
>>>> I think there needs to be a difference noted between "here is what
>>>> policy the kernel is going to enforce about run time changes" and "here
>>>> is what the user is going to assemble a system to look like". Again,
>>>> stemming from the part where the Linux kernel is where dts files reside
>>>> and are generated from normally. If we have it in __symbols__, someone
>>>> can make use of it in hardware design (again, think of the SoM + carrier
>>>> + custom) bit, I've seen so many real life products now that would be
>>>> simplified in this manner).
>>> I agree the usecase is an important one and one we should target, but
>>> I think there are other issues to solve first before we get to the
>>> trivial change needing to enable __symbols__. Do we have any dts files
>>> actually structured for the SoM + carrier use case? I guess it's done
>>> with includes ATM if we do. The run-time restrictions aren't just
>>> kernel policy. The SoM itself is going to have restrictions defined by
>>> its pinout. I think those need to be described in DT via a connector
>>> binding. I worry about leaving things wide open and having overlays
>>> just be a DT configuration tool with every platform structuring things
>>> however they want. From what I've looked at on RPi, I'm very concerned
>>> about having things like CMA overlays to set the CMA size. (On the
>>> flip side as a user, it was very nice to just apply the RPi 1-wire
>>> gpio overlay and things just worked.)
>> I believe the various SoM and EVM and hobbyist cases are all either out
>> of tree, or glued together (see imx6sx-udoo-neo-* in-tree, RPi or
>> Hummingboard or TI DRA7 EVM + LCDs) as various groups decided it
>> wouldn't be accepted to push in N "complete" DTS files for each valid
>> combination). Moving forward with an in-kernel policy on how it should
>> be done, structure-wise would help with consistency and defining what's
>> really acceptable.
> IMO, that starts with a connector binding. Stephen Boyd has been
> working towards that[1]. I guess "gpio nexus" is so obscure that all
> the masses clamoring for overlays and modular board support haven't
> noticed.
> Rob
> [1]

Agreed. The connector binding is needed for overlays to move


 \ /
  Last update: 2017-08-16 20:10    [W:0.043 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site