On Thursday 28 July 2022 15:26:08 Tom Rini wrote:
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.
For example those powerpc preliminary local bus settings which configures boot device memory mappings. Boot source is chosen by user (currently by selecting appropriate defconfig file). It is something which is board specific (based on board wiring), for each boot source different and instruct u-boot in early stage to correctly map remaining part of u-boot binary where is stored DTB blob.
I can imagine such #if / #elif / #elfi / .... block in som arch/ file with more extensions to include also sub-#if block for boot source... but well such monster #ifdef hell is unmaintainable.
Look for example how many defconfig files are there for P[12]* boards. For every one you would have to introduce #elif chain.
But this is just an example. I can imagine similar issues on other platforms which have RDB boards with tons of boot source options.
I know also ARM64 based boards which have boot strapping options to skip integrated BootROM and start booting directly from CS or other device local bus.
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.
-- Tom
We have such hooks, in proper U-Boot it is possible to do small modifications in DTB blob prior binding drivers. I'm preparing patches for Omnia board which use this feature. So it is not only possible but it is already working.
But in case device tree is not accessible yet (due to very early stage) then such hooks do not help.