[RFCv2] doc: develop: Describe system configuration

[Tom Rini]

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.

-- 
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/4d7c1087/attachment.sig>