Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1712483 > unrolled thread
| Started by | Tom Rini <trini@konsulko.com> |
|---|---|
| First post | 2017-08-15 23:20 +0200 |
| Last post | 2017-08-16 11:40 +0200 |
| Articles | 2 on this page of 22 — 5 participants |
Back to article view | Back to linux.kernel
[PATCH] devicetree: Enable generation of __symbols__ in all dtb files Tom Rini <trini@konsulko.com> - 2017-08-15 23:20 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Rob Herring <robh@kernel.org> - 2017-08-16 00:40 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Tom Rini <trini@konsulko.com> - 2017-08-16 00:50 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Rob Herring <robh@kernel.org> - 2017-08-16 17:50 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Tom Rini <trini@konsulko.com> - 2017-08-16 18:00 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Rob Herring <robh@kernel.org> - 2017-08-16 18:20 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 20:20 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 02:00 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 02:00 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Pantelis Antoniou <pantelis.antoniou@konsulko.com> - 2017-08-16 11:50 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 20:00 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 02:20 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 02:00 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Tom Rini <trini@konsulko.com> - 2017-08-16 02:50 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 05:30 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Tom Rini <trini@konsulko.com> - 2017-08-16 17:10 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 20:20 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Rob Herring <robh+dt@kernel.org> - 2017-08-16 17:30 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Tom Rini <trini@konsulko.com> - 2017-08-16 17:50 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Rob Herring <robh+dt@kernel.org> - 2017-08-16 18:10 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Frank Rowand <frowand.list@gmail.com> - 2017-08-16 02:20 +0200
Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Pantelis Antoniou <pantelis.antoniou@konsulko.com> - 2017-08-16 11:40 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Frank Rowand <frowand.list@gmail.com> |
|---|---|
| Date | 2017-08-16 02:20 +0200 |
| Subject | Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files |
| Message-ID | <ueUdX-8jK-1@gated-at.bofh.it> |
| In reply to | #1712483 |
On 08/15/17 14:15, 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. < snip > And for some background, for those who were not on the irc channel, here is the conversation that Tom and I had: <Tartarus> frowand: So, dtc knows -@, but the kernel doesn't globally use -@ yet due to increased memory usage, in the dtb? <frowand> yes <frowand> It is available via the pattern that you can see in drivers/of/unittest-data/Makefile <Tartarus> Is there an opt-in way to get the extra symbols? <frowand> # enable creation of __symbols__ node <frowand> DTC_FLAGS_overlay := -@ <Tartarus> ah, hm <frowand> The problem is that it is always on, once the flags are added <frowand> there are a few ways I have thought of making it optional <frowand> 1) DTC_FLAGS_overlay := CONFIG_OVERLAY_ENABLED_IN_BASE <Tartarus> OK. There's at least a few vendors that are eagerly awaiting overlays Just Working, is why I'm asking <Tartarus> How much extra memory usage are we talking about, on a 'big' platform for example? <frowand> where CONFIG_OVERLAY_ENABLED_IN_BASE is a string of either empty or "-@". I don't know if the kconfig allows that, but I'm guessing there is some way to do it <frowand> Not sure of size penalty. <Tartarus> CONFIG_USE_xxx as a bool, CONFIG_xxx as the string <Tartarus> I would kind of assume wanting overlays to just work would be the common case, at least in terms of in-kernel users <frowand> 2) When instantiating the device tree from the FDT, do not keep the __SYMBOLS__ node if overlays are not enabled in the kernel <Tartarus> ie if it's a CONFIG opt-in, multi_v7_defconfig, etc, would want it on <frowand> the issue with 2, is that the boot image still has the size penalty <frowand> 3) the bootloader could choose whether to pass the __SYMBOLS__ node to the kernel or not <Tartarus> I'm not sure about 3 honestly <frowand> Yep, 3 is my least favorite. <Tartarus> If one has a case where there's a desire for no overlay support, for whatever reason, that's a feature of the kernel <frowand> There is probably also option 4, 5, etc. But I haven't thought it through too deeply yet. <Tartarus> I can see some sort of CONFIG option, default y, being a reasonable option here <frowand> I'm not sure about the common case. There are some boards where overlays would almost always be used, but there may also be boards where there are rarely used. <frowand> But the common case is a bikeshed issue to me. <Tartarus> heh <Tartarus> Well, here's why I was thinking that <frowand> As long as the users and distros have a way to control it. <Tartarus> Lots of proprietary boards I've dealt with could just be an EVM + overlay <Tartarus> wrt dtb <frowand> what is EVM? <Tartarus> Today it's take the evm dts, start hacking <Tartarus> evaluation platform <Tartarus> The second, similar, example would be custom platforms based on SoMs <frowand> Are you saying to use an overlay to add onto the base EVM dts kinda sorta the way that some driver writers use kernel modules to add drivers? <Tartarus> A reasonable analogy, yes <frowand> ok, just wanted to verify I understood the model <frowand> I see that as a reasonable development technique <frowand> I have some time critical errands to run, so I'll be gone for a few hours. It would be good to share what we just said with the mail list, and see if anyone else has some brilliant ideas. Start with what the objectives/issues are, some possible solutions...
[toc] | [prev] | [next] | [standalone]
| From | Pantelis Antoniou <pantelis.antoniou@konsulko.com> |
|---|---|
| Date | 2017-08-16 11:40 +0200 |
| Message-ID | <uf2XT-5kr-3@gated-at.bofh.it> |
| In reply to | #1712483 |
Hi Tom, Sorry for taking a little bit of time to reply to this (vacation time). > On Aug 16, 2017, at 00:15 , Tom Rini <trini@konsulko.com> 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 <robh+dt@kernel.org> > Cc: Frank Rowand <frowand.list@gmail.com> > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Michal Marek <mmarek@suse.com> > Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> > Cc: devicetree@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > CC: linux-kbuild@vger.kernel.org > Signed-off-by: Tom Rini <trini@konsulko.com> > --- > 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, > 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. > > Second, I think this is out of step with how a lot of overlay usage will > occur. My thinking is that with maximally useful overlays being > available in mainline, lots of use-cases that we have today that result > in a number of DTS files being included can become just overlays. This > is true in terms of not only evaluation kits but also when these systems > are turned into custom hardware. This is even more true for SoM based > systems where a physical widget would be a SoM + carrier overlay + > custom parts overlay. These cases are going to be resolved with > overlays being applied outside of the kernel. > FWIW here are some thoughts of mine on this subject. First, the whole business with the __symbols__ (& the fixup nodes) is meant to be used as a method to pass along symbol information, inband with the DTB in such a way as it would require absolutely no changes to booloaders and the kernel unflattening methods with the downside of the increased memory consumption. That said, there’s no reason to keep the __symbols__ node as part of the in kernel device tree structure after loading. In fact operations would be much easier if that would be the case. That would go hand in hand with the a previously posted patch that turns phandle lookups into hash/idr lookups. I would think that whether overlays would be supported could be a board level option, but I would hate for overlay support to be dependent on a kernel config option. Yes, this is contradictory, I know :(. The problem is that if you don’t have symbols generated at compile time of the kernel DTB you’re SOL loading an overlay later. I was thinking of a patch that would allow ‘patching in’ the symbols of an kernel at runtime, when that would be required (using a kernel module containing that symbol information). Finally Tom is absolutely correct; the way that system design for EVM+SoM is done leads naturally to thinking in ‘overlay’ terms. So instead of the all the different DTBs for different variants of boards we could have the .DTSIs compiled as overlays and then the final DTB reconstructed at boot time (whether by the bootloader or the kernel). Regards — Pantelis > Signed-off-by: Tom Rini <trini@konsulko.com> > --- > drivers/of/unittest-data/Makefile | 5 ----- > scripts/Makefile.lib | 3 +++ > 2 files changed, 3 insertions(+), 5 deletions(-) > > diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile > index 6e00a9c69e58..70731cfe8900 100644 > --- a/drivers/of/unittest-data/Makefile > +++ b/drivers/of/unittest-data/Makefile > @@ -11,8 +11,3 @@ targets += overlay_base.dtb overlay_base.dtb.S > .PRECIOUS: \ > $(obj)/%.dtb.S \ > $(obj)/%.dtb > - > -# enable creation of __symbols__ node > -DTC_FLAGS_overlay := -@ > -DTC_FLAGS_overlay_bad_phandle := -@ > -DTC_FLAGS_overlay_base := -@ > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 58c05e5d9870..a1f4a6b29d75 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -293,6 +293,9 @@ DTC_FLAGS += -Wnode_name_chars_strict \ > -Wproperty_name_chars_strict > endif > > +# enable creation of __symbols__ node > +DTC_FLAGS += -@ > + > DTC_FLAGS += $(DTC_FLAGS_$(basetarget)) > > # Generate an assembly file to wrap the output of the device tree compiler > -- > 1.9.1 >
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web