| 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
A few simple patches which consolidate some Kconfig options and make SPL_FEL a first class .config member instead of putting it in CONFIG_SYS_EXTRA_OPTIONS. This means it is possible to do a FEL build for any board with: make <board>_config echo CONFIG_SPL_FEL=y >> .config echo CONFIG_SPL_FEL=y >> spl/.config or better make <board>_config sed -i -e 's/\# CONFIG_SPL_FEL is not set/CONFIG_SPL_FEL=y/g' .config spl/.config which is still one more step than I would like but still preferable IMHO to: sed -i -e 's/^CONFIG_SYS_EXTRA_OPTIONS="[^"]*/&,SPL_FEL/g' .config spl/.config I've been using a little hack (below) to MAKEALL to help build test this. There's still plenty of stuff in sunxi CONFIG_SYS_EXTRA_OPTIONS which could be moved out, but most of it is dependent on drivers/*/Kconfig switching first. Probably the board and power controller 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. Ian. My MAKEALL hack, surely not upstreamable ;-)