On Thu, Jul 28, 2022 at 09:21:52PM +0200, Pali Rohár wrote:
On Thursday 28 July 2022 15:18:03 Tom Rini wrote:
On Thu, Jul 28, 2022 at 09:05:07PM +0200, Pali Rohár wrote:
On Thursday 28 July 2022 14:53:49 Tom Rini wrote:
[snip]
+When it has been determined that the practical solution for where to have +something is in the ``CFG`` namespace, the next decision is where to place these +settings. It is strongly encouraged to place these in the architecture header +files, if they are generic to a given SoC, or under the board directory if board +specific. Placing them under the board.h file in the *include/configs/* +directory should be seen as a last resort.
Sounds good.
The only missing bit of information for me, which I really do not know still remain... Where, how and in which format to store board specific CFG option which is required for architecture or SoC for proper setup?
It cannot be in board/ subdir because arch/ code cannot use it (and even do not know which include file should use). It cannot be in arch/ subdir because it is SoC specific (e.g. arch would have to use long spaghetti #if defined(BOARD_1) ... #elif defined(BOARD_2) ... #endif block). And it cannot be in include/configs/ because you do not like it and do not want it here.
Currently this issue is _un_solved by using CONFIG option either in Kconfig or in include/configs/ ... and both options are not ideal.
I just do not see how to solve this problem.
I think it's fine to have things in quite literally <asm/arch/soc.h> (which we have a few of already) and then as needed #if / #elif / #endif for SoC changes. Much of this _could_ be instead pulled from device trees. But that's unlikely to happen for a number of platforms. And for the board specific cases which are not converted to come out of device tree, include/configs/board.h isn't going to be able to go away for that platform just yet.
So in a round about way, yes, I'm just punting on the problem because I suspect the "right" answer is converting to driver model in a more complete way and pulling the information from the device tree. But I accept there's not a desire on anyones part to invest that much time in a dead end platform.
Driver model and device tree is probably the better place. But in case such option is required for SoC setup to allow U-Boot to access device tree then it cannot be in device tree...
I guess I need an example value or two please, that can't reside in <arch/asm/soc.h> nor can be delayed long enough to come from the device tree instead.
One thing that we can and do in some platforms do today is have SPL use a correct-enough simplified device tree so we always enable enough clocks/mux to have GPIOs work to determine the real rev we're on and pass the correct tree to full U-Boot. I don't think we have the hooks to re-evaluate the tree in full U-Boot, but perhaps we do need that.