Hi Trent, On Wed, Sep 22, 2021 at 11:13:36AM -0700, Trent Piepho wrote: > This introduces a config variable that allows adding additional fragments > to the Barebox device tree(s). > > Example uses are adjusting the flash partition layout, adding barebox > state variables, or adding an I2C device. These can be now be done with > build configuration only, without needing to patch the existing dts > files in the Barebox source. > > The advantage is greater when an external build system, such as Yocto or > Buildroot, is being used to build Barebox. The build system can drop in > a dts fragment to partition flash and build from unaltered Barebox > source. This avoids the need for cumbersome maintenance of patch files > to modify Barebox's source for each flash partition layout. > > Preprocessing the dts file gains another layer, where a generated dts > source consisting of an include directive for the original dts source is > followed by more includes for each fragment. This is piped to the > existing preprocessor call on stdin to avoid another temporary file. > cpp/dtc will correctly identify errors in the source files they occur > in. The -MT option is used so the cpp auto-dependencies reference the > original dts source and not the generated code passed on stdin. > > A preprocessor macro named after the base dts file, e.g. foo-bar.dts > will define foo_bar_dts, will be defined so that the fragments can > possibly operate differently based on which image's dts is being built. > > Signed-off-by: Trent Piepho <trent.piepho@xxxxxxxxxxxxxxxxx> > --- > Changes from v1: > - Remove 2nd config variable for in-tree fragments. > - Add macro to preproccessed dts I tested this myself and it works as expected. Applied with a little change > +config EXTERNAL_DTS_FRAGMENTS > + string "external dts file fragments" > + depends on OFTREE > + help > + List of dts fragment files that will be appended to Barebox's device > + tree(s) source when building the dtb file(s). If multiple files are > + listed, they will be appended in order. Relative filenames will use > + the dtc include search path. > + > + A preprocessor macro based on the name of the main dts will be > + defined, which allows the dts fragments to based on which image of a > + multi image build they are being used in. Changed this to: A preprocessor macro based on the name of the main dts will be defined, which allows the dts fragments to based on which image of a multi image build they are being used in. Given the dts filename used for a board is "foo-board.dts" the external dts usage can be limited to that board with #ifdef foo_board_dts ... #endif To make that point a little more clear. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
