[RFCv2] doc: develop: Describe system configuration

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220728/f7426221/attachment.sig>