Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
I'm struggling against this, I don't really know how to proceed,
except keeping monolithic dts files including other dtsi files.
About dt-overlays I've tried to look around lot of time,
but the only thing I've found is this:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
where they use .dtso tagging them as "/plugin/;"
and compile all .dtso found in dts folder.
Then they obtain .dtbo files that should be the dt-overlays we have spoken
about right?
Yes. You don't have to do that though, you can just rely on dtc to
compile them, outside of the linux build system.
What I can't understand is if there's a real standard at this time to
follow, because on renesas-driver they use their way to handle all .dtso
files, but on mainline there seems to be nothing about that.
I'm not sure what you mean here. It's just fragments of device tree,
that have to be compiled using dtc, that's it. You can use the Linux
build system infrastructure to do that, or you can build your own
simpler one. That's really up to you. See for example
https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
(even though the overlays themselves use the legacy syntax and
shouldn't really be used an examples)