Message ID | 1412412466.17796.65.camel@hellion.org.uk |
---|---|
State | Accepted |
Delegated to: | Ian Campbell |
Headers | show |
On Sat, 2014-10-04 at 09:47 +0100, Ian Campbell wrote: > Probably the board [...] selection could be moved out > without any dependencies, although the board one in particular will be > quite a big patch I think it would be worth it. On the topic of board selection which way round should the SoC vs. board options be arrange? Should we have invisible TARGET_SUN?I options which are selected by each board, or should we have the boards depend on the appropriate TARGET? In the first case a user would need to choose from a pretty long list of boards, in the second case they would need to know which SoC the board has. I'm leaning towards the first. I don't think either would be an impediment to an eventually single common binary which I'm imagining would appear as a "Generic board" option which depends/selects all appropriate SoCs. Ian.
Hi Ian, On Sat, 04 Oct 2014 10:32:04 +0100 Ian Campbell <ijc@hellion.org.uk> wrote: > On Sat, 2014-10-04 at 09:47 +0100, Ian Campbell wrote: > > Probably the board [...] selection could be moved out > > without any dependencies, although the board one in particular will be > > quite a big patch I think it would be worth it. > > On the topic of board selection which way round should the SoC vs. board > options be arrange? Should we have invisible TARGET_SUN?I options which > are selected by each board, or should we have the boards depend on the > appropriate TARGET? > > In the first case a user would need to choose from a pretty long list of > boards, in the second case they would need to know which SoC the board > has. > > I'm leaning towards the first. Either would work, but as for Tegra, the second one has been chosen. Architecture select (CONFIG_ARCH) -> Tegra Platform (CONFIG_TEGRA) -> Tegra SoC select (CONFIG_TEGRA20 / 30 / 114 / 124) -> Board select > I don't think either would be an impediment to an eventually single > common binary which I'm imagining would appear as a "Generic board" > option which depends/selects all appropriate SoCs. Best Regards Masahiro Yamada
On Mon, 2014-10-06 at 11:16 +0900, Masahiro Yamada wrote: > Hi Ian, > > On Sat, 04 Oct 2014 10:32:04 +0100 > Ian Campbell <ijc@hellion.org.uk> wrote: > > > On Sat, 2014-10-04 at 09:47 +0100, Ian Campbell wrote: > > > Probably the board [...] selection could be moved out > > > without any dependencies, although the board one in particular will be > > > quite a big patch I think it would be worth it. > > > > On the topic of board selection which way round should the SoC vs. board > > options be arrange? Should we have invisible TARGET_SUN?I options which > > are selected by each board, or should we have the boards depend on the > > appropriate TARGET? > > > > In the first case a user would need to choose from a pretty long list of > > boards, in the second case they would need to know which SoC the board > > has. > > > > I'm leaning towards the first. > > > Either would work, but as for Tegra, the second one has been chosen. Thanks. I think global consistency is a worthwhile goal, so sunxi should follow the same pattern. > > > Architecture select (CONFIG_ARCH) > -> Tegra Platform (CONFIG_TEGRA) > -> Tegra SoC select (CONFIG_TEGRA20 / 30 / 114 / 124) > -> Board select > > > > > > I don't think either would be an impediment to an eventually single > > common binary which I'm imagining would appear as a "Generic board" > > option which depends/selects all appropriate SoCs. > > > > > Best Regards > Masahiro Yamada > >
diff --git a/MAKEALL b/MAKEALL index 7c16319..3a8d1d0 100755 --- a/MAKEALL +++ b/MAKEALL @@ -660,6 +660,11 @@ build_target() { echo "Building ${target} board..." ${MAKE} -s ${target}_defconfig >/dev/null + if [ -n "$SUNXI_FORCE_FEL" ] ; then + sed -i -e 's/\# CONFIG_SPL_FEL is not set/CONFIG_SPL_FEL=y/g' \ + .config spl/.config + fi + ${MAKE} ${JOBS} ${CHECK} all \ >${LOG_DIR}/$target.MAKELOG 2> ${LOG_DIR}/$target.ERR