On Tue, Feb 16, 2016 at 09:30:44PM +0900, Masahiro Yamada wrote: > 2016-02-16 21:17 GMT+09:00 Tom Rini <tr...@konsulko.com>: > > On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote: > >> Hi Simon, > >> > >> > >> 2016-01-29 1:39 GMT+09:00 Simon Glass <s...@chromium.org>: > >> > We need a way to support more than one board per binary in U-Boot with > >> > device tree. Various methods have been discussed. The one that seems to > >> > make > >> > the most sense is to adjust SPL so that it can load a FIT which contains > >> > U-Boot and several device tree binaries. This is how things with with > >> > Linux: > >> > load a FIT and select the correct device tree to pass to Linux. > >> > >> I've just skimmed over the git-logs, but I am confused. > >> > >> > >> Please makes it clearer why this is useful. > >> In your way, how SPL is handled? > >> > >> SPL is much more board-specific than U-Boot proper. > >> So, I assume SPL would remain as a per-board image > >> even after achieving one U-Boot proper for multi-boards. > >> > >> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot > >> proper. > >> > >> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be > >> generated by one-shot > >> and by one defconfig. > >> > >> > >> But, we would still have to do > >> > >> make board_a_defconfig && make > >> make board_b_defconfig && make > >> make board_c_defconfig && make > >> > >> to generate SPL for each of the three. > >> Is this correct? > >> > >> > >> Supposing my guess is correct, this series would not contribute > >> to decreasing the number of defconfig files. > >> > >> > >> > >> Please explain which problem you are solving with this series. > > > > It won't be just one board. We need this so that we can replicate > > existing (and very useful) functionality. Today, am335x_evm_config > > supports Beaglebone White, Beaglebone Black (could be faked enough for > > U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART > > AM335x IDK EVM. Each of these is different enough that they have their > > own DT that we will need to pass up to U-Boot, and their own config > > file. With Simon's series we'll be able to move am335x_evm_config up to > > DM in SPL and possibly even remove some of the am335x_evm subconfigs we > > have today, once those specific options also move to Kconfig. > > So, this series is useful to merge some boards > that are different enough to have their own DT, > but that are similar enough to share one SPL binary, correct?
Yes. It _may_ even be useful later on to support a more broad set of boards than we do today (ie it's not impossible that one binary could support the TI AM43xx EVMs as well, or all TI EVMs that have the EEPROM that identifies the model, for some narrow scope of boot devices). -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
