On Wed, Jun 10, 2020 at 11:40:33PM +0200, Marek Vasut wrote:
On 6/10/20 11:35 PM, Tom Rini wrote:
On Wed, Jun 10, 2020 at 10:56:40PM +0200, Marek Vasut wrote:
On 6/10/20 10:54 PM, Tom Rini wrote:
On Wed, Jun 10, 2020 at 10:46:23PM +0200, Marek Vasut wrote:
On 6/10/20 10:11 PM, Tom Rini wrote: [...]
>>>> You mean be more like barebox and Linux where the board-specific stuff >>>> is kicked up one level and we have a more generic binary? I don't know >>>> and there's so much work that would be required before having to move >>>> this from a Kconfig choice to just Kconfig options I don't see that as >>>> being a relevant question here. >>>> >>>> Or did I misunderstand the question? >>> >>> More like automatically have a Kconfig option generate it's _SPL and >>> _TPL variant. >> >> Ah. Well, that is rephrasing my first question. Would it ever make >> sense to have more than one of these enabled? > > For some sort of universal SPL, maybe ?
So no, there's not a reason today then and it should be a choice.
Can you provide some more detailed explanation why we shouldn't generate _SPL and _TPL variants of Kconfig entries for all Kconfig entries ? It would make things much simpler and permit configuring SPL/TPL the same way U-Boot is configured, with their own set of options.
In the context of this particular thread? I don't see how it's helpful to say 3 times that we're in fact building for Tegra or STM32 or SoCFPGA when you can't build something that runs on more than one of those.
In general.
Here I can imagine it is possible to build SoCFPGA+STM32 universal SD card image in fact.
So that's the case I brought up at first and you said no to.
I think I don't understand this part.
You're talking about a binary that runs on more than one dissimilar SoC, yes?
I don't see that in the foreseeable future but I don't feel so strongly about making this config area tidy enough to argue the point. So fine, leave it as separate options, the default y if ... is reasonable enough to ensure we get functional builds.
This patch is OK as-is.
Yes, since I'm no longer asking for changes to it, it's fine.
My point is more in the general direction of being able to configure SPL/TPL/U-Boot separately, without being forced to craft nasty ifdeffery in include/config/board.h if I need something enabled in SPL, but not in U-Boot, and vice versa. And for that the Kconfig should be able to somehow emit the _SPL/_TPL/U-Boot options of all symbols I think, so that we won't need separate entry for each.
I haven't seen a case where the nasty ifdeffery in a config header file wasn't basically either: - Now wrong (we _have_ the symbols today to say we don't want X in SPL) - Working around a case where we need to use $(SPL_TPL_) somewhere but didn't know that we could use $(SPL_TPL_) to fix the problem instead. - Now not useful (for example, disable CMD_xxx for SPL, but we've really sorted things out so now so doing that didn't help anything).
Now I'm happy to admit that I just might be missing a case as I've only gotten as far as "undef CONFIG_[ABC]" and BOOTCOMMAND is possibly leading to embedding a long string where we really don't want it. Please point me at more undef cases that need to be resolved in some way. Thanks!