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@xxxxxx> [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. > 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? > Building the FIT image post kernel build would also be possible, but who > would be doing this, is there any need to get this done in generic manner or > shall we just add SoC vendor specific tools for this? I'll tell you up front, I'm not a fan of FIT image (nor uImage, Android boot image, $bootloader image). If you want a collection of files and some configuration data, use a filesystem and a text file. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
