Hi Alexey, On 15 January 2015 at 13:49, Alexey Brodkin <alexey.brod...@synopsys.com> wrote: > Hi Simon, Masahiro-san, > > On Thu, 2015-01-15 at 12:44 -0700, Simon Glass wrote: >> Hi Masahiro, >> > Honestly, I do not like baseline options in board-Kconfig very much. >> > The advantage is that it works without any change. >> > >> > >> > What I suggested before was to use scripts/kconfig/merge_config.sh. >> > >> > For example, put the SoC baseline options into tegra30_defconfig. >> > Put the difference from that into tegra30_(board).config >> > For example, >> > >> > make tegra30_defconfig tegra30_seaboard.config >> > make tegra30_defconfig tegra30_trimslice.config >> > >> > The disadvantage is that we would have to input more for the configuration >> > and has some impact on other projects such as BuildRoot... > > Are you saying this approach really works? > I mean "make tegra30_defconfig tegra30_seaboard.config". > > Anyway I don't really like to change behavior of things people used to > use. It will produce a lot of confusion instead of convenience of > well-known tool. > >> > >> > In barebox, for example, all the Tegra boards share a single >> > defconfig, "tegra_v7_defconfig" >> > >> > tegra_v7_defconfig creates images for beaver, jetson, colibri, ac100, ... >> > >> > It takes advantage of Device Tree configuration and garbage collection. >> > So, it generates multipule images without increasing memory foot-print. >> > >> >> I've been keen on that approach and have taken some steps for Tegra >> and Exynos. Exynos is actually not to far away, but Tegra 124 pinmux >> approach makes this hard. >> >> Still I think this is the best solution - fewer boards to build also. > > I do like this approach as well. > But there will be pitfalls. > > Imagine there's say a driver for Ethernet controller which is used on > MyBoard1 and MyBoard2. One board may use DMA/Phylib/caches and another > doesn't use either of options I listed. > > This means we need to build 2 instances of the driver, because options > that I listed could not be built as extensions to some basic driver. You > may think of it like compilation with different flags.
Not a nice driver. Can it not support both at run-time? > > Another good example which will inevitable hit me with proposed solution > - some of our boards have either replaceable CPU tile or FPGA instead of > real silicon CPU. It means that the same one board (read peripherals) > could be driven by different CPUs. I mean not only variations of one > core (in this case we may build for some base-line configuration of CPU > so it will run on all more advanced cores) but it could be > binary-incompatible CPUs. It means we'll need to re-build everything > (sic!) for each board. It would be nice to have a cpu interface to allow multiple CPUs, but yes at present this is where we are. > > Still I'm not saying anything against proposed "multibuild" approach - I > do like it, but we need to understand if it may satisfy all of our > requirements. Or what will be overheads if we decide to go this way. > Probably in my case with binary-incompatible cores the simplest solution > will be 2 defconfigs which only differ in CPU version selection. Yes indeed. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
