From: Rob Herring <robh@kernel.org> To: Tero Kristo <t-kristo@ti.com> Cc: Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, Tom Rini <trini@konsulko.com>, Tony Lindgren <tony@atomide.com>, Russell King - ARM Linux <linux@armlinux.org.uk>, Frank Rowand <frowand.list@gmail.com>, "Mills, William" <wmills@ti.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Date: Wed, 23 May 2018 09:13:11 -0500 [thread overview] Message-ID: <CAL_JsqJPUaQf01Ahrmba2WBAApMTKq6i6LCXe6PGbq-N5f8shA@mail.gmail.com> (raw) In-Reply-To: <243730d3-e7f3-584d-b5dd-491c2700cf11@ti.com> On Wed, May 23, 2018 at 12:55 AM, Tero Kristo <t-kristo@ti.com> wrote: > On 22/05/18 23:01, Rob Herring wrote: >> >> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote: >>> >>> On 17/04/18 17:49, Tony Lindgren wrote: >>>> >>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]: >>>>> >>>>> In typical setup, you can boot a large number of different configs via: >>>>> >>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0 >>>>> >>>>> ... assuming the configs were named like that, and assuming they would >>>>> be >>>>> compatible with each other. The am57xx-evm example provided is better, >>>>> as >>>>> you can chain the different cameras to the available evm configs. >>>> >>>> >>>> Why not just do it in the bootloader to put together the dtb? >>>> >>>> Then for external devices, you could just pass info on the >>>> kernel cmdline with lcd=foo camera=bar if they cannot be >>>> detected over I2C. >>> >>> >>> (Added Linux ARM list to CC, this was not part of the original delivery.) >>> >>> Ok trying to resurrect this thread a bit. Is there any kind of consensus >>> how >>> things like this should be handled? Should we add the DT overlay files to >>> kernel tree or not? >> >> >> IMO, yes. >> >>> Should we add any kind of build infra to kernel tree, and at what level >>> would this be? Just DT overlay file building support, and drop the FIT >>> build >>> support as was proposed in this RFC series or...? >> >> >> I think I mentioned this already, but I expect that this is going to >> cause a number of conversions of dtsi + dtsi -> dtb into base dts and >> overlay(s) dts files. In doing so, we still need to be able to build the >> original, full dtb. > > > So you mean like breaking apart the existing .dts files? Are there any plans > to get that done (I know the android folks talk about this but I don't like > their idea.) If we do the split, how are we going to determine which dts + > overlay files are required to get a specific DTB done? I actually wrote a > tool for this purpose which parses the FIT image configurations and > generates plain dtb files out of the info there if needed, but assuming FIT > is abandoned then what...? There aren't any plans that I'm aware of. I'm just assuming there are some cases in the tree. It would just be some additional build rules: board-kit.dtb: soc-som.dtb expansion-board.dtbo fdtoverlay -o $@ -i $^ We'd need to come up with some way to express the input and output files in a kbuild way. Perhaps similar to how multiple module files are done. Even if you are adding new platforms, having the above would still be good. It captures what base the overlays apply to and tests that applying actually works (rather than leaving that for the user to do in the bootloader). FIT images also have or need that information, so perhaps we can define a format that works as input for both kbuild and FIT images. >>> U-boot can obviously parse the base DTB + overlay DTB:s into a single >>> DTB, >>> but this is somewhat clumsy approach and is relatively error prone to get >>> it >>> right. >> >> >> Why? How is the kernel better? > > > I am mostly speaking about runtime applying of the overlays. If done build > time, it is obviously on same level. If you apply the base DTS + overlays > from u-boot prompt, it is not too much fun, and if there are any failures it > just won't work, but don't really tell you why not. Runtime, but still at boot time, right? How is the kernel going to have better error handling? Is libfdt error handling worse than the kernel's overlay code? I do think we need to standardize how we tell bootloaders what overlays to apply. I expect that we'll do that as part of EBBR spec[1] though that is not part of the immediate focus. Rob [1] https://github.com/ARM-software/ebbr
WARNING: multiple messages have this Message-ID (diff)
From: robh@kernel.org (Rob Herring) To: linux-arm-kernel@lists.infradead.org Subject: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Date: Wed, 23 May 2018 09:13:11 -0500 [thread overview] Message-ID: <CAL_JsqJPUaQf01Ahrmba2WBAApMTKq6i6LCXe6PGbq-N5f8shA@mail.gmail.com> (raw) In-Reply-To: <243730d3-e7f3-584d-b5dd-491c2700cf11@ti.com> On Wed, May 23, 2018 at 12:55 AM, Tero Kristo <t-kristo@ti.com> wrote: > On 22/05/18 23:01, Rob Herring wrote: >> >> On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote: >>> >>> On 17/04/18 17:49, Tony Lindgren wrote: >>>> >>>> * Tero Kristo <t-kristo@ti.com> [180417 09:36]: >>>>> >>>>> In typical setup, you can boot a large number of different configs via: >>>>> >>>>> bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0 >>>>> >>>>> ... assuming the configs were named like that, and assuming they would >>>>> be >>>>> compatible with each other. The am57xx-evm example provided is better, >>>>> as >>>>> you can chain the different cameras to the available evm configs. >>>> >>>> >>>> Why not just do it in the bootloader to put together the dtb? >>>> >>>> Then for external devices, you could just pass info on the >>>> kernel cmdline with lcd=foo camera=bar if they cannot be >>>> detected over I2C. >>> >>> >>> (Added Linux ARM list to CC, this was not part of the original delivery.) >>> >>> Ok trying to resurrect this thread a bit. Is there any kind of consensus >>> how >>> things like this should be handled? Should we add the DT overlay files to >>> kernel tree or not? >> >> >> IMO, yes. >> >>> Should we add any kind of build infra to kernel tree, and at what level >>> would this be? Just DT overlay file building support, and drop the FIT >>> build >>> support as was proposed in this RFC series or...? >> >> >> I think I mentioned this already, but I expect that this is going to >> cause a number of conversions of dtsi + dtsi -> dtb into base dts and >> overlay(s) dts files. In doing so, we still need to be able to build the >> original, full dtb. > > > So you mean like breaking apart the existing .dts files? Are there any plans > to get that done (I know the android folks talk about this but I don't like > their idea.) If we do the split, how are we going to determine which dts + > overlay files are required to get a specific DTB done? I actually wrote a > tool for this purpose which parses the FIT image configurations and > generates plain dtb files out of the info there if needed, but assuming FIT > is abandoned then what...? There aren't any plans that I'm aware of. I'm just assuming there are some cases in the tree. It would just be some additional build rules: board-kit.dtb: soc-som.dtb expansion-board.dtbo fdtoverlay -o $@ -i $^ We'd need to come up with some way to express the input and output files in a kbuild way. Perhaps similar to how multiple module files are done. Even if you are adding new platforms, having the above would still be good. It captures what base the overlays apply to and tests that applying actually works (rather than leaving that for the user to do in the bootloader). FIT images also have or need that information, so perhaps we can define a format that works as input for both kbuild and FIT images. >>> U-boot can obviously parse the base DTB + overlay DTB:s into a single >>> DTB, >>> but this is somewhat clumsy approach and is relatively error prone to get >>> it >>> right. >> >> >> Why? How is the kernel better? > > > I am mostly speaking about runtime applying of the overlays. If done build > time, it is obviously on same level. If you apply the base DTS + overlays > from u-boot prompt, it is not too much fun, and if there are any failures it > just won't work, but don't really tell you why not. Runtime, but still at boot time, right? How is the kernel going to have better error handling? Is libfdt error handling worse than the kernel's overlay code? I do think we need to standardize how we tell bootloaders what overlays to apply. I expect that we'll do that as part of EBBR spec[1] though that is not part of the immediate focus. Rob [1] https://github.com/ARM-software/ebbr
next prev parent reply other threads:[~2018-05-23 14:13 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-17 9:10 [RFC 00/13] ARM: dts: DT overlay support infra + some data Tero Kristo 2018-04-17 9:10 ` [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs Tero Kristo 2018-04-19 0:02 ` Rob Herring 2018-04-17 9:10 ` [RFC 02/13] ARM: dts: add support for building DT overlays Tero Kristo 2018-04-17 9:10 ` [RFC 03/13] ARM: dts: add subdir for TI SoC DT files Tero Kristo 2018-04-17 9:10 ` [RFC 04/13] kbuild: add support for building %.dtbo targets Tero Kristo 2018-04-18 14:16 ` Geert Uytterhoeven 2018-04-17 9:10 ` [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols Tero Kristo 2018-04-18 14:20 ` Geert Uytterhoeven 2018-04-18 19:07 ` Tero Kristo 2018-04-18 22:43 ` Rob Herring 2018-04-19 6:36 ` Tero Kristo 2018-04-19 15:26 ` Rob Herring 2018-04-19 18:00 ` Tero Kristo 2018-04-17 9:10 ` [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay Tero Kristo 2018-04-18 14:36 ` Geert Uytterhoeven 2018-04-18 19:12 ` Tero Kristo 2018-04-18 19:15 ` Russell King 2018-04-20 13:27 ` Geert Uytterhoeven 2018-04-18 22:40 ` Rob Herring 2018-04-19 0:19 ` Rob Herring 2018-04-19 6:49 ` Tero Kristo 2018-04-20 1:31 ` Rob Herring 2018-04-17 9:10 ` [RFC 07/13] ARM: dts: ti: add camera overlays Tero Kristo 2018-04-17 9:10 ` [RFC 08/13] ARM: dts: ti: add dra71-evm overlays Tero Kristo 2018-04-17 9:10 ` [RFC 09/13] kbuild: add support for generating FIT images Tero Kristo 2018-04-17 9:10 ` [RFC 10/13] ARM: dts: add FIT image build support for ARM architecture Tero Kristo 2018-04-17 9:10 ` [RFC 11/13] ARM: dts: ti: add FIT image dependencies Tero Kristo 2018-04-17 9:10 ` [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file Tero Kristo 2018-04-17 9:29 ` Russell King 2018-04-17 9:34 ` Tero Kristo 2018-04-17 14:49 ` Tony Lindgren 2018-05-21 6:57 ` Tero Kristo 2018-05-21 6:57 ` Tero Kristo 2018-05-22 20:01 ` Rob Herring 2018-05-22 20:01 ` Rob Herring 2018-05-23 5:55 ` Tero Kristo 2018-05-23 5:55 ` Tero Kristo 2018-05-23 14:13 ` Rob Herring [this message] 2018-05-23 14:13 ` Rob Herring 2018-05-23 18:37 ` Tony Lindgren 2018-05-23 18:37 ` Tony Lindgren 2018-05-29 17:05 ` Frank Rowand 2018-05-29 17:05 ` Frank Rowand 2018-05-29 17:33 ` Russell King - ARM Linux 2018-05-29 17:33 ` Russell King - ARM Linux 2018-05-29 22:45 ` Frank Rowand 2018-05-29 22:45 ` Frank Rowand 2018-05-29 22:51 ` Russell King - ARM Linux 2018-05-29 22:51 ` Russell King - ARM Linux 2018-04-17 9:10 ` [RFC 13/13] ARM: dts: ti: add am57xx-evm " Tero Kristo 2018-04-17 9:18 ` [RFC 00/13] ARM: dts: DT overlay support infra + some data Russell King
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAL_JsqJPUaQf01Ahrmba2WBAApMTKq6i6LCXe6PGbq-N5f8shA@mail.gmail.com \ --to=robh@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux@armlinux.org.uk \ --cc=mark.rutland@arm.com \ --cc=t-kristo@ti.com \ --cc=tony@atomide.com \ --cc=trini@konsulko.com \ --cc=wmills@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.