On Thu, Sep 8, 2016 at 7:39 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: > On Thu, Sep 8, 2016 at 5:33 PM, Rob Herring <robh+dt@xxxxxxxxxx> wrote: >> On Thu, Sep 8, 2016 at 4:15 PM, Dmitry Shmidt <dimitrysh@xxxxxxxxxx> wrote: >>> On Thu, Sep 8, 2016 at 2:08 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: >>>> What problem(s) are you trying to solve with this? >>> >>> Currently the Linux kernel doesn't provide a way for boot time >>> selection of different possible board configurations, when the board >>> peripherals are specified via Device Tree. >> >> Well, the kernel does provide a way. For different h/w you give it a >> different h/w description (i.e. dtb). The issue is having multiple >> dtbs for mostly similar h/w is a PIA. > > Agreed. > >> Also, it can be argued this should remain a bootloader problem. For >> the LCD case, the bootloader is going to need that information to >> support a splash screen. libfdt is learning how to apply overlays on >> flat trees. > > I can imagine in many cases like devboards with various attached > shields/mezzanines the bootloader doesn't (and likely can't) have this > ability. Yes. That's the main reason overlays exist. There's a big blocker for a major subset of this case that is needing to define a connector binding. 96board mezzanine boards for example should have 1 overlay independent of the base board and that means we need some indirection for things like what i2c controller goes to I2C0 bus on the low speed connector. All that is being worked on (slowly). >>>> What is the use case? >>> >>> It is usually useful for development board when you can use >>> different peripherals. For example you want to use special >>> LCD panel. Using it will go on account of other stuff like GPIOs, >>> so you don't want it all the time. And it is not convenient to >>> apply new patches and to recompile the kernel. And this code >>> allows to choose LCD panel configuration from command line. >> >> If you can figure out how to change the command line, then you can >> just change the dtb. At least for how Android boot works, those aren't >> really changed separately. > > Ehh.. that's not so simple. The dtb is often appended to the kernel on > Android devices. Changing the boot arguments is much simpler to do. How? You typically make a new bootimage assembling the kernel/dtb, ramdisk and kernel command-line. If things were done differently such that the dtb is part of the bootloader (how it is supposed to be done), then I would buy the argument that we can't update the dtb and need to either have a way to add and/or select overlays. But Android folks like to update *everything*, so I don't buy that here. 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
